|
|
| Author |
Message |
| 25 new of 115 responses total. |
gelinas
|
|
response 19 of 115:
| 
Jan 26 13:43 UTC 2005 |
"display conference" works at the RFP prompt, too. :)
|
janc
|
|
response 20 of 115:
|
Jan 26 14:22 UTC 2005 |
resp:17 -
I recently grabbed a copy of your .cfonce and found it worked perfectly.
However, there wasn't a "set sane" in there. Maybe you took it out? Where
was it? Theoretically it is supposed to be first.
resp:18 -
(1) Hmmm...looks like picospan does that only in the special case where
only one item is given in the range. Should be easy enough to
make that happen.
(2) This is a trivial change to make in fronttalk.
(3) This is a deliberate change, having to do with architectural
differences between Backtalk and Picospan. In Picospan, to get
a list of conferences, you do "help conferences". This is weird,
since the help command normally shows you manual pages, not anything
about the configuration of the conferencing system. But it makes a
kind of backwards sense because in Picospan there really is no
computer readable list of conferences, just a manually maintained
text file that is printed out when you type "help conferences".
Backtalk needs to be able to parse conference lists, so it can
display them in pretty tables and stuff. On Grex it uses a set of
regular expressions tuned to the format of the manually maintained
conference file, but on most installs it has a rigidly structured
confmenu file that is maintained via some administrative web pages.
Displaying the contents of this with the "help" command instead of
the "display" command makes even less sense than it did before.
So, in Fronttalk, to get a list of all conferences on the current
server, you do:
display conferences
This can be abbreviated a lot, like to
d c
For backwards compatibility there is a kludge that makes "help conf"
do the same thing. However, this means that "disp conf" can no longer
display information about the current conference. My solution to this
was to create a new command:
display thisconf
Which gives similar information to the old Picospan "disp conf"
command. I figured renaming this relatively uncommon and obscure
command to make a common and important command more sensible was
a fair tradeoff, but I was never all that happy with the "thisconf"
keyword. Just haven't thought of anything better.
Incidentally, there are some similar commands for servers. You can
do "display servers" to get a list of all the servers Fronttalk knows
about (rather few, I should at least add M-Net to that list), and
"display thisserver" gives info about the server you are currently
connected to.
|
davel
|
|
response 21 of 115:
|
Jan 26 14:31 UTC 2005 |
John, "read 53 nor" [for "noresponses" I think] takes you directly to the
respond-or-pass prompt. Seems to work in ft too.
Fronttalk seems to require a lot more typing than picospan - fewer
abbreviations work.
|
janc
|
|
response 22 of 115:
|
Jan 26 14:38 UTC 2005 |
Hmmm...I'm noticing accessing remote conferencing systems (like hvcn) is being
slow and broken. I wonder if that is just because the proxy is still in the
pumpkin, so http connections out of Grex are going through the bad old DSL
twice.
Hmmm...M-Net accepts connections to backtalk only with "https". Fronttalk
doesn't talk https. Probably that is something I should look into.
|
janc
|
|
response 23 of 115:
|
Jan 26 14:39 UTC 2005 |
Which abbreviations don't work? Theoretically they all should.
|
gelinas
|
|
response 24 of 115:
|
Jan 26 15:14 UTC 2005 |
Here are the first eight lines of my .cfonce:
} # here is where you can put PicoSpan customization
}
} ## Stuff suggested in staff
} set nosource
} set sane
} set supersane
}
} ## Stuff . . . borrowed . . . from valerie
I use "read n1, n2, n3, n4 new" regularly. If I repeat an item number or
include an item that has no new responses, I get the RFP prompt for that
item, and the new responses for the other items.
Odd that my .cfonce works for you but not for me. :)
|
gelinas
|
|
response 25 of 115:
|
Jan 26 15:23 UTC 2005 |
} Ok: jh
} I don't understand "jh" - type HELP for help
}
} Ok: !grep jh .cfdir/.cfonce
} define jh 1 "join helpers"
}
} Ok: r 5 n
} No items found in range
I've already determined, by experimentation, that either sane or supersane,
and I don't remember which, disables my iseps and rseps. Maybe file
permissions are the problem? Right now, it's:
} -rw------- 1 gelinas people 3224 Jan 10 08:09 .cfdir/.cfonce
|
janc
|
|
response 26 of 115:
|
Jan 26 15:47 UTC 2005 |
I've implemented fixes for John's comments (1) and (2). They'll be in the
0.3.8 release.
I added a "skip"/"noskip" option to the "read new" command. If you do
"read new noskip 1-34" then it will do an ordinary "read new" but it will
also stop with a "Respond or Pass?" prompt at items with no new responses.
The default is "skip", unless a range is given with only one item in it, in
which case it defaults to "noskip".
|
remmers
|
|
response 27 of 115:
|
Jan 26 16:09 UTC 2005 |
Re #21: Thanks for the tip on "nor", Dave.
The semantics of the keyword "this" seems to be different in ft. In pico,
one can use "this" as an argument to various commands, and it applies it to
the most recent item looked at - e.g. "read new this" or "forget this".
I tend to use this fairly often. When I tried "read this" in ft after
having just read this item, it showed me item 1.
|
janc
|
|
response 28 of 115:
|
Jan 26 16:19 UTC 2005 |
Looks like I had somehow grabbed only half Joe's .cfonce file.
Permission shouldn't matter. With Fronttalk, you might theoretically have
two .cfonce files - one on the server and one on your local system. In the
Grex case they are the same, so Fronttalk has the brains to execute only the
local .cfonce. That means it is being accessed by the Perl program, which
is running as you, not by Backtalk which is running as cfadm. Should be OK.
Hmmm...looks like the "set sane" and "set supersae" command were incorrectly
terminating execution of the .cfonce file. I think I fixed that (on Grex
too).
Joining the puzzle conference with Joe's .cfonce file instead of mine seems
to hang.
|
janc
|
|
response 29 of 115:
|
Jan 26 16:41 UTC 2005 |
Oops, the current item number was being set to 1 when you joined a conference,
and then never changed. Fix will be in 0.3.8.
|
gelinas
|
|
response 30 of 115:
|
Jan 26 18:20 UTC 2005 |
My macros now work. :)
Thank you, Jan. :)
|
gelinas
|
|
response 31 of 115:
|
Jan 26 18:22 UTC 2005 |
As noted, "jpu" hangs. I wonder if it's a problem with the conference?
|
gelinas
|
|
response 32 of 115:
|
Jan 26 18:43 UTC 2005 |
Why is "SET SAVESEEN ignored in Fronttalk"?
|
janc
|
|
response 33 of 115:
|
Jan 26 20:15 UTC 2005 |
SAVESEEN is what Fronttalk *always* done. NOSAVESEEN would be extremely hard
to do in Fronttalk.
Picospan's default behavior is NOSAVESEEN. That means that it reads in your
participation file when you join the conference, and does not write anything
back out until you exit the conference. The Fronttalk client can't do this
because it doesn't read your participation file. It's the Backtalk server
that does that. But the Backtalk server just displays one item, then exits.
Since it isn't persistant, it can't keep your participation file in memory
until you exit the conference. So with Fronttalk we always update the
participation file after each item you read.
If I wanted to implement NOSAVESEEN in Fronttalk, I'd have to modify the
server not to update the participation files, and instead have the client
remember what you've seen since you joined and have the client make an
explicit call to the server when you exit the conference giving it the new
data to write out to the participation file. I'd also no longer be able to
have the server do the job of finding the next new item, because it doesn't
have the current participation file data, so it can't. Many other
complexities would be introduced, all to support a mode of operation that is
pretty much undesirable anyway.
So Fronttalk is going to keep ignoring SET SAVESEEN
|
janc
|
|
response 34 of 115:
|
Jan 26 20:17 UTC 2005 |
I've made some (fairly simple) changes so that the 0.3.8 release will support
the "https" protocol. Once that is installed, here and on M-Net, Fronttalk
will again be able to access M-Net conferences from Grex.
|
cross
|
|
response 35 of 115:
|
Jan 26 21:47 UTC 2005 |
The only slightly annoying thing I've noticed about fronttalk is that
when I do a `forget' at the `RFP' prompt, I get returned to the `RFP'
prompt, whereas with Picospan, I got bummed to the next item or to the
`Ok' prompt. The picospan behavior made a little more sense to me,
but it's not a huge deal.
|
gelinas
|
|
response 36 of 115:
|
Jan 26 21:53 UTC 2005 |
Thank you for the explanation, Jan. I no longer need to "cs" when I finish
reading. :)
|
gelinas
|
|
response 37 of 115:
|
Jan 26 22:13 UTC 2005 |
(Can we change the error message to "SET SAVESEEN is not needed in
Fronttalk"?)
|
gull
|
|
response 38 of 115:
|
Jan 26 23:44 UTC 2005 |
Or perhaps, since fronttalk effectively always has saveseen set, it
should silently ignore 'SET SAVESEEN' and give an error on 'SET
NOSAVESEEN'.
|
remmers
|
|
response 39 of 115:
|
Jan 27 01:36 UTC 2005 |
Re #35: That behavior is a settable option in Picospan; "set stay" will
cause you to be returned to the RFP. Since that behavior is what I
prefer, I hadn't noticed that ft's default is different from pico's.
I wouldn't mind if ft's default behavior was the same as pico's, as
long as I could do "set stay" to change it.
|
janc
|
|
response 40 of 115:
|
Jan 27 02:18 UTC 2005 |
Oops, I had things a bit mixed up in my description above.
SET SAVESEEN or SET SEEN or CHANGE SAVESEEN or CHANGE SEEN
These do a one time save of the participation file. It's the "cs"
command Joe was talking about doing occasionally as he reads the
conferences. In "Fronttalk" they all give the message "ignored
in Fronttalk".
SET AUTOSAVE or CHANGE AUTOSAVE
Causes Picospan to do a save after each item is read automatically.
This is what I was talking about above. In Fronttalk, this option
is silently ignored.
SET NOAUTOSAVE or CHANGE NOAUTOSAVE
This turns off the autosave mode. In Fronttalk, this gives the
"ignored" message.
SET RELOAD or CHANGE RELOAD
Causes Picospan to reload the participation file, effectively
removing all record of what you saw since the last time you
loaded the participation file. In Fronttalk, this gives the
"ignored" message.
So, it already does pretty much what gull suggested it should do.
These options are all not very easy to implement in Fronttalk. What I
could do to get sort of the same effect is to have a SET NORECORD option.
If you set that, future reads would not be recorded in your participation
file, until you did SET RECORD again. This would be easy to implement, but
I'm not sure this is really a functionality anyone would care to use.
|
janc
|
|
response 41 of 115:
|
Jan 27 02:36 UTC 2005 |
SET STAY is another place I deviated from Picospan. Picospan had just the
STAY setting, Fronttalk has STAY and MODESTAY. In Fronttalk, SET STAY and
SET NOSTAY control whether you move to the next item after a RESPOND command.
SET MODESTAY controls whether you move to the next item after all other
commands: FORGET, REMEMBER, RETIRE, UNRETIRE, FREEZE, THAW, MARK SEEN, FAVOR,
DISFAVOR.
The default in Fronttalk is STAY off, MODESTAY on.
So what Dan wants is SET NOMODESTAY. Except that if he sticks that in his
.cfonce, then Picospan will probably complain every time he runs Picospan.
I really ought to have some mechanism by which you can put commands in rc
files that will be seen by Fronttalk but no by Picospan. The obvious option
would be a .fronttalkrc file. I'm not to enthusiastic about that. Fronttalk
already reads six RC files:
- remote system rc
- remote .cfonce
- local .cfonce
- remote conference rc file
- remote .cfrc file
- local .cfrc file
Do I want to add a local and remote .fronttalkrc file to that? No, I do
not. Maybe I could support a syntax where lines starting with '#ft#' are
not comments, like:
#ft# set nomodestay
I dunno.
|
janc
|
|
response 42 of 115:
|
Jan 27 03:05 UTC 2005 |
Hmmm. There is some weird Picospan semantics that I hadn't understood.
Suppose items 1 through 4 contain no new responses. Then
read 1-4 new - "No New Items Matched"
read 1,2,3,4 new - prompts for all four items.
read 1,2-4 new - prompts for item one only.
These were all equivalent in Fronttalk. I can't exactly duplicate this
functionality without significant changes deep inside Backtalk. I'm faking
it a bit. If there are any ranges (like 2-4) in the item list, then it
won't prompt for any items that have no new responses. Otherwise it will.
So the first two examples above would be the same in Fronttalk as Backtalk,
but in the last example Fronttalk will not prompt for any items. Of course,
an explicit "skip" or "noskip" on the read command will override the default,
but it's still all or nothing - can skip for some items and not for others
like Picospan can.
|
janc
|
|
response 43 of 115:
|
Jan 27 03:32 UTC 2005 |
OK, a few more clues on the problems with Joe's .cfonce file.
First, he does "set nosource" before "set supersane". SUPERSANE is supposed
to reset all options to compiled-in defaults. Which means that it turns the
SOURCE option on. Makes perfect sense. Except that that doesn't seem to
happen in Picospan. So I guess SUPERSANE should set ald
options to their
default except for SOURCE. I wonder if there are any other exceptions?
So the reason I wasn't having problems in "puzzle" and Joe was, had to do
with the fact that he was sourcing the puzzle conferences RC file, I wasn't.
Now one of the problems I was having when I was using his .cfonce file was
with this pager, which is set to "less -ME". My terminal is one that uses
an alternate screen when it goes into editors like "vi" and then restores
the original screen when you exit. The "less -ME" pager seems to display
on the alternate screen and then exit without prompting, so any output that
was going through the page would cause a barely noticable flicker of my
screen, as it switched briefly to the alternate screen to display something
an then returned to the main screen, with nothing displayed. Ick.
Getting rid of that, I see that Fronttalk isn't really hanging on entry to
the puzzle conference. It just seems to have set the prompt to a null string.
That's evidently some kind of bug in the parsing of the prompt setting
command that is in the puzzle conference rc file.
|