+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command (/thread-1546.html)
How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - Jsather - 06-05-2014 04:40 PM
Apologies for such a lengthy post. I can’t wish away the details.
The Wait(-1) is an extremely convenient method of waiting for and reading touch pad activities and/or key presses. A command such as this is a large part of the “face” of the HP’ for programmers and users and must be extremely robust and well documented to enable programmers to deal with the huge variety of touches, drags, swipes, presses, bounces, pinches, drag velocities, etc. that may be encountered. The first rule is that the user might do anything and anything he does that the hardware allows is legitimate.
The bad news is that the Wait(-1) command, is not very robust but prone to freezing the calculator in a state that can only be retrieved by the “paper clip or On plus Symb” reset or worse. By worse, I mean that, in exploring the Wait(-1) freeze up I have managed to put my HP’ in a state where I could not edit programs, even after the paper clip reset. I only managed to revive the calculator by restoring a backup I had made using the connectivity kit. Let us all praise HP for the Backup / Restore capability and use it often.
More bad news is that HP has not completely documented the Wait(-1) command and has modified the undocumented features of the command in the 6030 firmware release without informing the community. The changes are in the handling of fast swipes of the finger across the touchpad. We cannot pretend these gestures will not occur and Wait(-1) will not detect them. If we ignore them, our code will not function. Shame on HP for not documenting them and trying to slip a change unnoticed in such a fundamental command.
The good news is that owner / operators are shedding a light on these shortcomings. My expectation is for a positive response from HP because they want these freeze-ups gone, more even than we.
You can observe the operation of Wait(-1) using a short and simple program called WaitLab that I’ve attached here and posted in the HP Prime software forum, http://www.hpmuseum.org/forum/thread-1545.html . The program simply prints the results of Wait(-1) in a continuous loop with a built in pause in the loop of Dly seconds. This simulates functional code that checks for user input and takes Dly seconds to process, then loops back and checks again. Every time Wait(-1) returns a list from the touchpad or a real number key press, the Mouse command is issued and the results are printed left to right: Wait(-1) result, time in milliseconds since the last result, Mouse result, velocity of drag in pixels per second if the result is a drag (code 1). Pressing the Esc key exits the program.
The purpose of writing this code was to explore the Wait(-1) and Mouse commands so I could learn how to program HP’ touchpad inputs. Obviously, HP documentation was lacking. When my real world code began freezing up, I used WaitLab to try and duplicate the freeze ups and eventually homed in on the specifics. I was ready to post that result when 6030 was released. I checked and found the specific freeze up had not been repaired, but my program was no longer functioning well due to changes in the way Wait(-1) responded to fast swipes. My priority was to get a handle on those changes and repair my code which I have partially done. Of course, that would have been a lot less time consuming if there had been documentation. Grrrr! Anyway, people are posting information about freeze-ups now, and I wanted to make my contribution; so I’m posting what I think I know.
Before using WaitLab, use the Connectivity Kit to backup your virtual and real calculator. You can lose your data and programs using 6030 Wait(-1).
Run WaitLab with any small delay (.01-.1 sec) to familiarize yourself with Wait(-1). Compare touches, long touches, drags, swipes, pinches, stretches, key presses, and touches in the button area at the bottom. You will see that those button area touches get special treatment, a nice feature (again undocumented) that your code should take into account.
On my computer, I can reliably freeze up the EMU (the virtual calculator) in either firmware rev 5447 or 6031 as follows: Run WaitLab with Dly = .1. Perform a long touch (1 second) to observe the normal sequence ({0,x,y}, {7,x,y},{2},{3,x,y} in 5447, {0,x,y}, {7,x,y},{2} in 6031 … didn’t you know?). Now press and hold a computer arrow key to activate the computer’s keyboard auto repeat function, then release the arrow key after a second or so. You will know you are ready to freeze the EMU if, after you released the arrow key, key presses continue to be indicated on the EMU display for a second or so. The EMU is now prepared to freeze up if you perform a long touch. This is true even you perform some short touches first which will respond normally. Go ahead and try some short touches which should work normally. Then place the cursor over the EMU display, press and hold your computer mouse left button for at least a second. Your EMU will then freeze up. A call will be made to Wait(-1) which places the EMU in an endless loop somewhere, control never to be returned unless you close the EMU and restart it.
This was the nature of the occasional freeze ups I encountered in a program of mine, only in the EMU, not the actual calculator. I eventually was able to isolate the problem to long touches after leaning on the arrow keys. You may not see the freeze ups on your computer because the auto repeat setups are different. I have mine set up for fast repeats after a short delay. But knowing the situation is related to key press buffering getting ahead of Wait(-1) calls, followed by long touches, we can create the freeze up situation by increasing Dly in WaitLab.
To reliably freeze up your HP’ or EMU, run WaitLab with Dly = .5, simulating half a second of processing between Wait(-1) returns. Press (or EMU click) any key on the calculator rapidly about 16 times. You should get the indication of keyboard buffering generating returns for a while every half second after you stop pressing the key. The calculator is now set up for the long touch to Wait(-1) that never returns, even if you perform some intervening short touches and drags.
After you’ve frozen up your calculator, you won’t be able to do anything with it unless until you perform a paper clip reset or press On and Symb at the same time, equivalent as far as I know. Do this so you can follow me on the changes to swipe handling by Wait(-1). I probably needn’t add that ideally, paper clip resets should never be required. Calculators are not supposed to freeze up under any circumstances.
After restarting your calculator, run WaitLab with a delay of .11. As opposed to dragging, swipe your finger fast to see the result of a detected swipe. If the calculator happens to freeze up, just restart it again. Assuming your firmware rev is 6030, you will know the swipe was detected because the calculator will continue to generate Wait(-1) returns for about a second after you finished the swipe. I’m not sure what triggers the swipe detection. It might be a velocity in the neighborhood of 700 pixels per second. I’m going to refer to the 1 second string of Wait(-1) returns as AutoDrags (short for auto repeat drags). Unique features of the AutoDrag returns are pixel coordinates off the screen (x,y<0, x>319, y>239) and the absence of a terminating {2} return. A nice feature is that AutoDrag returns are terminated if the user touches the screen, but a weak feature is that the programmer has no way to take charge and terminate them. It’s out of the programmer’s hands (unless there is a secret method I haven’t detected).
AutoDrag is a feature of firmware release 6030. There was swipe detection in 5447, but it consisted of a single x-coord return of 65535, followed by a terminating {2} return. The program needed to look at two returns prior to the 65535 return to get the direction of the swipe. There was a possibility of incoherent swipe detection, quick swipes without two preceding swipes, but that is all history now. My own code used IF x-coord > 319 to determine that Wait(-1) detected a swipe. No question as to why my code was on life support once I loaded 6030 considering the magnitude of the change in swipe detection from 5447 to 6030.
Please indulge me a moment while I complain to HP in a sanctimonious, self-superior manner. There are right ways and wrong ways to make a change like this. You could have left Wait(-1) alone and backward compatible and added Wait(-2) with AutoDrag as a new feature. Instead you skulk around in sneaky ways thinking you can modify code without telling anyone, just because you failed in your documentation mission in the first place. All the world doesn’t have scroll fever. Your AutoDrag takes control of Wait(-1) programming completely and leaves the programmer out of the loop, unable to accomplish his purpose. It would be a nice option but is an overbearing mandate. You’ve obviously never heard of Sather’s litmus test (which I’m making up as I write): If it’s not worth the effort to make it backward compatible to existing code, a change may well not be worth doing. Ditto for those stupid spaces you added behind the commas in lists printed via Textout_p. It’s a small screen. Don’t waste space. Bleah!
Alright now … Let us use AutoDrag to freeze up the HP’. Use the program editor to edit WaitLab and remark out the line “MS:=B->R(MOUSE());” so the call to Mouse no longer occurs after the Wait(-1) call. Now run WaitLab, again with Dly of .11 and do some fast swipes to activate AutoDrag. TaDaaa! Frosty the Snow Man … but if you let it sit there, it still seems to time out every minute and return a -1, even though it is otherwise frozen. The program I’m reviving is freezing up fairly often. I’ll try adding some Mouse calls after the Wait(-1) calls and post whether that or anything else is a viable workaround.
A parting note to the HP development team. Look, a lot of us have been around the block and can read between the lines. I probably wouldn’t have done any better in your shoes. You’ve created an amazing and unique product, and we are many behind you in hoping for its ultimate refinement and success. It’s all on your backs to make the right noise and the right changes. I hope this information is helpful in eliminating all the freeze ups people have been complaining about in other informative posts. Hang in there, and lots of love from the community.
Jfs.
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - HP67 - 06-05-2014 05:10 PM
Should have been: How to freeze up your Prime!
HPs don't freeze! Hey, that rhymes!
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - Tim Wessman - 06-05-2014 06:18 PM
Few items to comment on:
You seem to be under the impression that somehow we "decided" to modify wait or "slip in a change" when in reality what was modified was that kinetic scrolling was added to the system. This works by starting a timer which sends movement events until it stops. Yes, that will be out of the programmers hands and there is no way in *any* touch system I am aware of the manually stop receiving movement information from the screen. You can completely block it, you can completely ignore it, but you still get it. WAIT is just reporting what the system is receiving in a form that can be read/parsed in a program.
The button areas aren't getting special treatment - rather the buttons are still there underneath any drawing you've done. You just are covering them up on the screen but they still exist.
"Ditto for those stupid spaces you added behind the commas..."
How would you be able to distinguish between {1,234,123,234} and {1,234,123,234}? That could be {1 234 123 234}, {1234 123 234}, {1 234123234}, and so on.
I would appreciate your elaboration on "We cannot pretend these gestures will not occur and Wait(-1) will not detect them." What exactly is the information you are wanting to ignore and for what purpose?
I thank you for your detailed analysis and it should be helpful in tracking things down. I suspect you've isolated an issue that nobody seemed to have found before. I am not seeing the details you mention in "I checked and found the specific freeze up had not been repaired". Which is this? Details?
The other lock ups seem to be the same issue that is being discussed that has to do with a kinetic scroll being activated.
Reply to Tim Wessman - Jsather - 06-05-2014 09:53 PM
Responding to Tim Wessmen’s Reply:
TW:
You seem to be under the impression that somehow we "decided" to modify wait or "slip in a change" when in reality what was modified was that kinetic scrolling was added to the system. This works by starting a timer which sends movement events until it stops. Yes, that will be out of the programmers hands and there is no way in *any* touch system I am aware of the manually stop receiving movement information from the screen. You can completely block it, you can completely ignore it, but you still get it. WAIT is just reporting what the system is receiving in a form that can be read/parsed in a program.
JFS:
My perspective is that of a user who looks at the HP’ primarily as a programmable calculator and the Wait(-1) as a command in a programming language. I have no way of knowing how it ties in with the “behind the face” system though there are strong hints it is tied in with kinetic scrolling. My perspective is that the functions of a command in the programming language were modified without notification. I am grumpy about it because the functional changes affect my software and I have to figure them out for myself.
TW:
The button areas aren't getting special treatment - rather the buttons are still there underneath any drawing you've done. You just are covering them up on the screen but they still exist.
JFS:
The button areas most emphatically do get special treatment, speaking strictly of returns from Wait(-1). A touch north of y=219 generates a sequence {0,x,y}, {2}, {3,x,,y} and a touch south of y=219 generates only {3,x,y}. Long touches south of y=219 will not generate the {7,x,y} indicator, and drags cannot be started with touches south of y=219. Anything you initiate south of y=219 generates {3,x,y} and nothing else is returned by Wait(-1).
TW:
"Ditto for those stupid spaces you added behind the commas..."
How would you be able to distinguish between {1,234,123,234} and {1,234,123,234}? That could be {1 234 123 234}, {1234 123 234}, {1 234123234}, and so on.
JFS:
Now I see why you put in the stupid spaces. I was peevish because the change seemed frivolous and I had to find a workaround because screen layouts I’d previously done had lists bumping into each other. There is no quandary if apostrophe delineators are used for large numbers verses commas, especially if the textout_p specifies font size 1. That’s what I’d prefer, but I know it is subjective. I retract my complaint now that you’ve explained the issue. As a workaround in case anyone else is paying attention, Textout_p(String(list),x,y) suppresses the spaces.
TW:
I would appreciate your elaboration on "We cannot pretend these gestures will not occur and Wait(-1) will not detect them." What exactly is the information you are wanting to ignore and for what purpose?
JFS:
I meant that Wait(-1) swipe detection will sometimes return x=65535 (rev 5447) or the timed out “AutoDrag” sequence with x,y values off the screen. As a programmer, that 65535 is coming sometimes and I must write code to deal with it, I just can’t ignore it, even if it is not documented.
TW:
I thank you for your detailed analysis and it should be helpful in tracking things down. I suspect you've isolated an issue that nobody seemed to have found before. I am not seeing the details you mention in "I checked and found the specific freeze up had not been repaired". Which is this? Details?
JFS:
Yeah I was rambling a bit. The specific issue that has not been repaired is that in either 5447 or 6030, take a long time between calls to Wait(-1), say half a second, in a continuous loop. Then press any key rapidly about 16 times so that key presses start building up as in a buffer. After you stop pressing the key, the key presses will continue to generate Wait(-1) returns for a second or so as the buffered key presses are processed. Now touch the screen for longer than a second and it will freeze up the Prime. While this may seem artificial, I discovered it under completely practical circumstances in the Virtual Calculator since my computer auto repeat key was generating rapid key presses.
TW:
The other lock ups seem to be the same issue that is being discussed that has to do with a kinetic scroll being activated.
JFS:
Thank you for your quick response. That truly is great customer service.
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - cyrille de brébisson - 06-06-2014 08:08 AM
Hello
> The button areas most emphatically do get special treatment
Yes, they do, you are correct.
<Behind the scenes>
The screen is composed of a number of graphical objects arranged in a tree like structure (as in Windows).
The Cmenu object (located at the bottom of the LCD) has an 'Imediate Click' flag turned ON.
This flag allows for a touch down on the CMenu to be imediately 'understood' as a click instead of having to wait for the touch UP. This allows the Menu to react much faster to user input as the action associated with a button click is imediate, not delayed. This participate in the overall feeling of 'snipiness' of Prime.
Problem: The system, ad described above is organized in this hierachy of bitmaps, as I said, like any windowing system.
HOWEVER, users programs do NOT have access to it, you see the screen as just 1 large bitmap. This is at the same time for ease of creating simple programs AND for backward compatibility wiht the 39.
These 2 'views' of the world do conflict, and the case of the menu area reaction to touch event is one of them...
I appologize, but I do not, at this point have an easy solution for the problem (trust me, if I had found one, I would have implemented it).
</Behind the scenes>
I hope that this helps.. Sorry that it is not in the documentation. There is just so much that would need to be documented, and so little time... I mean, would you rather have us develop new stuff or spend the next 2 years documenting what we already have?
However, never hesitate to ask questions, we will do all we can to answer them.
Cyrille
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - cyrille de brébisson - 06-06-2014 08:14 AM
Hello,
just wanted to add, regarding kinetic scrolling...
When we added this in, we did NOT want to have to modify every place in the system that was handling scrolling to also handle kinetic scrolling...
This is why it was architectured as a transparent change to normal scrolling...
This allowed us to quickly roll in the new feature with little to no changes in the rest of the SW...
It worked for us, and our application.
I am sorry that it does not work for you... you probably have a situation which is not represented in our software.
Cyrille
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - Thomas Radtke - 06-06-2014 09:20 AM
(06-06-2014 08:08 AM)cyrille de brébisson Wrote: [...] would you rather have us develop new stuff or spend the next 2 years documenting what we already have?If you had asked me (a technical writer :-D), I'd have answered to prefer the latter. Why? Sticking a little to an existing product, especially when seriously documenting it, helps finding bugs. It is always better to slightly adjust and debug product A than to forget about A and work on B.
We currently see lots of new HP products, nearly all of which were quickly forgotten in terms of perfective maintenance.
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - Jsather - 06-06-2014 05:26 PM
First, I apologize for lobbing accusations. I have been frustrated and was venting, and I regret it.
On the point of touches south of y=219 receiving special treatment in Wait(-1) returns: I like the special treatment and have found it easy to handle “button presses” right up front when a {3,x,y} comes back without predecessors. My only criticism is lack of documentation.
As to priorities, since Cyrille asked my opinion, I would prioritize getting a technical writer assigned to reviewing help screens and the user guide so that system programmers can work primarily on system code. The code priorities should be elimination of bugs before addition of new features though I hope the new features keep coming.
As for documentation weaknesses: foremost, the typos create a bad image for HP. I would open a direct channel from the community to your new technical writer for feedback on typos, errata, and needs. I would even enlist the user community by organizing the contributions already being made around the forums and blogs. Users are an HP asset that doesn’t show up in the bean counts.
There should be a programmer’s guide familiarizing new users with all the unique programming requirements of the Prime. In that manual, there should be a command reference section rich with examples. I would like to see another manual devoted to the advanced mathematical and CAS capabilities. This will be many new owner’s first CAS capable calculator. There are currently 8 pages devoted to CAS in the user manual and 60 pages to the Geometry App. My opinion is that the pretty baby is the CAS, not the Geometry App.
How about that? The technical writer isn’t even assigned yet and he’s busy for as far as we can see.
Thomas’ point about finding bugs during the documentation process is also my experience. But if you’re saying we must choose between improving the documentation and improving the calculator, nuts to the documentation. Make the calculator better.
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - Angus - 06-06-2014 09:04 PM
A well written post by Jsather. Polite and still getting to the point. Maybe someone able to react reads this one and starts re-thinking.
I do over-react from time to time and as a cynical being, not writing in my mothers language I cannot write such posts, I guess.
Please! Listen to him he is so encouraged and he gives good advice on what small things can help make the prime a better tool.
You might have started the project as a quick response to TI in the school market, but I think it is not that much away from a tool for fans and business users. Just listen to small proposals, wishes, needs of the community. And: feedback and interaction makes people feel heard. (just my personal opinion)
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - Jsather - 06-09-2014 03:58 PM
(06-05-2014 04:40 PM)Jsather Wrote: The program I’m reviving is freezing up fairly often. I’ll try adding some Mouse calls after the Wait(-1) calls and post whether that or anything else is a viable workaround.I modified the code as I said I would, adding a Mouse call after every Wait(-1) call and indeed there is a great improvement. I have no idea why this would be, but it appears that following Wait(-1) calls immediately by Mouse calls prevents some classes of freeze ups in programs reading the touchpad via Wait(-1).
The program I have been working on is ColorCube, and it is now posted in the HP Prime Software thread. Prior to adding the shadowing Mouse calls, ColorCube was freezing up so often, I didn't feel I could post it.
RE: How to Freeze up Your HP' and Other Secrets of the Wait(-1) Command - cyrille de brébisson - 06-10-2014 06:09 AM
Hello,
Quote:If you had asked me (a technical writer :-D), I'd have answered to prefer the latterJob security :-)
Honestly, we woudl all want to have everything perfect... we try to balance things as much as we can, but everyone has a different opinion of the balance point.
Quote:First, I apologize for lobbing accusations. I have been frustrated and was venting, and I regret it.Shame on you for being Human! -
It happends to all of us that you are wholehartedly (sp?) excused!
Quote:How about that? The technical writer isn’t even assigned yet and he’s busy for as far as we can see.Volunteers?
Joke set asside, HP has worked in the past with various 3rd party individuals, if a motivated group got together and made a proposal, maybe something could be done.
(Note: THIS IS NOT A FORWARD LOOKING STATEMEMT, THIS IS NOT BASED ON ANY INTERNAL KNOWLEDGE OF ANYTHING, THIS IS JUST A: In the past, in a similar situation A happends, so maybe it could happen again given the same circonstances).
Cyrille