Crunching BASIC - again
Chris Johnson (125) 825 posts |
Have you tried TaskUsage by Martin Avison? This appears to work fine. |
John Sandgrounder (1650) 574 posts |
I had not tried it until now. The proof will be to see if it runs for days on end with other tasks coming and going. What I have seen so for looks good. Apart from the fact that the !RunImage file is another crunched basic. Somewhat different results from !CPUload and !Usage – who is to say which is more accurate! |
Martin Avison (27) 1494 posts |
Indeed, but that only runs when the Config window is open. The main monitoring & display is run by the TaskUsage module task. Which is assembler. All designed to minimise memory and cpu overheads. Anyway, I am still here and supporting it!
Indeed. But at least TaskUsage documents how it does calculate the processor usage – see Help. |
Rick Murray (539) 13851 posts |
There isn’t really a way to determine the CPU load. I think the usual way is to sit on null polls, and time how long it takes for control to come back to the application; in other words if control returns within 1cs then the system is less laden than if it takes 10cs. That said, I’m not certain that the maths that made sense in 1987 on an 8MHz processor entirely scales to 2017’s ~1GHz+ processors… |
John Sandgrounder (1650) 574 posts |
Sorry Martin. I did not mean to criticise the use of Basic. I program in Basic and like looking at other people’s code to learn from it. Crunching makes that difficult, whilst still leaving the code open to be copied if anybody really wants to. I see crunching as pointless, but annoying, particularly as Basic can now do it for us at runtime. By the way your !TaskUsage app looks very lood. I am very pleased with it (specially the way it reduces the need to have the Task Manager window open as well as !Usage. I am impressed with the way the window automatically adjusts its size to the number of running tasks. And thanks for the reminder to disable unwanted response codes from Wimp_Poll. |
Steve Drain (222) 1620 posts |
BASIC has been able to do limited crunching for decades, but without the user’s compliance it will not. It is not new. As for being pointless, it is clear from comments in response to my original post that opinions are divided. The main conclusion, perhaps, is that if you crunch you should include the uncrunched version in the application. Personally, I think it is worth doing, hence Crunchie. I am still working on it and adding features, even it is just for my own satisfaction. ;-) Who remembers COMAL, which was very like BASIC? One of its feature was that you did not have to include the PROC or FN when calling procedures and functions. I have just included this as an option in Crunchie – great fun. Of course, you can only actually run the crunched program. ;-) |
Clive Semmens (2335) 3276 posts |
That’s a good part of why I write and upgrade my little apps! 8~) Mental exercise…important when one’s nearing 70… |
Steve Drain (222) 1620 posts |
And beyond. ;-) |
Matt Price (2343) 71 posts |
I used to crunch using !BasCompress to stop people looking at my source code in BBC Basic. Effectively I did this as I was ashamed at how much reverse engineering my code contains. I never learnt BASIC as a proper structured high level programming language. I used reverse engineering of other people’s BBC BASIC code to figure out how to get actions to work. I know now that this is fine – most coders leave really useful comments in their code. Back then I thought the knives and pitchforks would be out for me! I’ve released all my stuff open source a while ago – I’ll publish the .arc and .img files shortly. |
Clive Semmens (2335) 3276 posts |
Because they’re sensible and know they’ll need them themselves when they come back to the code later. But some coders (he says, whistling innocently) never get round to writing the useful comments. Not malice, just stupidity. |
Steve Pampling (1551) 8172 posts |
Yeah, that’s me. Really helps when I come back to something a few years down the line.
Some start with comments and expand them along the way. |
Clive Semmens (2335) 3276 posts |
Oh, yes, I do that. Sometimes it reaches as many as five comments in 1,000 lines of code. No, I’m not proud of this. As I say, it’s stupid. Sometime I ought to make time to go back and comment things – but it never seems worth the effort. And when I’m writing stuff… oh, hell! Even when I’m editing 20 year old stuff… Is there any way to get an old dog to practice old tricks? |
Clive Semmens (2335) 3276 posts |
No, I really am not. But when I think about it, I suppose I am vaguely proud of the fact that this is still possible:
and this may contribute to the feeling that it’s never worth the effort to go back and comment…however much I may know that this is actually irrational. |
Chris Hall (132) 3559 posts |
The question really is whether it is more productive to recall your original decisions (on just the peice of misbehaving code, which takes me a couple of days) or to recall your original decisons (on the whole code) and write it our longhand in the form of comments. As I get older the balance between recall and adding comments when first written changes, but by then it is too late. |
Clive Semmens (2335) 3276 posts |
Oh, I’ve not had to fix any misbehaving code for yonks. I’ve been upgrading some programs I wrote twenty years ago to perform new tricks. I’ve not done a lot of recall in the process, it’s a matter of analysing the code to work out what the hell is going on. At least I have semi-meaningful variable, function and procedure names on the whole. |
Steve Pampling (1551) 8172 posts |
Or reading the comments to remind yourself :)
Which is actually part of the comment/documentation. It’s also why crunching up code is a damn stupid idea.1 Readable code is always better and comments enhance that. You know those people that delight in really quirk short perl scripts? Yeah, well I haven’t quite decided whether Neighbours shown 24/7 with their eyelids taped open for a month is harsh enough. 1 Yes I know it goes whizzy fast when variable names are very short, but it doesn’t really matter if the start and endpoint of your whizzy fast code are user input. It’s like having a 200mph stretch of road between two traffic jams. |
Steve Drain (222) 1620 posts |
Think of crunching as if it were compiling, perhaps to bytecode. You do not throw away the source after compiling. It is also quite feasible that crunching is only done at runtime 1, a sort of JIT. In effect that is what BASIC does itself, but only if the user enables it. That stretch between traffic jams is the time your application is not returning control to the Wimp. Better to do it at 200mph than 20. 1 I suggested this earlier: *Crunchie <Obey$Dir>.!RunImage <Wimp$Scrap> Run <Wimp$Scrap> |
Steve Pampling (1551) 8172 posts |
That’s sensible. As you said:
|
Clive Semmens (2335) 3276 posts |
Well, yes – I was talking about what I actually have to do, not the ideal situation! 8~) |
Clive Semmens (2335) 3276 posts |
Which might be important if you have real time app running, or your computer is doing some really heavy data crunching in a background task – how many of us are doing that sort of thing? |
Rick Murray (539) 13851 posts |
Sheesh. If it’s that important, hang off TickerV and to hell with what the Wimp may or may not be doing. Or is it acceptable for everything to grind to a halt because a small furry god walked upon the F12 key1? 1 She knows. And she knows I know she knows. And she does it anyway… |
Clive Semmens (2335) 3276 posts |
If anyone is using any app I’ve written while their computer is doing anything where an extra 150 microseconds between wimp polls matters, they’ve only got themselves to blame… |