TERMINAL view still does not work

[compsystems]

Excuse me for my bad english

No scroll the screen, is fixed, and similar programs to the next fail, only at the end of the program the screen can be scrolled

PHP Code:

EXPORT p9_while_loop_block()
BEGIN
  local n; 
  n := 1; 
  while n <= 20 do
    print(n); wait;
    n := n+1;
  end;
  return "Done";
END; 


PHP Code:

hpprime source code: File: p10_for_loop_block.hpprgm    
EXPORT p10_for_loop_block()
BEGIN
  local n; 
  n := 1; 
  for n from 1 to 20 do
    print(n); wait;
  end;
  return "Done";
END; 


¿solution or correction is in list for next firmware version?

a way of presenting the data is consecutive screens or one with scroll

[smp]

Yes, that is the way mine operates, as well. I thought that was normal operation?

smp

[StephenG1CMZ]

You might find the program "Terminal alternative" in the HP Prime library helpful.

[sbergman27]

Let's call a bug a bug. Just because many bugs have been in Prime firmwares for 27 months does not make them "normal operation". I look at my incredibly buggy Prime. And I see all the pats on the back here to the "great" Prime team. And I just have to say "Norman, coordinate!". How standards have fallen in the HP Calc world!

[cyrille de brébisson]

Hello,

Prime is single threaded, this means that it can only do one thing at a time.
In this case, while it is processing/executing your program, it can not handle UI event (touches/key presses). This is why you can not scroll the terminal while your program is running.

Cyrille

[sbergman27]

The Apple ][ was a 1 MHz 8 bit machine that could handle a maximum of 62K of memory, which ran a single threaded OS, and it could do the simple thing that compsystems desires. Nobody even considered it to be a "feature" worth mentioning. It was simply expected. I'm not sure where "single-threaded" equates to "can't scroll program results on a screen". If the screen output needs to become part of the interpreter, or VM, or whatever the Prime uses, then so be it.

[smp]

I think there are two different instances of scrolling being talked about here.

Cyrille is talking about the fact that one cannot touch the screen and get it to scroll while a program is running. This is because of being single-threaded, I guess.

Compsystems is asking why the Terminal screen cannot scroll with more output lines than one screen's worth, while the program is running.

This last instance is being called a bug, right? I've run into this, too (as I said previously). And I would also like to see the Terminal screen act like a terminal screen and scroll with ever how many lines of output it receives, rather than apparently freezing when the screen is full, and not providing any more of the output to be seen until the program has finished.

smp

[Tim Wessman]

Yes, the OS has no problems with your comment re the apple2.

What is really going on here is that the OP wants to do this:

//execute code
PrintToTerminal(...)
//pause here and wait for the user to do some stuff on the terminal
//execute more stuff
PrintToTerminal(...)
//pause here and wait for the user to do some stuff
//continue running

In a simple user function, that type of construct is not allowed because there is no way for a user program to do things like have a UI thread handling touch in the background while the function is running (that is where the single threaded comment came from). The terminal is not really a true terminal (it doesn't accept user input/editing for example), but for lack of a better word to describe it - it was dubbed the terminal. In order to support this, the options need to be built into the "Print" command, or provide a fully "handle system input" command that lets the user create a true system type loop. Both of those are on the list of future enhancements, but are not there right now.

Trying to use "wait" to stop and take input from the user despite that not being close to what the command does, how it is explained in the documentation, or is meant to be used for. Its just like using SIN instead of ATAN simply because "they are both trig functions so they should all do what I expect".

Chances are it will be improved at some point with more capability and options at some point in the future (2d output, input, control of scrolling, etc), it just hasn't been that high of a priority. It always comes down to the question of balancing time and resources against benefits. No matter what we pick, someone's "most critical feature" is not going to match the list.

[DrD]

I have several programs that use PRINT() to terminal, for output. I have a few programs that require more 'control' than the terminal mode provides, and for those I use graphics mode commands, based on grobs.

Realizing that there is no scroll mode, per se, my current goal is to just manage the terminal content using the page mode constraints. Until a more robust terminal mode can be provided, I 'd prefer to remain status quo, without further interim, or temporary, changes to the terminal feature. This will help keep consistent operation between existing and future programs; some of which get called upon to work together, as sub programs, for a larger project.

If more control than is provided in the existing terminal set is required, advanced users might be able to create a suitable user "terminal" program using the various, pixel based, commands. I have more than one Prime calc, which are used in different physical locations, and it helps if operations can remain as consistent as possible.

-Dale-

[matthiaspaul]

(01-19-2016 04:17 PM)Tim Wessman Wrote:  The terminal is not really a true terminal (it doesn't accept user input/editing for example), but for lack of a better word to describe it - it was dubbed the terminal.

Hm, if it is an output-only device and if associating it with a "print device" would be misleading as well, perhaps calling it "list device" or "lister" would be neutral enough. (This would be following old DOS 0.x/1.x terminology, which supported a line output device named LST:, later replaced by LPT1:.)

Greetings,

Matthias

[sbergman27]

(01-19-2016 04:17 PM)Tim Wessman Wrote:  Yes, the OS has no problems with your comment re the apple2.

OK. I'm largely satisfied. I can run a program that writes to the terminal and scroll through the results. And the output to the terminal mostly occurs in real-time. I do have one question. Why the 10 second delay in terminal output at 43 in this demo program? That delay threw me a bit. I assumed that it didn't scroll until the program terminated when I first ran it, with a smaller upper limit to the FOR/NEXT loop.

Code:


EXPORT PR()
BEGIN
  PRINT();
  LOCAL p:=1;
  FOR X FROM  1 TO 1000000 DO
    p:=nextprime(p);
    PRINT(P);
  END;
END;

Were you able to replicate my problem with Bad Argument Type? I consider that one to be a bug fix which really should make it into the next firmware release.