Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1919 > unrolled thread

BASIC REM's

Back to article view | Back to comp.sys.acorn.programmer

Contents

  BASIC REM's cferris@freeRemoveuk.com.invalid - 2012-07-13 09:29 +0100
    Re: BASIC REM's Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-07-13 11:23 +0100
    Re: BASIC REM's Steve Drain <steve@kappa.me.uk> - 2012-07-13 11:25 +0100
      Re: BASIC REM's Alan Adams <alan@adamshome.org.uk> - 2012-07-13 13:02 +0100
        Re: BASIC REM's Steve Drain <steve@kappa.me.uk> - 2012-07-13 14:08 +0100
    Re: BASIC REM's Gerph <gerph@gerph.org> - 2012-07-13 08:05 -0700
      Re: BASIC REM's jgharston <jgh@arcade.demon.co.uk> - 2012-07-14 05:15 -0700

#1919 — BASIC REM's

With BASIC REM's in PROCs/FN's where is best place to put them - in a 
file - without slowing down the Program?

How/can they be dumped - when the program is loaded?

Thanks
-- 
Colin Ferris Cornwall UK

[toc] | [next] | [standalone]

#1922

The following bytes were arranged on 13 Jul 2012 by cferris@freeRemoveuk.com.invalid:

> With BASIC REM's in PROCs/FN's where is best place to put them - in a
> file - without slowing down the Program?
>
> How/can they be dumped - when the program is loaded?

Apparently, by setting the system variable BASIC$Crunch to any value,
which will cause BASIC to perform a CRUNCH %01111 (the second 1 is the
flag to remove all REM statements) when a program is loaded.

-- 
  __<^>__
 / _   _ \           It is written that Geeks shall inherit the Earth.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1923

On 13/07/2012 09:29, cferris@freeRemoveuk.com.invalid wrote:
> With BASIC REM's in PROCs/FN's where is best place to put them - in a
> file - without slowing down the Program?
>
> How/can they be dumped - when the program is loaded?

*Set BASIC$Crunch 1

BASIC will then remove REMs, excess space etc. There is no penalty in 
doing this in the boot sequence and it ought to be included 
automatically IMHO. ;-)

Basalt does a similar job if there are still REMs and spaces to remove.

Steve

[toc] | [prev] | [next] | [standalone]

#1924

In message <GJSLr.732889$MP5.653518@fx27.am4>
          Steve Drain <steve@kappa.me.uk> wrote:

> On 13/07/2012 09:29, cferris@freeRemoveuk.com.invalid wrote:
>> With BASIC REM's in PROCs/FN's where is best place to put them - in a
>> file - without slowing down the Program?
>>
>> How/can they be dumped - when the program is loaded?

> *Set BASIC$Crunch 1

> BASIC will then remove REMs, excess space etc. There is no penalty in
> doing this in the boot sequence and it ought to be included
> automatically IMHO. ;-)

> Basalt does a similar job if there are still REMs and spaces to remove.

> Steve

What happens to the reported line nmber in error messages? does it 
still refer to the original line in the file?

-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#1925

Alan Adams wrote:
> Steve Drain wrote:
>
>> On 13/07/2012 09:29, cferris@freeRemoveuk.com.invalid wrote:
>>> With BASIC REM's in PROCs/FN's where is best place to put them - in a
>>> file - without slowing down the Program?
>>>
>>> How/can they be dumped - when the program is loaded?
>
>> *Set BASIC$Crunch 1
>
>> BASIC will then remove REMs, excess space etc. There is no penalty in
>> doing this in the boot sequence and it ought to be included
>> automatically IMHO. ;-)
>
>> Basalt does a similar job if there are still REMs and spaces to remove.
>
>> Steve
>
> What happens to the reported line number in error messages? does it
> still refer to the original line in the file?

Line numbers are preserved by BASIC and I think I have done so with 
Basalt. Perhaps this should not be relevant, but BASIC will not delete 
lines whose numbers are targets of GOTO etc.

Steve

[toc] | [prev] | [next] | [standalone]

#1926

On 13 July, 09:29, cfer...@freeRemoveuk.com.invalid wrote:
> With BASIC REM's in PROCs/FN's where is best place to put them - in a
> file - without slowing down the Program?

Place them where you need them.

Omitting commentary because of performance concerns is a premature
optimisation - one which will cause you more pain in the future.

> How/can they be dumped - when the program is loaded?

If you need to strip comments for performance, obfuscation or other
purposes, use a pre-processor to perform this operation. Many tools
exist for this, but you can also strip comments from your program by
using the BASIC interpreter itself. A simple harness for compressing
the program is to create a Command file that contains:

----
TEXTLOAD "input-program"
CRUNCH -1
SAVE "output-program"
QUIT
----

