WP34S: how to delete a program?



#39

Hello, I'm sorry if this has been already discussed but if you have several programs in the RAM, how do you delete only one of them?

CLP clears all program memory and I've not found in the manual a way to delete a single program, except by deleting it set-by-step.

Would it be possible to add a END instruction similar to the one in the 41/42 so that CLP 'lbl' would delete the program from the label 'lbl' to the next END?


#40

Quote:
CLP clears all program memory and I've not found in the manual a way to delete a single program, except by deleting it set-by-step.

These two are the only ways.


Quote:
Would it be possible to add a END instruction similar to the one in the 41/42 so that CLP 'lbl' would delete the program from the label 'lbl' to the next END?

Possible, certainly. Simple no.


- Pauli


#41

:-)


#42

What about a DEL instruction which takes as its argument the number of steps from the current position forward to delete?

Just an idea.


#43

Interesting idea. Can you think of a keyboard mapping?


#44

No keyboard mapping for access other than perhaps simply putting it into the P.FCN catalog.

#45

The same idea I've been thinking about how to implement...
Can't promise it will happen.


- Pauli

#46

Good idea! I understand that moving to individual programs separated by END instructions can have a huge impact on lot of functions at that stage of development. A DEL instruction as suggested in the P.FCN catalog would be very nice to have.


#47

Quote:
Good idea! I understand that moving to individual programs separated by END instructions can have a huge impact on lot of functions at that stage of development. A DEL instruction as suggested in the P.FCN catalog would be very nice to have.

Such an END statement won't be a problem at all, if it were just ignored by the usual interpreter and only used for clearing programs (something like a 'dummy' instruction or a NOP).

It could be only used by the CLP command, which would then clear the program where the program counter currently is, from the above END (or 000 when it's the 1st program) to the following END statement. With this method the user won't even have to enter any line number(s) for CLP, it would simply delete the 'current' program.

Or CLP could ask the user (as it does now for confirmation) if it should clear the "Current" or "All" programs.

Edited: 27 July 2011, 7:39 p.m.


#48

Quote:
Such an END statement won't be a problem at all,

Since it seems so easy to you, I look forward to seeing your implementation.

It is not this straightforward.

Also, END cannot act as a NOP, it has a defined behaviour. It has to act like a return, catch skips over it in either direction and stop label addressing searches.


- Pauli


#49

Quote:
Since it seems so easy to you, I look forward to seeing your implementation.

It is not this straightforward.

Also, END cannot act as a NOP, it has a defined behaviour. It has to act like a return, catch skips over it in either direction and stop label addressing searches.


Once again you don't understand at all what I mean!

Maybe you should read a bit more detailled what I wrote:

"...if it were just ignored by the usual interpreter and only used for clearing programs"


#50

I understood your suggestion, you seem to misinterpreted my response. Implementing END as you suggest will bring calls for it to be done properly that is what my last sentence was about.

Even if we just do what you suggest, I don't think it is as simple or easy as you are making out. Feel free to implement it and prove me wrong here.


- Pauli


#51

Quote:
Implementing END as you suggest will bring calls for it to be done properly

Sorry, but I've no clue what you mean with this!?

My idea of such an 'END' (or you can call it whatever you want, even a '---' would be possible) is that it should just work as a physical separator betweeen programs which have no connection to each other. And this separator can of course be simply ignored by an routines which e.g. search for any labels.

What I mean looks like the following structure:

LBL 'PRG1'
...
...
...
RTN
END (or ---)
LBL 'PRG2'
...
...
RTN
END
LBL'PRG3'
...
etc.

So where would any problem when the program counter is e.g. within PRG2 and you execute a CLP: this would just delete the block from LBL'PRG2' to (and including) the next END.

So this END should simply act as an additional marker for the CLP command, but otherwise should be ignored by any other program routines (like searching for labels etc.).


#52

Quote:
Sorry, but I've no clue what you mean with this!?

Read the HP-41 or HP-42 manuals. They have an END that finishes programs. This is what will be wanted.


- Pauli


#53

You are absolutely right. That IS what would be wanted <g> plus more. This is one of my big complaints with the 32/33/35 series as well as the Voyager calcs. Program separation was a great feature to have in the 41C and 42S.

Among the advantages you mention I would also add that labels within a program are local so reuse is not an issue. Plus all programs would start at step 1 no matter where they were in memory.

So you are right, more would be asked for and it is NOT easy to implement.


#54

Originally, CLP was meant to work as requested now:

Quote:
Clears current program after confirmation.

in v1.2. This request was explained further in v1.11:
Quote:
Clears the current program after confirmation. This program is the one the program pointer is in.

but never made it into the code, so I removed it from the manual in v1.18.

Walter

#55

Quote:
What about a DEL instruction which takes as its argument the number of steps from the current position forward to delete?

Done :-)


