[erlang-questions] erlang-questions Digest, Vol 24, Issue 15

[Johnny Billquist]

John Haugeland wrote:
>     Even getting colors is something that is totally dependant on what
>     kind of terminal (yes, *terminal*) you have. 
> 
> 
> Yes, that's exactly what I said.  That's why doing it in the language is 
> the superior strategy - it allows you to have per-console (no, not 
> terminal) output.
> 
> Why is it a console?  Because they're not all interactive.  Terminals 
> are two-way.  Consoles aren't, necessarily.

I don't even know what you mean by a "console" here. And I can't see the
point either.

>     Using a window on a windowing system (such as Microsoft Windows or
>     X-windows, or whatever) means that you have a terminal program
>     running, which do the actual visualization.
> 
> 
> Yes.  And they don't all use windows.  Windows erl.exe, for example, 
> uses the DOS console.  That isn't the same as using a window - windows 
> erl.exe will work in Windows 7's pure console mode, for example.

The DOS "console" as you call it, is a terminal window, just like any
other. There is no difference at all to any other terminal program.
You are confused.
However, the way you control a "DOS console" isn't neccesarily ANSI
compliant. Which just proves what I've said. However, it is controlled
some way, which the language (Erlang in this case) have absolutely
nothing to do with, and which isn't in any way tied to any specific
language at all, in fact.
(By the way, unless things have changed a lot, I wouldn't be surprised
if you can still load ANSI.SYS for a "DOS console" to get it to
understand ANSI control sequences.)

> The germane observation is that the language does not make any 
> guarantees about the user interface, and that as such anything which is 
> meant to be portable must be done in common ground.

Languages usually dn't even pretend to know anything about it. One
common ground, which the original replier referred to, was termcap,
which is such a common ground library for C.

>     *Erlang is in no way involved with this.*
> 
> 
> What?  Erlang is the only common factor in a group of undefined user 
> interfaces.  To suggest that erlang isn't involved in its own 
> input/output is silly.

Sorry, but you are confusing two different things here.
Input/output is one thing. Terminal control is another. Erlang is
involved in input/output. The original poster didn't ask how you do
input/output from Erlang. Please read the thread again.

>     However, almost all terminal programs have some way of controlling
>     them, and thus cause visual effects. 
> 
> 
> Not all of them.  And each are different.  Even so, you seem to be 
> making my point for me.

Except that you keep arguing against me.
And terminal programs without a way of controlling them are extremely
rare. I haven't seen any since the stone age. But if you can find one,
please let me know, it would be an interesting experience.

>     The exact way you get the terminal program to present the visual
>     effects you want is possibly unique for that terminal program. And
>     it is still totally outside of Erlang.
> 
> 
> Uh huh.  Which is precisely why any formatting must be done in Erlang, 
> to ensure that nobody attempts to ape a set of visual effects specific 
> to one platform.

Huh? Just because you think someone should write the code in Erlang
don't mean the problem as such has anything to do with Erlang.
It's like claiming that questions about how TCP/IP work is an Erlang
question.

Look at termlib to get a clue on what you are facing here, and how it
could be solved. It requires a *huge* database of different terminals,
how to control them, and what they can do, in combination with a big
library to present an abstract API for the program to use, which in the
end will cause something similar to appear at your terminal independent
on what terminal you might have.

Now, if what you are actually saying is that someone should write a
termlib-like library for Erlang, I certainly won't argue with you. I
suspect quite a few people would be happy if one was written.
That don't change the fact that what the original poster asked for was
how to clear the screen and move the cursor. And that is not an Erlang
problem, since Erlang don't even pretend to have an API for screen handling.

>     All that being said, there is an ANSI standard, which many terminal
>     programs implement, 
> 
> 
> Neither the modern Windows console nor the default Linux BASH 
> environment honor ANSI codes.

Bullsht. BASH is a shell. A shell don't even care about what ANSI
control sequences your program output, since your shell isn't even in
the loop when your program do I/O.
Second, what on earth do you think a shell would do, or care, about what
characters a program output??? Play stars and stripes???

In Linux, you run bash in a window. That window is what is concerned
about those ANSI codes, not bash.
And if that window is an xterm window, it will honor those ANSI control
codes. If we're talking about what I suspect you think when you say
"console" which is a terminal "window" which isn't in a graphical
environment, the console driver for Linux is actually ANSI compliant, so
it will work fine even if you run under Linux without running the
X-windows system, or a terminal program there under.
The "console" is actually also a terminal program. Just one that is
provided by the operating system. But it takes keyboard input, and pass
it on to whatever program is running inside, and it takes whatever
characters that is output by the program, parse them, and display
something on your screen. That parsing also means it grabs ANSI control
codes, and do other things with them.

>  The VT standard, which is not the same as 
> ANSI codes, would be a marginally better choice, but the reason that's 
> actually a bad choice was already discussed.

The "VT" standard you talk about is, I assume, the DEC extensions to the
ANSI standard (extensions which are perfectly legal by the ANSI
standard, by the way). Since they will be the same for the question
asked I fail to even see the point in making the distinction here.

