Posts: 248
Threads: 5
Joined: Feb 2008
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?
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 4,587
Threads: 105
Joined: Jul 2005
Posts: 1,545
Threads: 168
Joined: Jul 2005
What about a DEL instruction which takes as its argument the number of steps from the current position forward to delete?
Just an idea.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Interesting idea. Can you think of a keyboard mapping?
Posts: 1,545
Threads: 168
Joined: Jul 2005
No keyboard mapping for access other than perhaps simply putting it into the P.FCN catalog.
Posts: 3,229
Threads: 42
Joined: Jul 2006
The same idea I've been thinking about how to implement...
Can't promise it will happen.
- Pauli
Posts: 248
Threads: 5
Joined: Feb 2008
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.
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 1,216
Threads: 75
Joined: Jun 2011
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"
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.).
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 756
Threads: 31
Joined: Aug 2010
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.
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 248
Threads: 5
Joined: Feb 2008
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
No DEL.nnn Step numbers are the reason for the change to labels. I'm not going back :-)
- Pauli
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
We simply cannot have an END instruction that doesn't behave like the 41c's END.
- Pauli
Posts: 1,216
Threads: 75
Joined: Jun 2011
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 ... ;-)
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 1,216
Threads: 75
Joined: Jun 2011
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 ?
Posts: 3,229
Threads: 42
Joined: Jul 2006
What's in a name? That which we call a rose by any other name would smell as sweet.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
Posts: 1,216
Threads: 75
Joined: Jun 2011
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? ;-)
Posts: 372
Threads: 42
Joined: Mar 2011
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
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 756
Threads: 31
Joined: Aug 2010
Hear, hear! And thank you very much. As I noted earlier this is one feature that I would love to see implemented long term.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 248
Threads: 5
Joined: Feb 2008
Posts: 4,587
Threads: 105
Joined: Jul 2005
... and be patient: if it's a really good idea, it will turn up again. See e.g. the history of CLP ;-)
Walter
|