In message <5976c58cd9News03@avisoft.f9.co.uk>
on 5 Oct 2021 Martin wrote:

> In article <sji2ks$fsg$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:
> > Am Tue, 05 Oct 2021 15:44:04 +0100 schrieb Martin:
>
> > > Changing the poll mask is perfectly normal. The key thing is to have
> > > Nulls disabled when the program does not require them - eg when it is
> > > doing nothing, sitting idly on the iconbar waiting for something to do.
> > >
> > > You can also switch to using PollIdle, and change the delay
> > > times, when a program is running.
>
> > OK. That's interesting !
>
> > Then one can change almost all other poll events simply by
> > disabling the mask entry. E.g. to temporarily switch off reaction
> > to keypresses or messages.
>
> Yes ... but beware that the keypresses, messages or whatever will not
> be repeated, so they will be totally ignored. Null Polls will happen
> again at some time...

I'm not sure that's quite right. The description of the mask on page 3-117 of
the printed RISC OS 3 PRMs distinguishes between some events which are
completely masked out (e.g pointer leaving/entering window, lose/gain caret)
and others which will merely be queued, these being window redraw, mouse
click, and key press.

Mind you, I have never experimented with this, however, and there is a note
underneath that says "the bits which are marked 'queue for later handling'
stop the Wimp from proceeding, i.e. it stops all other tasks too".

In most software you decide which events you're never going to need (e.g.
poll word non-zero, pointer leaving window) and mask them out. The most
important thing is to mask out null events when you don't need them.
Receiving all the possible null events should only be done if you are doing
something intensive and want to remain responsive with multitasking. It is
also important to poll the Wimp frequently enough during this. I mainly use
Wimp_PollIdle if there is a regular activity to do, like updating a clock, or
every 25cs while dragging is occurring, so as to support the Drag and Drop
protocol, autoscrolling of windows, etc.

--
Matthew Phillips
Durham

In article <34b6977859.Matthew@sinenomine.co.uk>,
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> In message <5976c58cd9News03@avisoft.f9.co.uk>
> on 5 Oct 2021 Martin wrote:

> > In article <sji2ks$fsg$1@solani.org>,
> > Sebastian Barthel <naitsabes@freenet.de> wrote:
> > > Am Tue, 05 Oct 2021 15:44:04 +0100 schrieb Martin:
> >
> > > > Changing the poll mask is perfectly normal. The key thing is
> > > > to have Nulls disabled when the program does not require them
> > > > - eg when it is doing nothing, sitting idly on the iconbar
> > > > waiting for something to do.
> > > >
> > > > You can also switch to using PollIdle, and change the delay
> > > > times, when a program is running.
> >
> > > OK. That's interesting !
> >
> > > Then one can change almost all other poll events simply by
> > > disabling the mask entry. E.g. to temporarily switch off
> > > reaction to keypresses or messages.
> >
> > Yes ... but beware that the keypresses, messages or whatever will
> > not be repeated, so they will be totally ignored. Null Polls will
> > happen again at some time...

> I'm not sure that's quite right. The description of the mask on
> page 3-117 of the printed RISC OS 3 PRMs distinguishes between some
> events which are completely masked out (e.g pointer
> leaving/entering window, lose/gain caret) and others which will
> merely be queued, these being window redraw, mouse click, and key
> press.

Yes, I am aware of that, but I decided to try and keep the explanation
as simple as I could.

> Mind you, I have never experimented with this, however, and there
> is a note underneath that says "the bits which are marked 'queue
> for later handling' stop the Wimp from proceeding, i.e. it stops
> all other tasks too".

Me too - I have never tried it, and am puzzled by the note.

> In most software you decide which events you're never going to need
> (e.g. poll word non-zero, pointer leaving window) and mask them
> out. The most important thing is to mask out null events when you
> don't need them. Receiving all the possible null events should
> only be done if you are doing something intensive and want to
> remain responsive with multitasking. It is also important to poll
> the Wimp frequently enough during this. I mainly use Wimp_PollIdle
> if there is a regular activity to do, like updating a clock, or
> every 25cs while dragging is occurring, so as to support the Drag
> and Drop protocol, autoscrolling of windows, etc.

