DrawScript
Pages: 1 2
David R. Lane (77) 745 posts |
Does anyone know where one can get hold of DrawScript? I have tried various URLs, but they have all returned 404 errors or other errors. I have tried some AppBASIC (another of Joe Taylor’s applications) sites, but they have not led me to DrawScript. |
Rick Murray (539) 13432 posts |
Version 2.12 is here: It’s not 32 bit compatible. There may be a later release (not found it yet). This one works on my Pi2 (ARMv7) using Aemulor. |
Rick Murray (539) 13432 posts |
Download the above, then pick up an 32bitted version of the DrawScript module from http://heyrick.ddns.net/files/ds212-32.zip (only the module). It was a dead easy conversion. All the module does is register a bunch of BASIC files in ResourceFS, so there were only a few LDMFD^s to edit, and a flags word to stuff in. |
David Pitt (3386) 1248 posts |
The DrawScript Module is not required at all, it was intended for floppy only systems of long ago. Compare The last DrawScript was 2.12β May 2001 as far as I know. |
Fred Graute (114) 629 posts |
The DrawScript website can be found here |
David R. Lane (77) 745 posts |
Rick, thanks very much for the links. |
Steve Fryatt (216) 2055 posts |
That’s still probably DrawScript, however, as BASIC won’t be doing much paining on its own. |
Martin Avison (27) 1440 posts |
In my experience, a BASIC program is just as capable as any other languge of creating ZeroPain errors! |
Steve Fryatt (216) 2055 posts |
BASIC won’t be doing much paining on its own. That’s the program written in BASIC, and not BASIC itself, however. |
David R. Lane (77) 745 posts |
@Steve |
Rick Murray (539) 13432 posts |
FTFY. What you mean to say is that in BASIC it’s pretty difficult to create pain. One needs to be messing around with dodgy memory block addresses/offsets etc in raw indirected memory accesses (the ? and ! type stuff); whereas in C the typical behaviour of how the language is implemented makes it fairly easy to wander into pain by accident (a generic value for undefined things is NULL which is zero which is what arrays are typically set to before allocation or after being freed, etc etc. Plus C’s indirection BASIC is a padded play pen in comparison. ;-) And that’s what Steve’s reply was about. Unless freaky memory manipulation is going wrong, it’s pretty much not going to be BASIC causing the pain issues… |
Steve Fryatt (216) 2055 posts |
Yes, but BASIC by itself is not causing the errors – unless you’ve discovered some hitherto unnoticed bugs in the interpreter. The program written in BASIC can easily be causing the errors: as Martin says, it’s trivial to cause problems in BASIC by doing things with indirection operators. For example
will cause grief, but it’s not a problem with BASIC. If you get ZeroPain logs when running DrawScript scripts, it’s far more likely to be DrawScript or your scripts than BASIC itself which is responsible. That’s the program written in C, and not C itself, however. No, that’s not what I said at all.
No, I didn’t mean to say that, either. I meant exactly what I wrote. I think we can be fairly confident1 that there are not issues within the BASIC interpreter which are causing Zero Page reads – if there were, we would probably have had the odd report or two. I can be fairly confident that if I write
that I’m not going to get inundated with ZeroPain logs. However, BASIC doesn’t stop programs written in it from doing silly things. If I instead write
then I will indeed start to get logs output. David wrote
which I take to mean that he’s claiming that the fault lies with BASIC, and not DrawScript or the script itself. I would suggest looking elsewhere for the issues myself. :-) 1 Not 100% certain, however, but confident enough. |
nemo (145) 2437 posts |
Rather more pertinently, uninitialised variables in C are undefined, and in practice can be any random value. In BASIC however, uninitialised LOCALs are 0. Just sayin’. |
Clive Semmens (2335) 3136 posts |
Just to be clear, that means the programmer is unlikely to know what value they might have, and is unlikely (unless they have some pretty arcane knowledge and skills — or even then) to be able to gain useful information from the value. They’re not random in the strict sense, nor even properly pseudo-random, and can’t be used as a random number source. |
Rick Murray (539) 13432 posts |
What kind of lazy dev doesn’t bother to initialise variables at definition time? It isn’t as if “= NULL” or “= 0” is loads more typing. It’s also why I use cslloc() instead of malloc().
Locals, yes. And I think named variables default to 0. The built in ones (A% etc), not so much. I remember running into this with… StrongBS, was it? Many years ago… |
GavinWraith (26) 1540 posts |
This version of Drawscript is from 2001. Joe started with Drawscript a good decade earlier, long before AppBasic. It is only an extension of BASIC to the extent that the PROC token appears as a dot – a cosmetic detail. It started as a program for making it simpler to draw graphs. Joe was keen to get others to write libraries for it. I remember that I wrote one for doing elementary projective geometry in the plane – cross-ratios, coonics, Pascal and Des Argues’ theorems – that sort of stuff. The problem of undefined values has deep roots in theoretical computer science, especially for programming languages that have a type system. Is an empty list of numbers a different sort of thing from an empty list of unicorns? I think I have ranted elsewhere on the great advantages for a programming language of having a nil value, distinct from all other values. |
Clive Semmens (2335) 3136 posts |
No. Other than locals, using a named variable that has not been initialized results in an “Unknown or missing variable” error. |
nemo (145) 2437 posts |
Clive pedanted
Quite so. ‘Unpredictable’. Rick asked
It’s impossible to classify the programmers, because it’s a failing of the language. It’s not laziness (though it can be lazy initialisation, ha!). But regardless of opprobrium, it’s a common bug. Note in particular that debug builds do (usually) perform zero-initialisation, so this class of bug can hide in plain sight.
The only two ways to ‘declare’ a variable in BASIC (in the C sense) are these: PROCdeclare this=this DEFPROCdeclare:LOCALthat:ENDPROC and they both zero-initialise. However, if StrongBS decides that
|
nemo (145) 2437 posts |
My Favourite Programming Language™ PostScript has And a certain graphics program I’m familiar with used ‘none’ to mean no fill colour and ‘nowt’ to mean ‘a total absence of colour specification’. You can’t have too many nothings. |
GavinWraith (26) 1540 posts |
Absolutely right. Nor too many errors. Lua now allows errors to be any type, not just strings. Of course, as sight is the primary sense for humans, you can only output data after it has been formatted as a string, which has led some benighted souls to think that everything has to be a string (tcl, anybody?). When we move on to computer interfaces for dogs we shall have to format data as smells. A blind friend of mine in India used to use Linux and TeX with an aural interface when he headed the Indian Statistical Institute. |
Clive Semmens (2335) 3136 posts |
And again. Even “unpredictable” isn’t really quite right. I cringed every time I had to write it in the ARM ARM. But yes, under the ARM ARM definition, it’s unpredictable. |
Rick Murray (539) 13432 posts |
How is it a “failing” of the language? Some languages assign a value to a new variable, others do not. C is one that requires an explicit assignment. So does VisualBasic if you set OPTION EXPLICIT.
One might suggest if not laziness in programming, then a laziness in understanding the specifics of the language in use?
Yes, Debuggers are notorious for sanitising memory. Time for another nugget of Rick’s advice: Never assume a variable is set to any value that you haven’t set it to.
And there you go. Inconsistencies. ;-)
Maybe they were taking a broader view? What happens on any given processor is entirely predictable. However different cores, different implementations… So across the entire range of processors it is “unpredictable” how something would behave… ;-) |
Clive Semmens (2335) 3136 posts |
Oh, we certainly were. It’s just that it’s still not strictly “unpredictable.” Not easy to predict, but possible in principle. Not that anyone in their right mind would spend valuable instructions and clock cycles making such predictions! (Except possibly the writers of malware…)
Not in every instance, iirc, at least not in the sense of the result always being the same. On some processors the results in some cases vary according to race conditions or other externalities. Making them even harder to predict – possibly in a few cases actually UNpredictable 8~) |
Rick Murray (539) 13432 posts |
Once upon a time we used to time cycles to make code as optimal as possible. But these days with out of order 1 execution and dual issue and such, plus different cores having different behaviour (improvements) it’d be a nightmare to try to work out how “fast” anything goes. 1 When I were a lad, that phrase meant summat that were broke. |
Clive Semmens (2335) 3136 posts |
Or a wet dream for those aforementioned malware writers… |
Pages: 1 2