And in your scripts that create a new release of your program (because
you control your releases, don't you ? :-) ) you have a script that
invokes your simple compressor:

*compress-program
*BASIC

(yes, it's still a bit tacky, but it does the job)

Be encouraged to include the uncompressed source alongside the
compressed code if you're compressing the code for performance
reasons. Compressing the BASIC code for obfuscation reasons is
pointless, in general - unless your compressor is very intelligent it
will not stop anyone who is even slightly determined.


To digress slightly into forms of commentary, my personal
recommendations come from experience of my own development and pain
from observing other people's methods. Other people have their own
view on how you use comments, but here's some unsolicited 'wisdom'...

Files should always open with a comment ('file prologue comment') that
describes what they're for, and if you can express it easily, how it
fits into the overall project. Implementation details should not be
included in this comment. Include a copyright attribution if you want,
but if the entire file prologue comment consists of licensing details
then you're doing it wrong. The intention of the file prologue comment
is to give you context for further understanding of the file. It will
be the first thing that someone who looks at the code will see, and so
should help to introduce the concepts that are being used.

If the language you are using separates internal implementation and
external interface (eg header files in C/C++), the file prologue will
vary between them - the external interface (eg .h file) file prologue
should contain the concepts as seen from the external interface,
indications about reentrancy and maybe even some short examples of
use, where they don't fit into the function prologue comments. The
internal implementation file shouldn't duplicate this information, but
may deal in the concepts of implementation, eg how structures are
handled in general, or implementation goals. Design decisions are also
useful to include here (eg "We use a hash keyed on names to improve
lookup speed"), as are any notes about future developments (eg
"Consider a LRU cache if look up is still slow", "FIXME Although the
external API says we can use any address type, we only actually
support IPv4 right now.").

Functions should be commented ('function prologue comment') to give a
description of what they is intended to do, and their API. Constraints
on the function should be documented, as should assumptions.
Describing what the function is intended to do can often be summed up
in a single line, but where it needs to be described in more detail
this should be separated into a paragraph away from the single line
summary - this just helps when skimming the code. For languages which
separate the external and internal interface, the external interface
comment should focus on the use of the function, and the internal
comment should include any other detail to aid understanding
implementation.

Parameters to the function should be documented, for inputs and
outputs. Don't repeat information stated previously (try to be
concise) but don't omit important detail - the function prologue
comment will be the place that a reader will come to in order to find
the intention of the author, so omitting important detail here may
lead to misunderstanding and wasted time / broken code.

Return values should also be documented, as should and exit conditions
which should be expected (exceptions that are thrown or other exit
criteria). Behaviour in the case of errors should be consistent, but
if it isn't this should be documented.

Reentrancy issues should be documented here, if relevant, as should
any other side effects of the function which might not be expected.

If the function truly is simple, then document it as such. If you make
changes to the function, check that the constraints and documentation
in the function prologue is still correct - if it isn't then either
you've changed the behaviour, or the function was inadequately
described. In the former case, this may have impact on any code that
uses the function - and this one of the major reasons for documenting
the function properly - if you can see that you've changed the
functionality of the routine from the description (as well as changing
the code, obviously) then you can evaluate the risk of making the
change. Conversely, if you find that the code doesn't do what the
function prologue describes then you have two pieces of evidence for
what the author intended the function to do - a description and the
code. In general the documentation should be a more accurate view on
what was intended, which may help you decide how best to change the
discrepancy. (of course if the code is in wide usage in a different
form, then correcting the documentation to match implementation may be
more sensible)

Inline comments should deal with implementation detail, or indicate
where something non-obvious is happening. Using inline comments within
a function too much can obscure the code, but used sensibly they can
ease reading. I've bounced back and forth on how I do inline comments,
but one style which I've felt to be helpful is to document (in words)
what is being done/why through the function so that you can read
either the code or the comments and understand what's going on. This
has disadvantages - it's overly verbose and, it can be argued, should
be in the function prologue not inline.

Such comments should be at a higher level than describing the
following line - if you're following a set of steps from a
specification or procedure, it's useful to document the actual step
numbers. This can often aid in development; by writing the steps you
intend to perform first you can validate that you've got the structure
right before you implement anything. Again there are arguments against
this, but it often helps.

Using the form of documentation from automated documentation systems
(eg Doxygen, which I've used well in the past) can help to enforce a
consistent commentary style. Consistent style helps you to spot where
detail is missing. Even if your language is not supported by a
documentation system, you can still benefit from placing structure on
your code.

If you need examples of how you might apply these sorts of rules, see
some of my perl code:
  http://usenet.gerph.org/DCPU-16/dasm-0.34/
  http://usenet.gerph.org/DCPU-16/dasm-0.34/DASM.pm.txt
  http://usenet.gerph.org/DCPU-16/dasm-0.34/DASMIO/Source.pm.txt

In BASIC there's some quite old code which I wrote for managing timers
in AudioGalaxy satellite client; I don't hold strongly to some of the
guides here as the code is quite old:
  http://usenet.gerph.org/Timers/AGSatellite.zip

Or in C, there's some code that was originally in Nettle that I reused
(in Toolbox I think):
  http://usenet.gerph.org/Timers/CVersion.zip

I've diverged significantly from your original question. Sorry about
that. Hope it was useful.

--
Gerph
... I wanna heal, I wanna feel what I thought was never real,
    I wanna let go of the pain I've felt so long.

[toc] | [prev] | [next] | [standalone]

#1929

Gerph wrote:
> Files should always open with a comment ('file prologue comment')
..
> Functions should be commented ('function prologue comment') to give a
> description of what they is intended to do, and their API.
..
> Parameters to the function should be documented, for inputs and
> outputs.
..
> Return values should also be documented, as should and exit conditions

Sticking my head above the parapet, the libraries at mdfs.net/blib
can be examined for an example of a commenting style. I don't claim
it to be the best style, it is what I use.

JGH

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web