Agree totally - it is the main reason I wrote TaskUsage ablot 25 years
ago (gosh!), and why I try to let authors know if I think Nulls are
being used for no good reason.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

This thread takes me back a bit (? a lot)

In the late 1960s I knew John Conway in Cambridge, and we played his new
game using counters on sheets of squared paper.

He would be amazed and delighted that it is still being played 50 years later,
in a more modern form.

Rosemary

Am Sat, 09 Oct 2021 03:28:12 -0700 schrieb Rosemary Miskin:

> This thread takes me back a bit (? a lot)
>
> In the late 1960s I knew John Conway in Cambridge, and we played his new
> game using counters on sheets of squared paper.
>
> He would be amazed and delighted that it is still being played 50 years
> later,
> in a more modern form.
>
> Rosemary

Thats a very interesting comment.

And I suppose that this will be one of the games or better programs or
"algorithms" that have been made "for ever". Its a true classic in the
same sense as "Tower of Hanoi" or "Barnsley's fern" or "Koch snowflake"
are - great and impressive ideas, with the special feature that all of
them are execeptionally great examples for the connection between pure
mathematics and graphics and computers. They will be found - together
with the Game of Life - in books for programmers for the rest of all
times. And thats a great thing. Absolutely amazing, as some would tend to
say.

And thats why its good if RISCOS gets a new version too; from time to
time. And this should be as usable as possible (there are some minor
"glitches" in its current state), but actual its already usable and one
can get a good impression of the power of these 4 little rules that are
behind all the fancy gliders and sliders and oscillators.

SBn

In article <sk230s$37q$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:

> > In the late 1960s I knew John Conway in Cambridge, and we played his
> > new game using counters on sheets of squared paper.

> Thats a very interesting comment.

I wholeheartedly agree. At the ROOL forum, some contributors memorised
their contact with John Conway as well, thus making the past nearly
tangible.

> And thats why its good if RISCOS gets a new version too; from time to
> time. And this should be as usable as possible (there are some minor
> "glitches" in its current state), but actual its already usable and one
> can get a good impression of the power of these 4 little rules that are
> behind all the fancy gliders and sliders and oscillators.

I may have addressed some of the glitches.
Version 10 offers the possibility to switch off the grid, and has a much
more flexible grid control. Altering the grid dimensions will just do that,
while altering the cell dimension will always try to find corresponding
rows and columns in such way that the entire desktop is filled, minus the
iconbar.

Download from:

http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

Kind regards,
Paul

--
http://www.riscos.sprie.nl

Dear all,

I can't stop modifying my program.
The most important improvement is that I introduced memory blocks, instead
of two-dimensional arrays. My experience is that memory blocks benefit
greatly from getting compiled, while they need considerably less memory
than arrays. As an example: the 857 generations of the Kite>Manta shape in
a 400x400 grid take 14 minutes and 7 seconds in Basic on my 4té. The same
process in the compiled version takes 21 seconds - a 40 times speed gain!

Improvements:
- Much faster.
- Largest grid is now 400 x 400.
- Shapes may be moved around the grid using the cursor keys, with or
without Shift held down.
- Cell shape toggle and Grid toggle, by Adjust clicking on the pane, are
swapped. The new location is more intuitive, I think.
- The Random button reflects the cell shape.

http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

Best wishes,
Paul

--
http://www.riscos.sprie.nl

Am Sat, 16 Oct 2021 17:54:25 +0200 schrieb Paul Sprangers:

> I can't stop modifying my program.

That's normal ... :) and very good. Especially since the latest iteration
gave an IMPRESSIVE speedboost, and some minor but very handsome
iconchanges.

> The most important improvement is that I introduced memory blocks,
> instead of two-dimensional arrays. My experience is that memory blocks
> benefit greatly from getting compiled ... - a 40
> times speed gain!

