DevCPT Vote

[DGDanforth]

The discussion of this issue is here
This vote will use the STABLE (Short Circuit) rule of voting.

[warnersoft]

I apologize for my tardiness in reviewing this issue for this vote. I think the reason this never went to vote earlier is because there does not appear to be a resolution the Josef's question regarding the procedure names. He suggested OutHdBaseFlds and FPrintHdBaseFlds. Is that a valid or desirable suggestion? Is this same fix included in code that was just released by Helmut? If so, is it implemented in the same way?

[Ivan Denisov]

I apologize for my tardiness in reviewing this issue for this vote.

Marco made very good demo: http://redmine.blackboxframework.org/issues/1
You can run it in BlackBox 1.6.

He suggested OutHdBaseFlds and FPrintHdBaseFlds. Is that a valid or desirable suggestion?

This is desirable suggestion, from my point of view. However it has no influence on the result.

Is that a valid or desirable suggestion? Is this same fix included in code that was just released by Helmut? If so, is it implemented in the same way?

I think that about Helmut version he will answer by him self. I did not check yet.

[Josef Templ]

In order to see what we are discussing about, I have created a topic branch for issue-#13.
The bug fix is already contained in Helmut's latest version.
I have taken this bug fix and committed the changes to the topic branch.
See https://github.com/BlackBoxCenter/black ... ssue-%2313

Yes, Helmut's bug fix uses the naming as suggested by me earlier.

Please have a look at
http://redmine.blackboxframework.org/pr ... od/CPT.odc
for seeing the differences.

My vote for YES is under the precondition that proper naming is used.

- Josef

[cfbsoftware]

The proposed corrections do not look right to me.

a) I do not understand why new procedures are needed. I believe that an additional recursive call to the existing procedure would suffice in each case.

Code: Select all

			IF typ.comp = Record THEN 
			   IF typ.BaseTyp # NIL THEN FPrintHdFld(typ.BaseTyp, fld, adr) END;   (* additional call *)
				FPrintFlds(typ.link, adr, FALSE)

Code: Select all

		IF typ.comp = Record THEN 
			IF typ.BaseTyp # NIL THEN OutHdFld(typ.BaseTyp, fld, adr) END;   (* additional call *)
			OutFlds(typ.link, adr, FALSE)

b) If I am wrong, and the new procedures are needed, shouldn't there be another check for typ.BaseTyp = Record in OutHdBaseFlds and FPrintHdBaseFlds for when they are called by themselves? Otherwise, what happens if typ.BaseTyp is not a record? Was there a test case written to check that?

[Josef Templ]

> a) I do not understand why new procedures are needed. I believe that an additional recursive call to the existing procedure would suffice in each case.

If you want to preserve the order of extension levels in the processing (i.e. starting with the very base level), it is the simplest approach to use recursion.
Otherwise a WHILE loop in OutHdFld would be sufficient.
Now, which procedure do you want to call recursively instead of OutHdBaseFlds? Probably you mean OutHdFld.
This does not work because OutHdFld is called for a single field, not for a type.
Note the parameter fld. If you try to code it, you will see it immediately.

> b) If I am wrong, and the new procedures are needed, shouldn't there be another check for typ.BaseTyp = Record in OutHdBaseFlds and FPrintHdBaseFlds for when they are called by themselves? Otherwise, what happens if typ.BaseTyp is not a record? Was there a test case written to check that?

BaseTyp of a record is always a record or NIL. No need for an additional check.

- Josef

[cfbsoftware]

Now, which procedure do you want to call recursively instead of OutHdBaseFlds? Probably you mean OutHdFld.

Yes. See the code below - the statement with the comment against it.

This does not work because OutHdFld is called for a single field, not for a type.
Note the parameter fld. If you try to code it, you will see it immediately.

Parameter fld is passed in, but is just ignored in that part of the code. I did code it (exactly as shown in my previous post):

Code: Select all

		IF typ.comp = Record THEN 
			IF typ.BaseTyp # NIL THEN OutHdFld(typ.BaseTyp, fld, adr) END;   (* additional call *)
			OutFlds(typ.link, adr, FALSE)

and it does work for the test case that was provided. Try it and see for yourself. If there are any more test cases let me know and I'll try it with those as well.

At the end of the day, all that is required is that OutFlds is called in the correct sequence, with the correct values, the correct number of times. You do not need the additional intermediate procedure call to make that happen.

[Josef Templ]

> Parameter fld is passed in, but is just ignored in that part of the code. I did code it (exactly as shown in my previous post):

You are right. I didn't read the code in your posting carefully enough.
fld is ignored for Record, so your solution works and is much better than the existing one.
I have adjusted it in the topic branch issue-#13.

- Josef

[DGDanforth]

If Chris' solution is correct then one should vote NO for the current DevCPT vote as written and a new vote started for Chris's solution. Do people agree with that?

Your vote is changeable for this poll.

[DGDanforth]

CAUTION!

I made Chris' changes to DevCPT and tested it and it worked.
BUT after compiling another module of mine and attempting to run it
I got the message that Controllers was inconsistently imported.
I tried recompiling Controllers and got a long list saying that some pointers were
hidden and their addresses.
I excited BB and tried to restart but it failed!
I then deleted DevCPT.ocf and Controllers.ocf
and successfully restarted BB. I then recompiled my original module (old DevCPT) and it ran correctly.

SO I think that all may be due to the change in DevCPT which may have found problems in
other code. I am guessing that if all of the modules of BB are recompiled with Chris' change
then everything might work correctly. But that is a guess.

Anyone else find any problems compiling and running programs using the change to DevCPT?
-Doug