Sampsa Laine <sampsa at mac.com> writes:
Before this, I did an "xhost +" and ssh'd into RHESUS with X forwarding on.
{RHESUS$} create/term
X11 connection rejected because of wrong authentication.
X connection to _WSA48: broken (explicit kill or server shutdown).
X Error of failed request: BadConnection (fatal error on display connection)
Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 0
Current serial number in output stream: 0
%XLIB-E-ERROREVENT, error event received from server
Xlib: client uses different protocol version (11) than server (0)!
%DECW-E-CANT_OPEN_DISPL, Can't open display
Any idea what is causing this?
Server and version? (Assuming you're using your Mac? OSX ???)
VMS Arch/Versions? (Assuming a VAX? VMS V?.? TCPIP???)
Before this, I did an "xhost +" and ssh'd into RHESUS with X forwarding on.
{RHESUS$} create/term
X11 connection rejected because of wrong authentication.
X connection to _WSA48: broken (explicit kill or server shutdown).
X Error of failed request: BadConnection (fatal error on display connection)
Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 0
Current serial number in output stream: 0
%XLIB-E-ERROREVENT, error event received from server
Xlib: client uses different protocol version (11) than server (0)!
%DECW-E-CANT_OPEN_DISPL, Can't open display
Any idea what is causing this?
sampsa
On 06/01/2014 18:35, Johnny Billquist wrote:
On 2014-01-06 18:32, Paul_Koning at Dell.com wrote:
Sure, that would make sense. Color; sixel; other good things. But the first requirement would be strict conformance to the spec.
Yes, which pretty much rules out everything except xterm. :-)
xterm had DEC people involved, so I have at least some confidence that they might have checked it against some specs, and not just made up their own assumptions.
I had a good look at the xterm source code to see how difficult it would be to use it as the basis of a decent java-based terminal emulator.
'There be dragons' was as far as I got...
My second thought would be to write an simulation of a VT320 which was capable of running the VT320 ROM. That seems like a pretty good idea, but that's as far as it's got. There is an terminal emulator called VMSTAR in the Freeware V5.0 archive which some of you may remember - apparently this takes that exact approach.
SLAVE::ARCHIVE$:[MEDIA.DECUS.FREEWAREV50.VMSTAR]
Regards, Mark.
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/urbancamo
On 1/7/2014 12:57 AM, Sampsa Laine wrote:
Turns out Terminal.app has built-in support for the keys, being as it derives largely from xterm source code I believe.
Anyway, I've now got my frankenkeyboard for the occasional moments when I really need to edit a file on a VMS box..
Sampsa
Can you do an export of your terminal settings and post the files somehwere? I'd be interested in trying them out.
John H. Reinhardt
Turns out Terminal.app has built-in support for the keys, being as it derives largely from xterm source code I believe.
Anyway, I've now got my frankenkeyboard for the occasional moments when I really need to edit a file on a VMS box..
Sampsa
On 2014-01-06 18:32, Paul_Koning at Dell.com wrote:
Sure, that would make sense. Color; sixel; other good things. But the first requirement would be strict conformance to the spec.
Yes, which pretty much rules out everything except xterm. :-)
xterm had DEC people involved, so I have at least some confidence that they might have checked it against some specs, and not just made up their own assumptions.
As far as "colored terms with graphics" goes, I'm not sure what terminal emulators Sampsa would be thinking of. xterm definitely supports ANSI color sequences, as an extension, and like has been mentioned, there is now also Sixel support (although that is far from perfect yet). If we get that a bit more improved, soft fonts is not that far away afterwards, and then we'll have a proper VT220, and so on. I talked a bit with the person writing the sixel support about soft fonts a few weeks ago. It might happen...
Johnny
paul
On Jan 6, 2014, at 11:59 AM, Sampsa Laine <sampsa at mac.com> wrote:
Well if you're going to go through all that hassle, why not go for one of the coloured terms with graphics?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 6 Jan 2014, at 18:43, Paul_Koning at Dell.com wrote:
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
paul
On 2014-01-06 17:43, Paul_Koning at Dell.com wrote:
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
Actually, I think except for the soft fonts, xterm does VT220 pretty correctly too.
Johnny
I'd even pay for an emulator like this..
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 6 Jan 2014, at 19:32, Paul_Koning at Dell.com wrote:
Sure, that would make sense. Color; sixel; other good things. But the first requirement would be strict conformance to the spec.
paul
On Jan 6, 2014, at 11:59 AM, Sampsa Laine <sampsa at mac.com> wrote:
Well if you're going to go through all that hassle, why not go for one of the coloured terms with graphics?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 6 Jan 2014, at 18:43, Paul_Koning at Dell.com wrote:
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
paul
Sure, that would make sense. Color; sixel; other good things. But the first requirement would be strict conformance to the spec.
paul
On Jan 6, 2014, at 11:59 AM, Sampsa Laine <sampsa at mac.com> wrote:
Well if you're going to go through all that hassle, why not go for one of the coloured terms with graphics?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 6 Jan 2014, at 18:43, Paul_Koning at Dell.com wrote:
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
paul
Well if you're going to go through all that hassle, why not go for one of the coloured terms with graphics?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 6 Jan 2014, at 18:43, Paul_Koning at Dell.com wrote:
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
paul
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
The editing keypad etc work great out of the box on Terminal.app.
The one thing that annoys me is the location of the PF keys, which are mapped to F1-4.
Going to remap those later.
Sampsa
On Jan 5, 2014, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Sounds like an interesting project would be to do a proper VT2xx emulator (ideally from the DEC terminal SRM, if a copy can be found, failing that from published VT2xx manuals). Wx would be a good way to do that, since it s a very useable portable development environment. Or to make it even more straightforward, in WxPython?
paul
On 2014-01-06 11:22, Sampsa Laine wrote:
On 6 Jan 2014, at 00:05, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Sampsa Laine <sampsa at mac.com> writes:
Yeah, thinking of going that route, even though Xterm does look like =
crap and isn't really well integrated into the rest of OS X.
As a bonus, I'll get Erik's SIXEL support too..
What are you going to use it with?
I was actually just looking to get access to the editing + numeric keypad, which it turns out that both Terminal.app + iTerm have built in. So I'm just gonna stick with those - I don't know what I'm doing wrong, but I _STILL_ haven't found anything so buggy as to be memorable in 5+ years of using Terminal.app.
Might be different on the VMS version compared to RSX, but EDT in RSX sometimes use DECCOLM. At which point, your screen gets totally FUBAR using Terminal.app...
It'd be nice if it did SIXEL graphics, though, but again, I use those maybe once a year.
That's more often than I do. :-)
If VMS, you can't beat "$ CREATE/TERMINAL" if what you're seeking is DEC
terminal emulation.
With create/terminal you get into the fun of multiple clipboards again.
Yes, since that will once again be an X application, which works just like any other X application.
You need to setup a font server or copy the DEC fonts
to your MAc, create the font library and setup the path.
A simple, sane, user-friendly solution in the traditional Unix tradition :)
It is all very simple, and sane. You just have to try avoid using various proprietary solutions that mess things up... :-) It's when you mix those in that things becomes insane.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 6 Jan 2014, at 00:05, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Sampsa Laine <sampsa at mac.com> writes:
Yeah, thinking of going that route, even though Xterm does look like =
crap and isn't really well integrated into the rest of OS X.
As a bonus, I'll get Erik's SIXEL support too..
What are you going to use it with?
I was actually just looking to get access to the editing + numeric keypad, which it turns out that both Terminal.app + iTerm have built in. So I'm just gonna stick with those - I don't know what I'm doing wrong, but I _STILL_ haven't found anything so buggy as to be memorable in 5+ years of using Terminal.app.
It'd be nice if it did SIXEL graphics, though, but again, I use those maybe once a year.
If VMS, you can't beat "$ CREATE/TERMINAL" if what you're seeking is DEC
terminal emulation.
With create/terminal you get into the fun of multiple clipboards again.
You need to setup a font server or copy the DEC fonts
to your MAc, create the font library and setup the path.
A simple, sane, user-friendly solution in the traditional Unix tradition :)
Sampsa Laine <sampsa at mac.com> writes:
Yeah, thinking of going that route, even though Xterm does look like =
crap and isn't really well integrated into the rest of OS X.
As a bonus, I'll get Erik's SIXEL support too..
What are you going to use it with?
If VMS, you can't beat "$ CREATE/TERMINAL" if what you're seeking is DEC
terminal emulation. You need to setup a font server or copy the DEC fonts
to your MAc, create the font library and setup the path.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 01/05/2014 02:06 PM, Sampsa Laine wrote:
I am happy to use various tools if there's a sane reason to do it - however I fail to see any concrete benefit of using xterm over Terminal.app on OS X. Again, what is the show-stopping bug that should make me swap over?
Already answered that one, as far I am concerned. Your requirements might not be the same as mine, so you'll have to decide yourself.
Fair enough, so there isn't a specific issue, it's just vaguely "buggy"?
It's SPECIFICALLY "buggy". I end up shouting the word "FUCK!" a great
many times when I try to run EDT under Terminal.app.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 01/05/2014 01:44 PM, Sampsa Laine wrote:
Yeah, thinking of going that route, even though Xterm does look
like crap and isn't really well integrated into the rest of OS
X.
Looks like crap? Not sure I agree with that. It does not have a lot
of eye candy and similar drivel. Instead it just looks like a
terminal - which is what I think it should look like.
Ok, that's a tad harsh, but let's say it doesn't visually integrate
well with the rest of the UI. If I didn't care about this stuff I
wouldn't be on an OS X box, but seriously, the xterm UI is abysmal
(Want to change the font or say background colour? Oh, edit
.Xresources - WTF?!?).
Wow. You're a highly technical computer professional, and you can't
be bothered to...EDIT A FILE?
Wow. Just...wow.
For the ONE TIME you have to do it, it takes five minutes. I created
my .Xresources file probably twenty years ago and haven't touched it
since. It gets migrated from machine to machine, and everything JUST WORKS.
BTW, I ran OS X for many years...from 10.1 until 10.7 hit the streets.
(I never ran 10.7...I didn't go past 10.5 myself, because 10.6 really
started to suck and it seems to have gotten steadily worse from there)
For a long time, OS X was the best way to get a fast GUI-enabled UNIX
desktop machine. Sadly that time has passed, but when I was running it,
my X server started when the machine started up, and I ran X and native
OS X applications side-by-side with excellent integration via Xquartz.
Everything just worked, no complaints.
And Xterm didn't look all that different from Terminal.app. I wonder
what's so broken about your machine that it DOES look different.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 5 Jan 2014, at 21:09, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-05 20:04, Sampsa Laine wrote:
On 5 Jan 2014, at 21:00, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-05 19:46, Sampsa Laine wrote:
Does this resize the terminal window when you resize the window on OS X?
Not sure I understand the question.
Johnny
Ok, so I open up an SSH connection to CHIMPY.
1. Resize the window
2. SET TERM/INQ
3. Run EDIT
Terminal.app the new dimensions are used, xterm is still 80x25..
I'm sure there a really intuitive .Xresource somewhere that I need to set to enable this, but as I haven't been using xterm for 20 years like you mentioned before, I find this rather irritating (also, how DOES pasting stuff into xterm work anyway)?
Uh.. No... Since SET TERM/INQ do not tell the size of the window. And a VT100 cannot report such things that way, of course xterm can't either.
What you actually see/get in this case is that the resizing itself can be passed over the link between xterm and the ssh server. And yes, xterm can and will report the size change (assuming the conditions are correct).
If you want more details on how this works, and how things needs to be set up (assuming you are still interested in using xterm) send me a mail, and we can go through details outside the list. This is getting rather off-topic for HECnet. :-)
Yeah, don't worry - I won't be using xterm as simple stuff that works out of the box on Terminal.app seems to fail on xterm for me. I don't really have the desire or need to learn how to use it properly either :)
Now DTTERM, that's terminal emulator I want to get to know better.
Sampsa
On 2014-01-05 20:06, Sampsa Laine wrote:
I am happy to use various tools if there's a sane reason to do it - however I fail to see any concrete benefit of using xterm over Terminal.app on OS X. Again, what is the show-stopping bug that should make me swap over?
Already answered that one, as far I am concerned. Your requirements might not be the same as mine, so you'll have to decide yourself.
Fair enough, so there isn't a specific issue, it's just vaguely "buggy"?
Uh? No. I said "DECCOLM does not clear the window". Did you not see that mail? I can list a bunch of other bugs as well, if you really want to, but for me DECCOLM is a showstopper.
I'll stick to Terminal.app :)
Feel free.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2014-01-05 20:04, Sampsa Laine wrote:
On 5 Jan 2014, at 21:00, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-05 19:46, Sampsa Laine wrote:
Does this resize the terminal window when you resize the window on OS X?
Not sure I understand the question.
Johnny
Ok, so I open up an SSH connection to CHIMPY.
1. Resize the window
2. SET TERM/INQ
3. Run EDIT
Terminal.app the new dimensions are used, xterm is still 80x25..
I'm sure there a really intuitive .Xresource somewhere that I need to set to enable this, but as I haven't been using xterm for 20 years like you mentioned before, I find this rather irritating (also, how DOES pasting stuff into xterm work anyway)?
Uh.. No... Since SET TERM/INQ do not tell the size of the window. And a VT100 cannot report such things that way, of course xterm can't either.
What you actually see/get in this case is that the resizing itself can be passed over the link between xterm and the ssh server. And yes, xterm can and will report the size change (assuming the conditions are correct).
If you want more details on how this works, and how things needs to be set up (assuming you are still interested in using xterm) send me a mail, and we can go through details outside the list. This is getting rather off-topic for HECnet. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I am happy to use various tools if there's a sane reason to do it - however I fail to see any concrete benefit of using xterm over Terminal.app on OS X. Again, what is the show-stopping bug that should make me swap over?
Already answered that one, as far I am concerned. Your requirements might not be the same as mine, so you'll have to decide yourself.
Fair enough, so there isn't a specific issue, it's just vaguely "buggy"?
I'll stick to Terminal.app :)
Sampsa
On 2014-01-05 20:02, Sampsa Laine wrote:
Your problem is that you are too stuck in just one way of doing things. So I guess it makes more sense for you to use some OS X application. But I do know that all that I have tested (and that probably includes any you are trying to play with now) all are pretty buggy when it comes to actual functionality. They look pretty, but they are pigs, even if they have lipstick.
I am happy to use various tools if there's a sane reason to do it - however I fail to see any concrete benefit of using xterm over Terminal.app on OS X. Again, what is the show-stopping bug that should make me swap over?
Already answered that one, as far I am concerned. Your requirements might not be the same as mine, so you'll have to decide yourself.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 5 Jan 2014, at 21:00, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-05 19:46, Sampsa Laine wrote:
Does this resize the terminal window when you resize the window on OS X?
Not sure I understand the question.
Johnny
Ok, so I open up an SSH connection to CHIMPY.
1. Resize the window
2. SET TERM/INQ
3. Run EDIT
Terminal.app the new dimensions are used, xterm is still 80x25..
I'm sure there a really intuitive .Xresource somewhere that I need to set to enable this, but as I haven't been using xterm for 20 years like you mentioned before, I find this rather irritating (also, how DOES pasting stuff into xterm work anyway)?
Sampsa
Your problem is that you are too stuck in just one way of doing things. So I guess it makes more sense for you to use some OS X application. But I do know that all that I have tested (and that probably includes any you are trying to play with now) all are pretty buggy when it comes to actual functionality. They look pretty, but they are pigs, even if they have lipstick.
I am happy to use various tools if there's a sane reason to do it - however I fail to see any concrete benefit of using xterm over Terminal.app on OS X. Again, what is the show-stopping bug that should make me swap over?