And that's not the maximum that could be reachable. There are some more
speed uprgrade possible, if You try to change the check procedure. At the
cost of readability of the code.

> Improvements:
> - Much faster.

Thats true. Runs in good animation speed on my RPCEmu with a smaller grid
of e.g. 128x96

> - Largest grid is now 400 x 400.

Thats the max. But probably not the best idea to use it as the default
mode. At the start of the program - for a new users first time run - its
absolutely necessary that he can click and play around easily with the
"elements". On my screen I would say a 96x64 resolution of the grid is a
good starting point. On higher screenresolutions on a RPi or coming
machines something around 128x96 or 160x128 could be a good starting
point.

An experienced user of this program will set his/her own resolution. But
to get involved into the program 400x400 isn't ideal.

> - Shapes may be moved around the grid using the cursor keys, with or
> without Shift held down.

Need to try this. Sounds interesting.

> - Cell shape toggle and Grid toggle, by Adjust clicking on the pane, are
> swapped. The new location is more intuitive, I think.

That IS more intuitive !

Eventually there also could be a second icon for the grid button, too.
One with broken/interrupted lines in it ( - - - - - ) ( - - - - ).
Or a little painted checkmark in the lower corner of the gridsymbol.

> - The Random button reflects the cell shape.

Very handy.

> http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

Thanks for bringing this to the massive audience :)

Eventually You could also announce the next version (or this one here) in
the comp.sys.acorn.announce and ROOL - its a major step forward.

All the best,
SBn

In article <skmb39$bsm$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:

> There are some more speed uprgrade possible, if You try to change the
> check procedure. At the cost of readability of the code.

I really wouldn't know how to speed up that routine, short and simple as it
already is. What I *am* thinking about, is to assign a single bit to each
cell, rather than a byte. This might speed up things, only if it wouldn't
cost extra time to calculate the individual bits involved. But even when it
would slow down the program marginally, it would definitively need 8 times
less memory. However, I first have to think about a short and effective
routine that sets and reads single bits.

> At the start of the program - for a new users first time run - its
> absolutely necessary that he can click and play around easily with the
> "elements". On my screen I would say a 96x64 resolution of the grid is a
> good starting point.

Good point. I'll think about a useful beginners grid and add that as the
first time default.

> Eventually there also could be a second icon for the grid button, too.
> One with broken/interrupted lines in it ( - - - - - ) ( - - - - ).
> Or a little painted checkmark in the lower corner of the gridsymbol.

Good point too. I'll think about it.

> Thanks for bringing this to the massive audience :)

Ha-ha!

> Eventually You could also announce the next version (or this one here)
> in the comp.sys.acorn.announce and ROOL - its a major step forward.

Don't you think that people who read the comp.sys.announce will also read
this group?

Thanks for the feed back, very much appreciated!

Best wishes,
Paul

--
http://www.riscos.sprie.nl

Am Wed, 20 Oct 2021 17:11:37 +0200 schrieb Paul Sprangers:

> In article <skmb39$bsm$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:
>
>> There are some more speed uprgrade possible, if You try to change the
>> check procedure. At the cost of readability of the code.
>
> I really wouldn't know how to speed up that routine, short and simple as
> it already is.

Its simple and good in a sense of readability since it simply "declares"
what the algorithm of GoL says. But this doesn't mean its the fastest one
possible.

A very easy edit could eventually be (one has to measure if this gives an
effect at all) the inclusion of an if then statement wich checks if the
maximum of three neighbor cells has been reached already and if so leave
the procedure immediately. There should be an optimal place for such a
thing and eventually an maximum of such if-then structures since they
also a need an amount of time. And, its effeciancy depends on state of
"filling" of the complete board. E.g. an if c >= 3 then endproc after the
4th line of if's could be an interesting place for such a structure.