There is a DEL[sub-p] command in the program catalogue. This command takes an argument 00 - 99 and that many steps will be deleted starting with the current step. If the argument is zero, all steps from the current one to the end of program memory will be removed.

The name is subject to ratification by Walter and quite likely will change. The implementation is probably full of bugs where I missed corner cases.

About one third of our bug fix flash buffer was used adding this feature.


- Pauli


#56

Thanks!

#57

Looks like we're having a slight change of plan. I think I'll be able to implement a delete up to but not including a label instead. Almost as good as a program END.


- Pauli


#58

A proper name would be DELto, taking a label in any case. What will happen, if the label is not found? Abort or delete to end? How to delete to end? DELto . nnn might mean delete up to step nnn.


#59

No DEL.nnn Step numbers are the reason for the change to labels. I'm not going back :-)


- Pauli

#60

A first attempt is committed to SVN.

DEL[sub-p] takes either a numeric, hot key or alpha label and deletes up to but not including that label.


- Pauli


#61

Quote:
A first attempt is committed to SVN.

DEL[sub-p] takes either a numeric, hot key or alpha label and deletes up to but not including that label.


Ok, I'm coming back to 'END' again: ;-)

I can guess what confused you with the word 'END' as end-marker for a program: you probably thought you would have to completely change you code for searching labels (after a XEQ) in memory.

But in fact this END could just be an alternative (synonym) for RTN, with the only difference that RTN could also be WITHIN a program (even more often than once, e.g. after a conditional test), whereas this END should really exist only at the intended/physical end of a program.

With this method you won't even need a new command like DELp, you just need to modify the existing CLP routine to delete all lines upto and including the next END statement (any maybe even backwards to but not including the previous END). No need to change any other routines (like searching for labels) at all ...

And this method would have the further advantage that the user doesn't have to know (and enter= the name of the next label when he just wants to delete the current program.

Franz

Edited: 28 July 2011, 5:36 a.m.


#62

We simply cannot have an END instruction that doesn't behave like the 41c's END.


- Pauli


#63

Quote:
We simply cannot have an END instruction that doesn't behave like the 41c's END.

Ok, I finally understand now: you're suffering from ENDophobia ... ;-)

#64

It's just respect for the ingenious implementation in the 41C and 42s calculators.

Don't understand us wrong, please! We know that the feature is useful and your simplified approach will certainly work. But it will trigger a lot of further requests which we cannot fulfill.

There will be another incarnation of what is now the 34S that's oriented closer on the 41C and 42s. But it requires a mayor rewrite of most of the firmware and will most likely be renamed to another number then 34.


#65

Quote:
It's just respect for the ingenious implementation in the 41C and 42s calculators.

Well, then why not just call this new statement EOP (end-of-program) instead of END ?

#66

What's in a name? That which we call a rose by any other name would smell as sweet.


#67

Quote:
What's in a name?

Well, it was just to avoid your dislike of the name END. ;-)

BTW, although it's certainly more than 15 years when I've used my HP41 the last time, but I absolutely don't understand (or remember) what could be so 'special' (or ingeniuos) about this END statement!?

I've just had a look the the HP41 programs on JMB's site (which you always use as reference), and I see that every program there terminates with an END.