The question of "bad choice" seems weird as well. You play the cards you
are dealt. If you have a terminal that is ANSI compliant, you better
send the codes that do the right things according to that standard. "Bad
choice" hardly seems an appropriate comment.

It is however questionable if I should have written down those codes in
the first place, since it is not even known if the terminal used by the
original posted is ANSI compliant, and so the information may as well be
meaningless for him.

>     which means that if your terminal program follows this standard, 
> 
> 
> What terminal program do you believe is involved for Windows users?  
> Answers which aren't suitable outside Unix aren't suitable period.

There is no one answer. There isn't one terminal program that runs on
everything.
But if you run windows (for instance) you normally get a terminal window
as soon as you run CMD.EXE. That terminal window is doing the processing
for you, including processing control codes, and making "strange" things
happen. For instance, if you send a ^H to that window, it will move the
cursor one character to the left. How do you think that happened?
Now, it might not be ANSI compliant, but that just goes back to the
original problem and answer. The original problem was: I want to clear
the screen and move the cursor to the top left.
The original answer: this is not an Erlang problem, but a question of
what terminal you have, and how you control it.
Erlang itself can output the characters, but exactly what characters you
should output is not something we can answer straight off, and it is not
really an Erlang problem.

Now, if it turns out that the original poster is running inside a
terminal program that don't even have functions to do the requested
operations, then he is smoked, but that's not Erlangs fault either.
If doing the operations would require doing something else than just
outputting bytes to the screen, then Erlang can't do it either, since
Erlang don't have the ability to do anything else (such as poking at
specific bytes in memory to get something to happen on screen).

It all still boils down to that this is not an Erlang problem. It's a
problem of how do he control his terminal, and is the terminal capable
of performing the actions requested.

>     the way to get the wanted effects are well known, and can probably
>     be answered by a whole bunch of people reading this list.
> 
> 
> Yes.  Including me.  But it's a bad strategy, so nobody will.  There's a 
> reason HIPE tools don't get used much in production code.  Things that 
> are tied to one platform are fundamentally broken.

Erlang I/O isn't tied to a specific platform. However, the original
posters code will most likely be tied to a specific platform if he were
to write it, since I doubt he'll implement termlib.

>     But even so, we don't even know what kind of terminal the original
>     posted is using, so we can't even make a proper answer based on that
>     standard, because it might very well not be something that will work
>     for him.
> 
> 
> Yes, that's exactly what I said.

I must admit that I mostly saw that you claimed that this was an Erlang
problem, which it definitely is not.

>     Sorry, but you uninformed reply really pissed me off. 
> 
> 
> So much that you agreed with it, it seems.  You haven't actually said 
> anything that disagrees with me.

Really???

>     But making totally bogus claims
> 
> 
> Such as?

"This is an Erlang problem".

>     and trying to shoot down someone who gives a correct answer is just
>     plain wrong. 
> 
> 
> I haven't shot down someone who gives a correct answer.  I've shot down 
> someone who gave a unix-specific answer when there are better available 
> approaches which are well known to people who are willing to do the 
> small amount of extra work it takes to keep a portable language portable.

No. The answer wasn't Unix-specific. And that is your problem. You
couldn't see that what he gave was the whole, total, and correct answer.
That it isn't an Erlang problem, and that it depends on what terminal he
is using.
What he might have liked would be something like termlib, which solves
that very same problem, but termlib is for C, so it isn't really useful
for an Erlang program.

> I haven't actually seen you point out anything I said which was wrong.  
> All you seem to want to do is repeat the things I said, come to the 
> conclusion I came to when saying "here's what you would do if you were 
> willing to limit yourself to Unix", then get all nasty in public.

Okay. Let's put it this way then. What was Unix-centric in anything that
was written in any reply?

>     And for some totally unkown reason (to me), you think that it is
>     Erlang that should have the answer. Geez. 
> 
> 
> Probably because of the things I've already explained several times: 
> it's the only common factor among a set of undefined terminals, and I'm 
> not willing to accept a naive, unix-only solution from naive, unix-only 
> people.

Which is?
The answer I've seen is that Erlang isn't involved in the issue. It's a
question for your terminal.

How on earth can you get that to be Unix-centric in any way???

>     Maybe I should direct all the people on NetBSD-current here as well,
>     when they pop this question.
> 
> 
> That's okay: I'm on that mailing list too.  Being on an operating system 
> specific mailing list doesn't actually teach you much about how to 
> handle things in an operating-system portable fashion, as a general rule 
> of thumb.

Good. Then you should have seen the answer I made on this very same
subject on that list less than a month ago.

>     And, as a friendly gnome, 
> 
> 
> You seem to be confused about the nature of the word "friendly." 

I probably am. :-)

>     I'll provide the answer for when he really is using a terminal that
>     is ANSI compliant:
> 
> 
> Wow, a repetition of the answer other people already gave, including the 
> person you're yelling at for not giving answers. Bravo.  By the way, 
> those are actually VT codes, not ANSI.  ANSI requires escape bracket; 
> CSI is only supported by the VT terminal series.