But thats the easy one. The more effeciant way could be to think about
the fact, that for every point that runs through this procedure (check)
every line of neighbours to the left and to the right of the point is
also a line for another point, namely the +2 point and the -2 point in
direction x. The same is true for y, but makes things much more
complicate. So if one runs through a line in x direction and adds the
positions that are neighbours y wise ( -x,-y; -x,0; -x-+y ) ( +x,-y;
+x,0; +x,+y ) and then test the sums it is possible to reuse every sum a
second time for another point.

And, away from this idea, wich eventually is not faster because of the
overhead (one has to test it) its eventually faster in a general way to
use additions instead of if-then's. Your actual check procedure would
then transform into a single sum / addtion command of all the neighbours.
This sum could be tested in a normal way with if sum <= 2 , if sum = 3 ,
if sum > 3.

( ... and in another turn this could (evetnually) be speeded up a little
bit by defining an "result-array" (DIM nresult% 256) that simply states
the rules of the game - wich means that for every postion in the array
the postions of the neighbours are set as bit-on/bit-of, wich works
perfeclty with 8 bit since there are 8 neighbours at all. With such an
construction You never have to check something (if-then) at all because
only the neighbouring bits of the actual point are "collected" in a byte
and then this is tested against the result array wich gives back if the
point should be plotted or not.)

> What I *am* thinking about, is to assign a single bit to
> each cell, rather than a byte. This might speed up things, only if it
> wouldn't cost extra time to calculate the individual bits involved. But
> even when it would slow down the program marginally, it would
> definitively need 8 times less memory. However, I first have to think
> about a short and effective routine that sets and reads single bits.

Yes. It depends.
But, if its good constructed and especially if it uses shifts or is
written in assembler it should give another boost.

>> Eventually You could also announce the next version (or this one here)
>> in the comp.sys.acorn.announce and ROOL - its a major step forward.
>
> Don't you think that people who read the comp.sys.announce will also
> read this group?

I think they will read. But none of them will read all the items of such
an thread. So he/she will miss the announcements.

I don't say You should announce every single and somtimes little steps as
a new version in c.s.a.announce but if the program makes a big step
forward - as it has been with the speed up - it should get an new
"official" announcement to all. You can reuse the old thread in
c.s.a.announce ... :) if You think, there is not enough place to do so
otherwise.

> Thanks for the feed back, very much appreciated!

If it helps to get a finer and more polished version ...

on the other side I like to see a new RISCOS "Tool" coming alive.

All the best,
SBn

In article <sku720$lfp$1@solani.org>,
Sebastian Barthel <naitsabes@freenet.de> wrote:

> {...} the inclusion of an if then statement wich checks if the maximum
> of three neighbor cells has been reached already and if so leave the
> procedure immediately. There should be an optimal place for such a
> thing and eventually an maximum of such if-then structures since they
> also a need an amount of time. And, its effeciancy depends on state of
> "filling" of the complete board. E.g. an if c >= 3 then endproc after
> the 4th line of if's could be an interesting place for such a structure.

Your suggestion, as well as three other if-then structures in that routine
that I tried, slow the program down - from noticeable to considerable.
There's no speed gain whatsoever.

I've thought about making the routine more efficient for many hours,
especially about avoiding the duplication of calculations, as you noticed
in your comment. But avoiding duplicate calculations can't be done without
introducing a lot of overhead. The experience with the extra if-then
statements as described above discouraged me from even trying.

A good example is my attempt to store each cell in a bit, rather than in a
byte. Unfortunately, we don't have a bit operator for memory blocks, such
as the ? for bytes, or the ! for words. Setting or clearing a particular
bit 'n' in a particular byte can be done rather easily by adding or
subtracting 2^n to or from that byte. But reading a bit is another matter.
After a lot of brain crunching I managed to compose a nice little recursive
routine that does the job. The necessary memory could then be reduce with a
factor 8 indeed. However, the bit-approach slows the program down to such
degree, that I had no other choice than forgetting about it completely.

Of course, all this doesn't mean that speeding up the program can't be
done. It just means that it can't be done by me.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

In message <59820556e0Paul@sprie.nl>
Paul Sprangers <Paul@sprie.nl> wrote:

> In article <sku720$lfp$1@solani.org>,
> Sebastian Barthel <naitsabes@freenet.de> wrote:
>
> > {...} the inclusion of an if then statement wich checks if the
> > maximum of three neighbor cells has been reached already and if so
> > leave the procedure immediately. There should be an optimal place
> > for such a thing and eventually an maximum of such if-then
> > structures since they also a need an amount of time. And, its
> > effeciancy depends on state of "filling" of the complete board.
> > E.g. an if c >= 3 then endproc after the 4th line of if's could be
> > an interesting place for such a structure.
>

> I've thought about making the routine more efficient for many hours,
> especially about avoiding the duplication of calculations, as you
> noticed in your comment. But avoiding duplicate calculations can't be
> done without introducing a lot of overhead. The experience with the
> extra if-then statements as described above discouraged me from even
> trying.
>
> A good example is my attempt to store each cell in a bit, rather
> than in a byte. Unfortunately, we don't have a bit operator for
> memory blocks, such as the ? for bytes, or the ! for words. Setting
> or clearing a particular bit 'n' in a particular byte can be done
> rather easily by adding or subtracting 2^n to or from that byte. But
> reading a bit is another matter. After a lot of brain crunching I
> managed to compose a nice little recursive routine that does the job.
> The necessary memory could then be reduce with a factor 8 indeed.
> However, the bit-approach slows the program down to such degree, that
> I had no other choice than forgetting about it completely.

It's a long time since I've used BASIC, so this may be wrong, but
surely you can read a bit using AND as a binary operator?

Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
preferably (b AND (1<<n)).

Without looking at the program in the large, I wouldn't have thought
this would give much of a performance hit.

--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

In article <f2600c8259.tigger@bc63.orpheusinternet.co.uk>,
Nick Roberts <tigger@orpheusinternet.co.uk> wrote:

> Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
> preferably (b AND (1<<n)).

Hell, that's it! I completely forgot about AND, and only remembered the
shift. This is the current state of my brains I'm afraid, and it surely
won't get better. Thanks a lot!

Kind regards,
Paul

--
http://www.riscos.sprie.nl

On 28/10/2021 08:34, Paul Sprangers wrote:
> In article <f2600c8259.tigger@bc63.orpheusinternet.co.uk>,
> Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
>
>> Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
>> preferably (b AND (1<<n)).

Or maybe:

b%>>n% AND 1

This always returns 1 or 0 and is a tiny bit faster. ;-)

In message <slgds7$1tb$1@gioia.aioe.org>
Steve Drain <steve@kappa.me.uk> wrote:

> On 28/10/2021 08:34, Paul Sprangers wrote:
> > In article <f2600c8259.tigger@bc63.orpheusinternet.co.uk>,
> > Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
> >
> >> Hence bit 'n' of byte 'b' is set if (b AND (2^n)) is not zero, or
> >> preferably (b AND (1<<n)).
>
> Or maybe:
>
> b%>>n% AND 1
>
> This always returns 1 or 0 and is a tiny bit faster. ;-)

It's been a long time since I used Basic, so I plead brain fade for the
use of %. In C, I just tell the compiler that b and n are integers 8-)

--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

Dear all,

In case you're wondering why there hasn't been a new update since two weeks
or so, well... there is one: 1.11c. However, it only has some minor
improvements, partly based upon the suggestions made by others, in
particular Sebastian Barthel.

My intention was to reduce memory significantly by storing cells in bits,
rather than in bytes, but although I more or less succeeded in doing so,
there's still a really weird bug that I can't put my fingers on. Moreover,
in spite of Nick's and Steve's elegant bit operators, the result is still
noticeably slower than the version based upon bytes. I haven't yet given
up, but I'll park it for the time being.

Download as always from:
http://www.riscos.sprie.nl/sprang.riscos/Downloads/GoL.zip

Kind regards,
Paul

--
http://www.riscos.sprie.nl

On 03/11/2021 11:21, Paul Sprangers wrote:

> Moreover, in spite of Nick's and Steve's elegant bit operators, the
> result is still noticeably slower than the version based upon bytes.
A little while back Martin Avison and I worked on providing bit and byte
arrays for BASIC via a CALL. They were great for saving memory, but
there was a significant penalty in speed over using indirection.
Accessing bits in just BASIC is very much slower again.

In article <slu8bs$1gl4$1@gioia.aioe.org>,
Steve Drain <steve@kappa.me.uk> wrote:

> A little while back Martin Avison and I worked on providing bit and byte
> arrays for BASIC via a CALL. They were great for saving memory, but
> there was a significant penalty in speed over using indirection.
> Accessing bits in just BASIC is very much slower again.

That confirms my experience. If even Martin and you came to this
conclusion, then I will now certainly forget about bitting the game.

Setting and reading bits in computer memory seems so fundamental, that it's
weird to find out that it isn't easy at all (well, it may be easy, but
unexpectedly time consuming). Thank you for sharing your thoughts and
experience.

Kind regards,
Paul

--
http://www.riscos.sprie.nl

On 04/11/2021 16:30, Paul Sprangers wrote:
> Setting and reading bits in computer memory seems so fundamental, that it's
> weird to find out that it isn't easy at all (well, it may be easy, but
> unexpectedly time consuming). Thank you for sharing your thoughts and
> experience.

It's a case of using the correct tool for the job. An interpreted
language has a large overhead determining the additional arithmetic
operations needed to get or set each bit within a byte or word.

But a compiled language, particularly C which was designed to twiddle
bits as efficiently as possible, can mean the reduction in the amount of
memory passing through the data cache more than makes up for the
additional arithmetic instructions needed. So using bits may be a lot
faster than bytes for large amount of data.

---druck

In article <sm1bo2$ur8$1@dont-email.me>,
druck <news@druck.org.uk> wrote:

> But a compiled language, particularly C which was designed to twiddle
> bits as efficiently as possible, can mean the reduction in the amount of
> memory passing through the data cache more than makes up for the
> additional arithmetic instructions needed. So using bits may be a lot
> faster than bytes for large amount of data

No doubt that's true. The need of learning C is something that I postponed
to my retirement. Now that I am, I find it even difficult to remember the
common Wimp things in Basic. Erm... any recommendation for a good start for
C in RISC OS?

Kind regards,
Paul

--
http://www.riscos.sprie.nl

On 05/11/2021 09:27, Paul Sprangers wrote:
> No doubt that's true. The need of learning C is something that I postponed
> to my retirement. Now that I am, I find it even difficult to remember the
> common Wimp things in Basic. Erm... any recommendation for a good start for
> C in RISC OS?

I don't have any specific recommendations, but Wimp programming is a lot
easier in C than BASCIC. Wimp calls in BASIC take blocks of memory and
you have to know offset and type of each field to use with indirection
operators. In C each call takes or returns a C structure which contains
named and typed fields, meaning you don't have to remember offsets, and
the compiler can check you've used the correct type.

---druck

In message <sm98a9$72b$1@dont-email.me>
on 7 Nov 2021 druck wrote:

> On 05/11/2021 09:27, Paul Sprangers wrote:
> > No doubt that's true. The need of learning C is something that I postponed
> > to my retirement. Now that I am, I find it even difficult to remember the
> > common Wimp things in Basic. Erm... any recommendation for a good start for
> > C in RISC OS?
>
> I don't have any specific recommendations, but Wimp programming is a lot
> easier in C than BASIC. Wimp calls in BASIC take blocks of memory and you
> have to know offset and type of each field to use with indirection
> operators. In C each call takes or returns a C structure which contains
> named and typed fields, meaning you don't have to remember offsets, and
> the compiler can check you've used the correct type.

Well, you can make C just as hard as BASIC if you make all the calls using
_kernel_swi or similar! For an example of that approach (not recommended)
see the series by Paul Johnson in Archive many years ago.

If you use OSLib, or a higher-level library like Desk, DeskLib or Steve
Fryatt's SFLib, then I would agree, C is easier than BASIC.

See https://www.stevefryatt.org.uk/risc-os/wimp-prog for Steve's tutorial on
Wimp programming in C. You could do a lot worse than follow his guide. I've
dipped into a few of his tutorials and it looks very well presented and full
of good advice.

--
Matthew Phillips
Durham

On 07/11/2021 20:12, Matthew Phillips wrote:

> Well, you can make C just as hard as BASIC if you make all the calls using
> _kernel_swi or similar! For an example of that approach (not recommended)
> see the series by Paul Johnson in Archive many years ago.
>
> If you use OSLib, or a higher-level library like Desk, DeskLib or Steve
> Fryatt's SFLib, then I would agree, C is easier than BASIC.

So, it comes down to the quality of the library you use then. Perhaps,
if you have a good quality BASIC library then C is not so much easier. ;-)

For desktop applications with BASIC I would recommend using the Toolbox,
and most of those structure problems disappear. I am happy to write my
own library, but AppBasic is the obvious suggestion for a general
library, and it has excellent tutorials.

On 08/11/2021 09:49, Steve Drain wrote:
> On 07/11/2021 20:12, Matthew Phillips wrote:
>
>> Well, you can make C just as hard as BASIC if you make all the calls
>> using
>> _kernel_swi or similar!  For an example of that approach (not
>> recommended)
>> see the series by Paul Johnson in Archive many years ago.
>>
>> If you use OSLib, or a higher-level library like Desk, DeskLib or Steve
>> Fryatt's SFLib, then I would agree, C is easier than BASIC.
>
> So, it comes down to the quality of the library you use then. Perhaps,
> if you have a good quality BASIC library then C is not so much easier. ;-)

No matter how good a BASIC library is, it can't get around the problem
that BASIC does not have rich enough data types to interact with the
Wimp, without resorting to memory blocks and indirection operators.

> For desktop applications with BASIC I would recommend using the Toolbox,
> and most of those structure problems disappear. I am happy to write my
> own library, but AppBasic is the obvious suggestion for a general
> library, and it has excellent tutorials.

I'm not sure using Toolbox overcomes the problem I've described, it
still requires a set of rich data types, which BASIC can't do.

---druck

In message <smaru5$130f$1@gioia.aioe.org>
Steve Drain <steve@kappa.me.uk> wrote:

>On 07/11/2021 20:12, Matthew Phillips wrote:
>
>> Well, you can make C just as hard as BASIC if you make all the calls using
>> _kernel_swi or similar! For an example of that approach (not recommended)
>> see the series by Paul Johnson in Archive many years ago.
>>
>> If you use OSLib, or a higher-level library like Desk, DeskLib or Steve
>> Fryatt's SFLib, then I would agree, C is easier than BASIC.
>
>So, it comes down to the quality of the library you use then. Perhaps,
>if you have a good quality BASIC library then C is not so much easier. ;-)
>
>For desktop applications with BASIC I would recommend using the Toolbox,
>and most of those structure problems disappear. I am happy to write my
>own library, but AppBasic is the obvious suggestion for a general
>library, and it has excellent tutorials.

Another one to consider is Dr Wimp for the same reasons.

--
Kev Wells
http://kevsoft.co.uk/ https://ko-fi.com/kevsoft
carpe cervisium
But it's " Saviour of 'is country " when the guns begin to shoot;

On 08/11/2021 11:49, druck wrote:

> I'm not sure using Toolbox overcomes the problem I've described, it
> still requires a set of rich data types, which BASIC can't do.

Of course, it does not remove all use of indirection, but the many
window, icon and menu structures are no longer needed. Any decent
library will hide the small amount necessary. That still leaves memory
management and event handling though. I agree, those who can should use
C, but BASIC can be used in pretty 'easy' way. ;-)