|
|
| Author |
Message |
| 25 new of 115 responses total. |
cross
|
|
response 44 of 115:
| 
Jan 27 04:05 UTC 2005 |
It's all right. I don't plan on running picospan ever again.
As regards strict picospan compatibility: one has to ask if, at
some point, that's really all that desirable. Who cares if some
esoteric thing is different between picospan and fronttalk, when
picospan is only on life support until you can get the bugs
worked out of fronttalk?
|
gelinas
|
|
response 45 of 115:
|
Jan 27 04:29 UTC 2005 |
The person who was depending upon that esoterica cares, obviously. ;)
|
janc
|
|
response 46 of 115:
|
Jan 27 04:50 UTC 2005 |
Joe's answer is exactly right. Fronttalk exists to provide continuity for
those who know and love Picospan. The range of Picospan features that are
used by *some* users here turn out to be pretty broad, including things that
I never use and didn't know existed. I'm not adverse to asking a few users
to make mild adaptations to slightly different syntax and semantics in places
where it makes sense to do so, but mostly I'd like the transition to Fronttalk
very smooth for people, and not give them the feeling that they are giving
much up when they make it.
|
janc
|
|
response 47 of 115:
|
Jan 27 04:55 UTC 2005 |
The problem with the puzzle conference rc files looks like a much bigger bug
than any other I've seen recently in Fronttalk. When you join a conference,
things like prompts can be set by the system RC file. When you leave the
conference, they are supposed to revert to the previous definition. Fronttalk
isn't reverting them right. When the revert they go blank. I don't think
Fronttalk is even remembering the previous definitions. I'm going to have
to do some slightly more complex programming to get this working right. At
the moment I don't even really remember how that code works.
|
gelinas
|
|
response 48 of 115:
|
Jan 27 05:02 UTC 2005 |
Yeah, I just discovered that, myself, when I went from puzzle to agora.
|
davel
|
|
response 49 of 115:
|
Jan 27 13:44 UTC 2005 |
This is a pretty minor bug - if "bug" is the right word. It's certainly a
difference from picospan's behavior. I normally do "n;r" to go from one
conference to the next (in my .cflist). In ft, this results in:
> Ok: n;r
> I don't understand "n;r" - type HELP for help
Is there a reason ft understands that "n" is "next" and "r" is "read [new]",
but that it doesn't understand them together? (Um. A *good* reason, I mean.)
|
janc
|
|
response 50 of 115:
|
Jan 27 15:02 UTC 2005 |
I didn't know you could put multiple commands on the same line in Picospan.
Fronttalk doesn't do anything with semicolons.
The issue with defines and conference RC files had to do with reverting
definitions when leaving a conference. I had misunderstood how this works
in Picospan. I'd assumed that if you defined "prompt" to something before
joining a conference, and the conference rc file defined it to something else,
it would change to the new value, then revert to the old value when you left
the conference. This requires keeping the old value around someplace.
What Picospan actually appears to do is only keep around compiled-in default
values and current values. If a conference RC file tries to set "prompt" to
something new, it will only work if there is no previous value (except the
compiled in default). When you leave a conference, it erases values that were
set by the conference RC file, always reverting them to the system default.
So on Grex, since the system RC file defines the "isep", no conference RC file
can do so, unless the user has done set supersane first. (Hmm...I wonder if
a conference RC file can "set supersane" or undefine isep). All rather
strange and obscure.
|
janc
|
|
response 51 of 115:
|
Jan 27 15:23 UTC 2005 |
Fascinating. Conference RC files *can* do "undef prompt" and "set supersane".
So normally if the user or the system rc file has defined the prompt, the
conference RC file can't override them. Unless the conference RC file does
"undef prompt" before defining it to a new value, in which case they can
override the old value. However, if they do that, then when the user leaves
the conference, the prompt reverts not to their previous value, but to the
compiled in default value.
|
remmers
|
|
response 52 of 115:
|
Jan 27 18:48 UTC 2005 |
Oh yes, semicolons. I'd miss that feature. For example, at the RFP
prompt I like to do "h;only 0" to see the item header and text.
|
gelinas
|
|
response 53 of 115:
|
Jan 28 12:38 UTC 2005 |
I just discovered that fronttalk is more forgiving than picospan. I had
the following line in my .cfonce:
} define cs 1 "unix echo 'SET SAVESEEN is not needed in FrontTalk.'""
Fronttalk was happy with it, but picospan complained about the extra
double-quote at the end of the line.
|
remmers
|
|
response 54 of 115:
|
Jan 28 14:28 UTC 2005 |
I assume that piping to Unix commands isn't practical to implement in
FT, due to the architecture.
|
janc
|
|
response 55 of 115:
|
Jan 28 21:19 UTC 2005 |
Depends on what you mean. Certainly the unix command you pipe to would have
to be on the local server. We already pipe to the pager.
|
gelinas
|
|
response 56 of 115:
|
Jan 30 00:42 UTC 2005 |
FrontTalk does not properly the number of lines in item texts and responses:
It always claims there is but one line.
|
gelinas
|
|
response 57 of 115:
|
Jan 31 02:39 UTC 2005 |
Ok: w
who - NOT IMPLEMENTED
Ok:
|
remmers
|
|
response 58 of 115:
|
Jan 31 13:54 UTC 2005 |
How does one "ignore" a user in FT?
|
janc
|
|
response 59 of 115:
|
Jan 31 15:37 UTC 2005 |
Number of lines in texts and responses: I'll need to check into that.
Who: Here's the problem. Suppose you are logged into Grex, running
"ft mnet:general". You type "who". Which system's users should be listed?
Now mentally speaking you are "on" M-Net, seeing postings by M-Net users
and reading M-Net items. So ideally, "who" should list M-Net users, and
"!who" should list Grex users. Getting the list of M-Net users is mildly
complex. The fronttalk client would have to ask the backtalk server to
run the "who" command and pass the result back. Not really too hard.
But, now, having seen someone you want a word with logged on, you do
"write tod". Are you writing "tod" on M-Net or Grex? If on M-Net, then
we are going to have to use the "talk" program instead of "write". "Talk"
isn't even enabled on most servers these days. This is overall quite a mess.
The "mail" command has similar issues. Should the mail be sent from your
local system or from the remote system? Backtalk actually has a full-blown
mailer built into it, so having the server send the message would be pretty
easy. Without arguments "mail" reads mail. Which system's mail?
So probably I don't really want to get into any of this. All these
commands should just act on the local system. "write" is an alias for
!write and so forth. I guess.
Ignore: Fronttalk should probably tie into the Backtalk ignore lists.
It doesn't yet. However it should be possible to use the same twit
filter programs with Fronttalk that people are using with Picospan.
Eventually I do want to make Backtalk's built in "ignore" lists work
for both Backtalk and Fronttalk. However, I also want to do substantial
reworking of the way ignore lists are implemented in Backtalk. I want it
to be possible to much more thoroughly ignore people, so that items that
have been responded to only by ignored people don't come up new until
at least one not-ignored person responds to them. So I'm not planning
ignore support in Fronttalk until after I have it updated in Backtalk.
|
janc
|
|
response 60 of 115:
|
Jan 31 16:32 UTC 2005 |
OK, I've installed Fronttalk 0.9.0.
The rather big jump in version numbers from 0.3.7 to 0.3.8 is mostly just
catch-up. It started with very low version numbers to hint that it was
very far from production usability. We are getting close now, so we need
version numbers closer to 1.0.0.
However there are quite a lot of changes in this release.
- https protocol support. If M-Net upgrades their version of Fronttalk
then it should once more be possible to M-Net from Grex. Actually,
I'm not sure that the Perl package needed to do this is installed on
Grex (Crypt::SSLeay or IO::Socket::SSL). Need to check that.
- Define handling code has been substantially rewritten to handle
defines in conference RC files correctly (or at least Picospanishly).
- It is now possible to put multiple commands on the same line by
separating them with semicolons. It is not possible to put
semicolons in macro definitions though (which does work in Picospan).
For now, you'd have to create a file with the commands in it and
define a macro to source the file.
- Environment variables can now be set with "define name 256 value".
Note that in Fronttalk, as in Picospan, the name will always be mapped
to all upper case. It is not possible to define an environment
variable containing lower case letters in either program.
- The commands "enter" and "echo" now work at RFP prompt as well as at
OK prompt.
- There are now "skip" and "noskip" options that can be put on a "read new"
command. These tell whether or not to give an RFP prompt for items that
have no new responses. The default is skip unless a explicit list of
items is given on the command with no dashes in it. So "read 1,5,7 new"
will not skip, but "read new" and "read 1-4,7 new" will.
- After a "server" command is done to change servers, the old server's
rc definitions are unloaded and the new server's are loaded. Defines
are also reloaded if you were reading anonymously, but did "login"
to log in as a user.
- The "." and "curr" terms in item ranges should now correctly track the
last item read.
- In Picospan and previous versions of Fronttalk, "define name" undefines
name. I think this sucks, especially since there is a perfectly good
"undefine name" command around. So in Fronttalk 0.9.0 "define name"
prints the current definition of name instead of undefining it. This
may not be compatible with Picospan, but it's compatible with everything
else.
- Fixed bug where "set sane" and "set supersane" sometimes terminated
execution of a script. Fixed "display modestay".
- When users who are reading anonymously attempt to respond or enter, give
error message immediately, not after they have entered response text.
- Implemented various other Picospan commands:
source file
leave
resign
set resign
set default
set nomesg
Fronttalk does not have an observer mode like Picospan does. Nearest thing
is an anonymous reading mode, which isn't really the same thing and doesn't
work if you are reading Grex from Grex. I'm not sure if this is worth
implementing.
|
janc
|
|
response 61 of 115:
|
Jan 31 18:38 UTC 2005 |
Starting work on the next release. Fixing the %s tab in rseps is
pretty easy - really just a typo preventing it from working. By the
way, Joe, you might want to do " %s line%S " in your rsep and isep
definitions. This will cause it to say "1 line" instead of "1
lines".
The line count in isep is trickier. Iseps format the header printed
at the top of the item. They are also used in "browse long" and a
few other places. The problem is that we frequently display it
without the item text, like in "browse long" or "read new". When
that happens, Fronttalk doesn't bother to fetch the item text from
Backtalk. And if it doesn't have the item text, it certainly
doesn't know how many lines or bytes of data are in it.
I could have Backtalk always read in the item text and always count
the number of lines in it. But this is a lot of extra overhead just
for the few users who use %s in their isep. What I'll probably have
to do is have Fronttalk precheck the isep to see if there is a
directive in it like %s and pass an flag to Backtalk asking it to
return the extra data for each item. Kind of a lot of work to
support such a trivial feature, but I guess I'm stuck with it.
|
janc
|
|
response 62 of 115:
|
Jan 31 20:20 UTC 2005 |
Hmmm...the "scribble" command in Picospan causes a core dump.
|
cross
|
|
response 63 of 115:
|
Feb 1 01:00 UTC 2005 |
Awesome.
|
janc
|
|
response 64 of 115:
|
Feb 2 05:32 UTC 2005 |
Installed Fronttalk 0.9.1
Some of the more nearly noticable changes include:
- If your iseps/rseps display the number of lines or bytes or kilobytes
in each response, this should now work correct. This was actually
fairly tricky to get to work right.
- The default behavior is now to flag responses as "hidden" instead of
"censored" and "erased" instead of "censored & scribbled". This
agrees with the prefered Backtalk terminology. It would be possible
to write rseps/iseps that restore the old terminology if you really
want to.
- Display of <hidden> and <erased> flags in iseps was broken. It is now
fixed, but slightly different from Picospan. Since these flags refer
only to the text of response zero, not to the whole item (as <frozen>
does), they are only included in iseps if the isep would otherwise
be followed by the item test. So if you do a "browse long" or if
you are reading and response zero is not new, then these status flags
are not displayed for the response that we weren't going to display
anyway.
- In source files like (your .cfonce for instance) lines starting with
#ft# are NOT treated as comments. This allows you to include fronttalk
specific commands in files that are also used by Picospan, which, of
course, will treat lines like this as being commented out:
#ft# set nomodestay
- The "set password" command now works. When reading Grex conferences
from Grex, it just runs the Unix !passwd program. If you were reading
HVCN's conferences from Grex, then it would change your Backtalk
password on HVCN. If it you were reading M-Net's conferences from
Grex, then it wouldn't work, because M-Net, like Grex, uses real
Unix accouts for Backtalk, and and Backtalk doesn't have the capacity
to change real Unix passwords.
- The "who" and "write" commands now exist. They just execute the local
!who and !write commands.
|
remmers
|
|
response 65 of 115:
|
Feb 2 14:02 UTC 2005 |
With the new version of FT, my Picospan twit filter now works. Cool.
(Can't get the builtin "ignore list" facility to work in backtalk though.
Sent you mail.)
|
remmers
|
|
response 66 of 115:
|
Feb 2 14:05 UTC 2005 |
Are pipelines on the list of things to be implemented? e.g.
browse all | grep -i iraq
|
davel
|
|
response 67 of 115:
|
Feb 2 15:42 UTC 2005 |
Hmm. I hadn't noticed that, John, but I sure would the first time my
participation file got garbaged. I'd be trying
read all > /dev/null
which doesn't work.
|
remmers
|
|
response 68 of 115:
|
Feb 2 17:34 UTC 2005 |
Hadn't noticed what?
|