So if a user would like to port any of these HP41 programs to WP34S, then what should he use instead of this END statement of the HP41? I guess a RTN is the correct (and only) choice, right?

But this RTN does also NOT behave exactly as the END on the HP41 (as you've stated), so why could not just be used an END statement instead of this RTN (with the SAME behaviour as RTN)? This would at least making the deletion of a program easier.


#68

Franz, I'm thinking about a proper implementation of END as known from the 41C. It doesn't come for free. We need to sacrifice some program steps or even numeric registers for the proper handling of the current program and the return stack. You will not talk us into a half hearted implementation just for the sake of a simple program delete command. Be patient, let's discuss the ramifications internally, and if we come to a solution we'll talk about it here.


#69

Hear, hear! And thank you very much. As I noted earlier this is one feature that I would love to see implemented long term.


#70

+1

#71

I think I've got a fix for END issue.

When you write your programs, finish each with a LBL'END' or a LBL 97 or LBL whatever.

To delete a program: DELp'END' or DELp 97 or DELp whatever.


You get your no-operation END. Nobody will complain that it isn't a real END.


Problem solved :-)


- Pauli


#72

Quote:
Problem solved :-)

Well, I would say there's an even better solution:

I'll stop reporting any bugs or making any suggestions to improve the WP34S in the future - problem solved, too!

I guess this is the first time you agree with me, right? ;-)


#73

Well, I don't think that stopping reporting bugs will improve anything... I think that suggesting new things and reporting bugs is great, but we shouldn't expect them to implement everything we wish. After all, they're doing this for fun. I too made a few suggestions (some privately, too) and many were not accepted. I was disappointed but I accepted that, and I kept on reporting and asking! :) It's too bad that I can't program C, if I could I would probably try to submit patches myself, but being unable to do so, I can just suggest and hope that those who can program, agree with my ideas.
And in this case, the suggestion of a "Lbl 'End'" makes sense... if it's not possible to have a proper 'End' command, this more or less does what you need - as you can put one after each program, and so the calc will delete until the end of the current program. So, in a way, it is problem solved.

This is all in my opinion of course, but I really don't think we should take these things personally - after all it's their project and their free time, we can't expect them to do what we want, not until we pay them! :)

Cristian


#74

Cristian, we have had the same type of discussions internally for some time. Many "brilliant" ideas weren't implemented because they either were too demanding on space (flash and ram) or they were just not so "brilliant" as they seemed to be.

#75

I agree with Cristian here. Reporting bugs is always helpful. I think everything you've reported thus far has been improved upon if not fixed.

Making suggestions as to how to you'd like the problem fixed are also welcome.

Resolutely sticking to these suggestions or trivial variations thereof after they been explained to be flawed isn't so helpful.

Getting upset is positively counter-productive.


Chill out, it is a hobby for us all.


- Pauli

#76

... and be patient: if it's a really good idea, it will turn up again. See e.g. the history of CLP ;-)

Walter


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime: How do I insert/delete a column/row in a spreadsheet ? Michael de Estrada 3 738 11-20-2013, 10:01 PM
Last Post: Michael de Estrada
  HP Prime: run a program in another program Davi Ribeiro de Oliveira 6 818 11-11-2013, 08:28 PM
Last Post: Davi Ribeiro de Oliveira
  Cannot delete file Les Koller 4 687 11-07-2013, 12:17 AM
Last Post: Les Koller
  program print in wp34s Andrew Nikitin 13 1,264 07-22-2013, 10:11 PM
Last Post: Andrew Nikitin
  WP34s program submission: Quadratic fit Andrew Nikitin 2 440 06-13-2013, 02:44 AM
Last Post: Paul Dale
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 404 10-04-2012, 04:59 PM
Last Post: Paul Dale
  WP34S program question Mike Maiorana 12 969 04-05-2012, 03:09 AM
Last Post: Steve Simpkin
  WP34S: "Domain error" when running a program Cristian Arezzini 19 1,296 01-31-2012, 08:31 AM
Last Post: Cristian Arezzini
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,534 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 513 12-04-2011, 10:49 PM
Last Post: Les Wright

Forum Jump: