Re: Director's Calendar - weird bug

[Harriet Bazley]

On 2 Aug 2022 as I do recall,
Harriet Bazley wrote:

> Yesterday (i.e. before midnight on Monday) the !Calendar app inside
> Director

!Director.Apps.!Calendar


> was telling me that it was Sun 1st August. Now it has rolled over to
> correct itself to Tuesday 2nd August... while I was in the middle of
> trying to debug it, so we shall never know what was going on!
>

There is definitely a bug in this app affecting *every* first day of the
month, which will always get displayed in the wrong column, as can be
demonstrated by forcibly setting the value of TIME$ just before it gets
checked. Put it back to 1st August, or 1st June, or 1st July, and they
all go wrong in the same manner.

It is too late at night and I can't get my head around why exactly the
program is doing what it is doing: the calculation is
(VAL(MID$(TIME$,5,2))+16+calday%) when calculating the icon handle to
highlight in red for 'today', where the icon numbers start at 18 for the
first Sunday in a month, and where calday% starts off as the index into
an array of day names where Sunday is 1, and is then cycled downwards
according to the date value to form an arbitrary offset pointer:

FOR n=VAL(MID$(TIME$,5,2)) TO 2 STEP -1
PROCcalday_change(-1)
NEXT n

DEF PROCcalday_change(nd)
calday%=calday%+nd
IF calday%<1 calday%=7
IF calday%>7 calday%=1
ENDPROC

I would *assume* that the problem is that PROCcalday_change gets called
the same number of times whether VAL(MID$(TIME$,5,2)) is 01 or 02, since
the FOR loop isn't being allowed to go below 2, but I don't see why that
causes the value of calday% to (apparently) be one integer smaller than
it ought to be if TIME$ contains 01.

The routine that is printing the numbers from 1 to (no_of_days_in_month)
puts day 1 in the wrong column when the value of calday% is wrong, too:

FOR n=1 TO monthd(calmonth%)
PROCset_icon_string(calendar%,(16+calday%+n),STR$(n))
NEXT n


But if I experimentally alter the FOR loop to go to 1 STEP -1 that makes
everything go haywire, so there is clearly a good reason for this odd
constraint!

--
Harriet Bazley == Loyaulte me lie ==

The attacker must vanquish; the defender need only survive.

[Martin]

In article <483b6a115...@bazleyfamily.co.uk>,

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> On 2 Aug 2022 as I do recall,
> Harriet Bazley wrote:

> > Yesterday (i.e. before midnight on Monday) the !Calendar app
> > inside Director

> !Director.Apps.!Calendar

> > was telling me that it was Sun 1st August. Now it has rolled
> > over to correct itself to Tuesday 2nd August... while I was in
> > the middle of trying to debug it, so we shall never know what was
> > going on!

I hate bugs which hide.

It is much easier to debug if you add
time$ = TIME$
at the start, and replace all other TIME$ with time$.
Then you can set time$ to any value for debugging, without messing
with time itself.

> There is definitely a bug in this app affecting *every* first day
> of the month, which will always get displayed in the wrong column,
> as can be demonstrated by forcibly setting the value of TIME$ just
> before it gets checked. Put it back to 1st August, or 1st June,
> or 1st July, and they all go wrong in the same manner.

> It is too late at night and I can't get my head around why exactly
> the program is doing what it is doing: the calculation is
> (VAL(MID$(TIME$,5,2))+16+calday%) when calculating the icon handle
> to highlight in red for 'today', where the icon numbers start at 18
> for the first Sunday in a month, and where calday% starts off as
> the index into an array of day names where Sunday is 1, and is then
> cycled downwards according to the date value to form an arbitrary
> offset pointer:

> FOR n=VAL(MID$(TIME$,5,2)) TO 2 STEP -1
> PROCcalday_change(-1)
> NEXT n

That looks wrong - it certainly introduces an anomaly when it is the
1st, as calday% is set to the same number as for 2nd.

> DEF PROCcalday_change(nd)
> calday%=calday%+nd
> IF calday%<1 calday%=7
> IF calday%>7 calday%=1
> ENDPROC

> I would *assume* that the problem is that PROCcalday_change gets
> called the same number of times whether VAL(MID$(TIME$,5,2)) is 01
> or 02, since the FOR loop isn't being allowed to go below 2,

Agreed!

> but I don't see why that causes the value of calday% to
> (apparently) be one integer smaller than it ought to be if TIME$
> contains 01.

Agreed again.

> The routine that is printing the numbers from 1 to
> (no_of_days_in_month) puts day 1 in the wrong column when the value
> of calday% is wrong, too:

> FOR n=1 TO monthd(calmonth%)
> PROCset_icon_string(calendar%,(16+calday%+n),STR$(n))
> NEXT n

That is because calday% is wrong.

> But if I experimentally alter the FOR loop to go to 1 STEP -1 that
> makes everything go haywire, so there is clearly a good reason for
> this odd constraint!

I think it should be 1 STEP -1, as that corrects calday%.
Then the two calls to PROCset_icon_colour should be changed from +16
to +17 which corrects the colours.
I think!

It would be much easier to use Territory_ConvertTimeToOrdinals !!

Martin

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

[Harriet Bazley]

On 2 Aug 2022 as I do recall,

Martin wrote:

> In article <483b6a115...@bazleyfamily.co.uk>,
> Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> > On 2 Aug 2022 as I do recall,
> > Harriet Bazley wrote:
>
> > > Yesterday (i.e. before midnight on Monday) the !Calendar app
> > > inside Director
>
> > !Director.Apps.!Calendar
>
> > > was telling me that it was Sun 1st August. Now it has rolled
> > > over to correct itself to Tuesday 2nd August... while I was in
> > > the middle of trying to debug it, so we shall never know what was
> > > going on!
>
> I hate bugs which hide.
>
> It is much easier to debug if you add
> time$ = TIME$
> at the start, and replace all other TIME$ with time$.
> Then you can set time$ to any value for debugging, without messing
> with time itself.

That's a much better idea - I had to quit all my Internet stuff to avoid
problems with messed-up dates and Messenger expiring things every time I
changed TIME$....

>
> > There is definitely a bug in this app affecting *every* first day
> > of the month, which will always get displayed in the wrong column,
> > as can be demonstrated by forcibly setting the value of TIME$ just
> > before it gets checked. Put it back to 1st August, or 1st June,
> > or 1st July, and they all go wrong in the same manner.

I'm also more than a little surprised that no-one has ever run into this
particular bug since 1992, when the Calendar app was written!

>
> > It is too late at night and I can't get my head around why exactly
> > the program is doing what it is doing: the calculation is
> > (VAL(MID$(TIME$,5,2))+16+calday%) when calculating the icon handle
> > to highlight in red for 'today', where the icon numbers start at 18
> > for the first Sunday in a month, and where calday% starts off as
> > the index into an array of day names where Sunday is 1, and is then
> > cycled downwards according to the date value to form an arbitrary
> > offset pointer:

I think this is probably an exemplar of why it is a Bad Idea to reuse
your variables for other purposes (which I do myself all the time) - it
becomes extremely confusing as to what function the variable is actually
performing at any given point in the program.

Hmmm. That seems to correct the 1st August problem, but reliably
crashes with an abort on data transfer if I attempt to display August
2021 or May 2022 - presumably because a bad icon number is being passed
to FNstring_addr(window, icon%)

DEF FNstring_addr(window%,icon%)
REM returns address of icon's indirected text string
LOCAL c%
c%=b%+500
!c%=window%
c%!4=icon%
SYS "Wimp_GetIconState",,c%
=c%!28

Edit: yes, it crashes if icon% reaches 55, at which point c%!28 becomes
a rubbish value.
And icon% reaches 55 on months that start on a Sunday... although it
does *not* crash on November 2020. It just displays a completely blank
line for the first week, and starts on the following Sunday. Why?!!!

>
> It would be much easier to use Territory_ConvertTimeToOrdinals !!
>

I'm not sure it would help that much for the icon position/number
calculation, which is where the program is falling over (and which is
the part where I frankly haven't got my head around the logic).

--
Harriet Bazley == Loyaulte me lie ==

If it's not broken, don't fix it.

[Paul Sprangers]

In article <483b6a115...@bazleyfamily.co.uk>,
Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

To me, the code doesn't look extremely efficient. For example, the redraw
routine will never be called, as the window consists of icons only.

Anyhow, it seems that this small change may work, as far as I've tested it
(admittedly, not very far):

date% = VAL(MID$(time$,5,2))
IF date% > 1 THEN
FOR n=date% TO 2 STEP -1
PROCcalday_change(-1)
NEXT n
ENDIF

Paul

--
https://riscos.sprie.nl

[Harriet Bazley]

On 2 Aug 2022 as I do recall,

Paul Sprangers wrote:


> To me, the code doesn't look extremely efficient. For example, the redraw
> routine will never be called, as the window consists of icons only.

There was at some stage in the past a ghostly PROCdraw, to which I have
removed the REMmed out call since the procedure doesn't actually exist
in the program any more....

> Anyhow, it seems that this small change may work, as far as I've tested it
> (admittedly, not very far):
>
> date% = VAL(MID$(time$,5,2))
> IF date% > 1 THEN
> FOR n=date% TO 2 STEP -1
> PROCcalday_change(-1)
> NEXT n
> ENDIF
>

I committed the cardinal sin of not saving a copy of the original before
starting my tinkering about, but I *think* I managed to undo everything
before inserting this replacement, and it does seem to work, thanks - in
that it doesn't obviously crash, anyway, and doesn't generate months
with blank lines, although I didn't double-check to make sure that it
does put all the days in the correct columns.

It makes sense as a way of isolating the specific case that is causing
the problem, e.g. the date is 01 (as opposed to trying to work out the
principle behind the algorithm used to position the dates and bug-fix
that from first principles!)

--
Harriet Bazley == Loyaulte me lie ==

Time is nature's way of making sure that everything doesn't happen at once.

[Harriet Bazley]

On 2 Aug 2022 as I do recall,

Harriet Bazley wrote:

> On 2 Aug 2022 as I do recall,
> Paul Sprangers wrote:

[snip]

> > Anyhow, it seems that this small change may work, as far as I've tested it
> > (admittedly, not very far):

[snip]

> I committed the cardinal sin of not saving a copy of the original before
> starting my tinkering about, but I *think* I managed to undo everything
> before inserting this replacement, and it does seem to work, thanks - in
> that it doesn't obviously crash, anyway, and doesn't generate months
> with blank lines, although I didn't double-check to make sure that it
> does put all the days in the correct columns.

I tried posting to the Director mailing list earlier, but nothing ever
appeared - the mailing list archives at Sourceforge appear to be empty,
and my attempt at contacting the developers failed.

----- Transcript of session follows -----
... while talking to mx.sourceforge.net.:
>>> DATA
<<< 550 unknown user
550 5.1.1 <phil...@users.sourceforge.net>... User unknown
<<< 451-81.5.176.45 is not yet authorized to deliver mail from
<<< 451-<har...@bazleyfamily.co.uk> to <director-...@lists.sourceforge.net>.
<<< 451 Please try later.

Who is currently supporting/distributing the Director software?

--
Harriet Bazley == Loyaulte me lie ==

A man's best friend is his dogma.

[Paul Sprangers]

In article <f702c4115...@bazleyfamily.co.uk>,

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

> I committed the cardinal sin of not saving a copy of the original before
> starting my tinkering about,

Haha, that sounds very familiar. F8 is a good friend, to some extend. But
even then I far too often managed to mangle source codes (especially my
own) beyond repair.

Paul

--
https://riscos.sprie.nl

[Martin]

In article <f702c4115...@bazleyfamily.co.uk>,

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> On 2 Aug 2022 as I do recall,
> Paul Sprangers wrote:

> > Anyhow, it seems that this small change may work, as far as I've
> > tested it (admittedly, not very far):
> >
> > date% = VAL(MID$(time$,5,2))
> > IF date% > 1 THEN
> > FOR n=date% TO 2 STEP -1
> > PROCcalday_change(-1)
> > NEXT n
> > ENDIF

Having done a bit more tinkering, I would agree that Paul's suggestion
(and no other changes) fixes the bugs as reported, though I arrived a
a slightly different solution...

date% = VAL(MID$(time$,5,2)) :REM from today's date down to 1st
WHILE date% > 1
PROCcalday_change(-1) :REM subtract 1 from calday%
date% -= 1
ENDWHILE

I also noticed that while the window was open, the processor was being
consumed by 60k+ Null Polls/sec ... easily solved by changing
SYS "Wimp_Poll",,b% TO r%
to
SYS "Wimp_Poll",1,b% TO r%

I would assign the arrays days$(), monthb$(), monthd$() and leapyrs()
by eg:
days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"
rather than RESTORE & READ loops, but that is being picky!

[Harriet Bazley]

On 3 Aug 2022 as I do recall,
Martin wrote:


[snip]

> I also noticed that while the window was open, the processor was being
> consumed by 60k+ Null Polls/sec ... easily solved by changing
> SYS "Wimp_Poll",,b% TO r%
> to
> SYS "Wimp_Poll",1,b% TO r%

Worth doing. I just wish we could get these improvements back into the
original distribution!

>
> I would assign the arrays days$(), monthb$(), monthd$() and leapyrs()
> by eg:
> days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"
> rather than RESTORE & READ loops, but that is being picky!
>

I suspect that would have required a newer version of BASIC than
available when the program was written.

(I didn't know you could do that....)

--
Harriet Bazley == Loyaulte me lie ==

Power tends to corrupt and absolute power corrupts absolutely

[Martin]

In article <b9282f125...@bazleyfamily.co.uk>,

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> On 3 Aug 2022 as I do recall,
> Martin wrote:

> [snip]

> > I also noticed that while the window was open, the processor was
> > being consumed by 60k+ Null Polls/sec ... easily solved by
> > changing

> > SYS "Wimp_Poll",,b% TO r%
> > to
> > SYS "Wimp_Poll",1,b% TO r%

> Worth doing. I just wish we could get these improvements back
> into the original distribution!

I fear any support has vanished a long time ago :-((

> > I would assign the arrays days$(), monthb$(), monthd$() and
> > leapyrs() by eg:
> > days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"
> > rather than RESTORE & READ loops, but that is being picky!

> I suspect that would have required a newer version of BASIC than
> available when the program was written.
> (I didn't know you could do that....)

Nope - it is in my BASIC guide dated 1988!

[Paul Sprangers]

In article <b9282f125...@bazleyfamily.co.uk>,
Harriet Bazley <har...@bazleyfamily.co.uk>

> > days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"

> (I didn't know you could do that....)

(I didn't know that either...)

Paul

--
https://riscos.sprie.nl

[Harriet Bazley]

On 3 Aug 2022 as I do recall,
Martin wrote:

> In article <b9282f125...@bazleyfamily.co.uk>,
> Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> > On 3 Aug 2022 as I do recall,
> > Martin wrote:
>
> > > I also noticed that while the window was open, the processor was
> > > being consumed by 60k+ Null Polls/sec ... easily solved by
> > > changing
>
> > > SYS "Wimp_Poll",,b% TO r%
> > > to
> > > SYS "Wimp_Poll",1,b% TO r%
>
> > Worth doing. I just wish we could get these improvements back
> > into the original distribution!
>
> I fear any support has vanished a long time ago :-((
>

At some point since 2015, apparently....

--
Harriet Bazley == Loyaulte me lie ==

It is impossible to enjoy idling thoroughly unless one has plenty of work to do

[Theo]

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> Who is currently supporting/distributing the Director software?

I'm not sure if anyone is, but I note the CVS repository is still alive:
http://director.cvs.sourceforge.net/

So it's there if anyone wants to take it on - eg convert it to another
version control system and host it elsewhere, from where it would be easier
to apply changes and make new releases.

Anyone want to do it?

Theo
(riscos.info can offer SVN hosting, although I tend to recommend github
for hosting repos these days as it's more robust)

[Steve Fryatt]

On 4 Aug, Theo wrote in message
<VaC*cU...@news.chiark.greenend.org.uk>:

> I'm not sure if anyone is, but I note the CVS repository is still alive:
> http://director.cvs.sourceforge.net/
>
> So it's there if anyone wants to take it on - eg convert it to another
> version control system and host it elsewhere, from where it would be
> easier to apply changes and make new releases.
>
> Anyone want to do it?

I could have a look if anyone would actually make use of it. Director's a
permanent fixture on my iconbar, so there's some self-interest.

> Theo (riscos.info can offer SVN hosting, although I tend to recommend
> github for hosting repos these days as it's more robust)

Would the riscos.info project on GitHub be a sensible place for it?

(I should probably get around to finishing the work that I was doing there
on StrongHelp and WinEd sometime, too...).

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[Theo]

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 4 Aug, Theo wrote in message
> <VaC*cU...@news.chiark.greenend.org.uk>:
>

> > Theo (riscos.info can offer SVN hosting, although I tend to recommend
> > github for hosting repos these days as it's more robust)
>
> Would the riscos.info project on GitHub be a sensible place for it?

Sounds as good as any. There is already a summary page in the wiki:
https://www.riscos.info/index.php/Director

and it would be possible to link to releases from there.

Theo

[druck]

On 04/08/2022 20:42, Steve Fryatt wrote:
> On 4 Aug, Theo wrote in message
> <VaC*cU...@news.chiark.greenend.org.uk>:

>> Theo (riscos.info can offer SVN hosting, although I tend to recommend
>> github for hosting repos these days as it's more robust)
>
> Would the riscos.info project on GitHub be a sensible place for it?

Get as much RISC OS source code on there as possible, then GitHubs
copilot be able to knockout RISC OS applications automatically - lack of
developers solved! [Joke]

---druck