Huh? Where did you get that?
Utter nonsense! Just because you might have used a terminal program that
claimed to be ANSI compliant, and yet didn't support CSI don't mean the
standard don't specify it.

See http://en.wikipedia.org/wiki/ANSI_escape_code for some education.
There you'll even find how to get your precious "DOS console" to
understand those darned ANSI control sequences.

>     I could go on for quite a while about this, but maybe you should
>     read a manual instead?
> 
> 
> Yes, I'll get right on reading a manual about the thing I already 
> suggested.  Because clearly I didn't know about it, which is why I knew 
> its correct name when you didn't.  And the fact that I've already panned 
> it for important reasons, and provided a portable alternative?
> 
> Really, dude, you shouldn't get that high up on your horse.  It hurts 
> worse when you fall.

Indeed.

>     And this is still totally not related to Erlang, and you'd send the
>     same control sequence if your program was written in C, Perl,
>     Haskell, Lisp, Prolog, Assembler, Basic, Pascal, FORTRAN, Cobol,
>     Snobol, Algol, Dibol, Focal, Python, Java, or God knows what else,
>     if your *terminal* was ANSI compliant.
> 
> 
> Wow, you really don't understand the idea that requiring terminal code 
> scanning breaks three out of the four existing consoles, do you?
> 
> This is the Unix specific part that isn't acceptable.  Your strategy 
> would require people to log in over SSH or Telnet for their stuff to 
> work correctly.  The windows shell wouldn't work.  The Dos shell 
> wouldn't work.  The stream Unix shell wouldn't work.

And you are wrong on all accounts, and that's even without still
pointing out that this is not an issue with Erlang.

> We get it: you really like the idea the rest of us already discussed 
> before you spoke up.  No need to get all "omg i'm so right and you need 
> to read a book" about it. Turns out you aren't as far out ahead as you 
> think you are.  At least read enough of the manual you're talking about 
> to know the name of the coding scheme you're trying to discuss. 
> 
> 
> 
> 
>  
> 
>     If that shouldn't make it obvious to you that it is not related to
>     the language, but to the terminal, then I don't know what would.
> 
> 
> Yes, the scheme you have which is unacceptably tied to a unix 
> environment isn't about the language.  Wow.  Bravo.  By killing all but 
> one terminal, you've made it a terminal issue.

I haven't killed any terminal, and if you are so hung up about Unix, you
should atleast know that this is a long standing problem with Unix, and
the reason termlib exists. *All* terminals are supported under Unix.

But that don't help Erlang much, because Erlang is not Unix.

*Sigh*
This is really turning into an idiotic argument against somemone who
don't know, but really thinks he do.

> Any /_*acceptable portable solution*_/ cannot be required to support the 
> things you expect to gain from a telnet/ssh connection.  That's why your 
> solution is unacceptable.  Any solution which requires the support of an 
> intermediary communications application is fundamentally broken.  You've 
> broken anything that doesn't work through a Unix terminal, then used 
> that to justify calling it a terminal problem.

Start over, will you? And learn how things actually work. And stop
bashing Unix, because this really have nothing to do with Unix.

> But, for those of us who don't use Erlang through ssh/telnet, your 
> solution is not only broken, but introduces a ton of unnecessary noise 
> into the console which damages the language's fundamental usability.
> 
> That's why _/*a correct, console portable solution*/_ cannot rely on 
> third party intermediary tools which aren't even usually there.
> 
> Your solution is a terminal solution, yes.  But that doesn't mean the 
> problem is a terminal problem, and the fact that it isn't shows more 
> mature engineers who know what portability is why the solution you're so 
> bent out of shape about isn't adequate.
> 
> The funniest part is that a portable, language level solution would 
> probably rely on the strategy you're discussing for the Unix interactive 
> shell implementation. 
> 
> No solution which cuts away 75% of the existing consoles is acceptable.  
> Emitting VT protocol noise because you're assuming a VT connection might 
> maybe be there, ignorant of how it affects (and potentially damages) 
> existing systems, is the hallmark of poor design.

And I pointed out from the start that the first answer was correct.
There is no way we can give an answer, since we don't know what terminal
he is using.
And Erlang don't provide a solution for him.

> If you choose to reply, please mediate your tone.  I don't like being 
> talked down to by someone who doesn't understand that they're playing 
> catch-up.

If it was only that easy.
The short of the story is that you obviously don't know what you are
talking about, and this post have only made it painfully obvious.

And if I understand you right, your answer to the problem is that Erlang
should implement terminal independent functions to do terminal handling.
A problem that is close to impossible to get right, and which is also
inherently extremely difficult to move between different platforms.
Not to mention that it don't exist.
That is what I would call an uninformed answer.

All I can see here is uninformed Unix bashing, on something that you
appearantly don't know how it even works in Unix. Heck, you don't even
seem to know how it works in Windows, or even in DOS.

Sorry, but no. I don't think I'll mediate my tone. Your post was
uninformed, pointless and misleading to people. And full of bullshit.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@REDACTED             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol