Author Topic: Ask: Control Character: Backspace to erase the last character printed  (Read 6755 times)

0 Members and 1 Guest are viewing this topic.

BlackBox

  • King Gator
  • Posts: 3770
Re: Ask: Control Character: Backspace to erase the last character printed
« Reply #15 on: September 11, 2011, 10:19:28 PM »
Similar to the "Initializing..." message displayed with AUTOLOAD function.
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Ask: Control Character: Backspace to erase the last character printed
« Reply #16 on: September 12, 2011, 03:25:05 AM »
Yep, the \r (carriage return) can be seen as analogous to an old typewriter moving back to the start of a line. The \n new line is usually followed by that. Actually that's exactly what they do when sent to a printer (at least those old dot-matrix / daisy-wheel stuff).

The difference though is when you use \r on a screen you overwrite what was already on the line. Effectively erasing as you fill in new stuff. Usually it doesn't cause problems, though in the old days you tended to see flickering as the line of text got redrawn.

So back then it was a bit less processing to just backspace one char and replace just that one. On windows it doesn't make much difference since an update to one char invalidates the entire command palette in any case - thus cause a redraw of its entirety. It's just that the new hardware's so much faster at displaying these updates that you won't notice the difference between \r and \010.

Another place it was used quite often was to show a running counter which would backspace over the number portion of the message. Then replace just that with the new value. But again, these days it's not necessary. Though I'm starting to sound as if I'm advocating something I despise about current programming laxity: back in the 70's & 80's programs tended to be as efficient as possible. Since around the 90's programmers tended to say: "The hardware's fast & large enough, we don't need to worry so much about keeping it small and efficient."

It's just that in this particular case, it makes no difference which one you choose. You're stuck with the way windows updates its display, so changing one character or the entire line has the same processing & update effect.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

BlackBox

  • King Gator
  • Posts: 3770
Re: Ask: Control Character: Backspace to erase the last character printed
« Reply #17 on: September 12, 2011, 06:13:25 AM »
Though I'm starting to sound as if I'm advocating something I despise about current programming laxity: back in the 70's & 80's programs tended to be as efficient as possible. Since around the 90's programmers tended to say: "The hardware's fast & large enough, we don't need to worry so much about keeping it small and efficient."

I *heart* Apply, Lambda, and Mapcar. :-D LoL
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Ask: Control Character: Backspace to erase the last character printed
« Reply #18 on: September 12, 2011, 11:09:26 AM »
I definitely like those too. They save a lot of programming  8) ... but when used in the correct places they don't necessarily make for "inefficient" programming. In Lisp they're actually quite efficient in themselves, it's when you try them in something like C# (which has to load the entire Linq libraries simply to use such constructs) when the overhead comes to play.

Actually even in those days-gone-by these functions were used in extremely efficient programming. Even to the point where it became an art-form  :lmao: . It's usually a case of the optimization is handled by the compiler / interpreter in such a way as to make for more efficient running code.

E.g. using a while loop with a counter variable extracting from a list of strings and running strcat to concatenate them all together would not only be a lot of typing, but would use at least twice the amount of RAM and probably be slower than simply using apply:
Code: [Select]
;; Iterative strcat of list
(defun strcat-list-1 (lst / str n)
  (setq n (length lst) str "")
  (while (> (setq n (1- n)) -1)
    (setq str (strcat (nth n lst) str))
  )
  str
)

;; Iterative strcat of list - using foreach
 (defun strcat-list-1a (lst / str)
   (setq str "")
   (foreach item lst
     (setq str (strcat str item))
   )
   str
 )

;; Recursive strcat of list
(defun strcat-list-2 (lst / )
  (if (cdr lst)
    (strcat (car lst) (strcat-list-2 (cdr lst)))
    (car lst)
  )
)

;; Minimal version using apply
(defun strcat-list-3 (lst / )
   (apply 'strcat lst)
 )
And the test:
Code: [Select]
_$ (setq lst '("This" " " "is" " " "a" " " "test."))
("This" " " "is" " " "a" " " "test.")
_$ (benchmark '((strcat-list-1 lst) (strcat-list-1a lst) (strcat-list-2 lst) (strcat-list-3 lst)))
Benchmarking ..................Elapsed milliseconds / relative speed for 32768 iteration(s):

    (STRCAT-LIST-3 LST)......1141 / 1.47 <fastest>
    (STRCAT-LIST-2 LST)......1313 / 1.27
    (STRCAT-LIST-1A LST).....1390 / 1.20
    (STRCAT-LIST-1 LST)......1672 / 1.00 <slowest>
So you can see the recursive & foreach are close. But the while is slow as molasses. The apply is a lot faster in comparison.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.