issue-#52 fixing wrong DevCommanders.par.beg/end

Post Reply
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

issue-#52 fixing wrong DevCommanders.par.beg/end

Post by Josef Templ »

OberonCore has observed that the text range that describes the parameters of a command (beg/end)
in DevCommanders is not always set as expected. For most situations this is irrelevant in practice,
but there are bugs indeed (OberonCore B11).
See the issue at http://redmine.blackboxframework.org/issues/52.

A proposal for fixing this exists in CPC 1.7 rc5.
I have put those changes into topic branch issue-#52.
See the diffs at http://redmine.blackboxframework.org/pr ... a44fb7ec1e.

I have slightly modified the proposal:
1. the test for v # NIL is not required because it is implied by ~r.eot.
2. similar changes have been applied to ScriptConfig, our internally used scripting mechanism for the BlackBox build engine.

When studying the changes the following question came up:
What is Properties.ThisType good for in GetParExtend as shown below?
It is a rarely used and undocumented feature of BB. OberonCore originally replaced it
by Services.Is but later changed it back to using Properties.ThisType again.
(Note: Instead of Services.Is a better replacement would have been to simply use the type test operator IS.)
I cannot find a reason why Properties.ThisType is required and it is not clear to me what it is used for in general.

Code: Select all

	PROCEDURE GetParExtend (r: TextModels.Reader; VAR end: INTEGER);
		VAR v: Views.View;
	BEGIN
		IF r.view # NIL THEN v := r.view ELSE r.ReadView(v) END;
		WHILE ~r.eot 
				& (Properties.ThisType(v, "DevCommanders.View") = NIL) 
				& (Properties.ThisType(v, "DevCommanders.EndView") = NIL) DO
			r.ReadView(v)
		END;
		end := r.Pos(); IF ~r.eot THEN DEC(end) END
	END GetParExtend;
- Josef
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: issue-#52 fixing wrong DevCommanders.par.beg/end

Post by DGDanforth »

Using GftSearchFiles run over all "Mod" files on my BB1.6 system I find

Location
Bbt/Mod/Commanders.odc
Properties.ThisType [3]
Dev/Mod/Commanders.odc
Properties.ThisType [3]
Dev/Mod/MsgSpy.odc
Properties.ThisType [1]
Host/Mod/TextConv.odc
Properties.ThisType [1]
My/Mod/TextConv.odc
Properties.ThisType [1]
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#52 fixing wrong DevCommanders.par.beg/end

Post by Josef Templ »

can anybody contact the experts from OberonCore regarding the
undocumented Properties.TypePref message?
Why has it been introduced and what is it needed for in general
and why is it needed in DevCommanders in particular?

- Josef
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#52 fixing wrong DevCommanders.par.beg/end

Post by Ivan Denisov »

Josef Templ wrote:can anybody contact the experts from OberonCore regarding the
undocumented Properties.TypePref message?
Why has it been introduced and what is it needed for in general
and why is it needed in DevCommanders in particular?

- Josef
Peter gave me some prompt:
Wrap is not always heir. Messages arriving even if types are differ.
This helped me to make minimalistic demo:

Code: Select all

MODULE DemoWrapper;
	IMPORT  Log, Views, Properties, Ports, Stores, Services;
	
	TYPE
		View = POINTER TO ABSTRACT RECORD (Views.View) END;
		StdView = POINTER TO RECORD (View) END;
		StdViewWrapper = POINTER TO RECORD (Views.View) inner: StdView; END;
	
	PROCEDURE (v: StdView) Restore (f: Views.Frame; l, t, r, b: INTEGER);
	BEGIN f.DrawRect(l, t, r, b, Ports.fill, Ports.red)
	END Restore;
	
	PROCEDURE (v: StdViewWrapper) Restore (f: Views.Frame; l, t, r, b: INTEGER);
	BEGIN Views.InstallFrame(f, v.inner, 0, 100 * f.dot, 0, TRUE)
	END Restore;
	
	PROCEDURE (v: StdView) HandlePropMsg (VAR msg: Properties.Message);
	BEGIN
		WITH msg: Properties.Preference DO
			WITH msg: Properties.TypePref DO
				IF Services.Is(v, msg.type) THEN msg.view := v END
			ELSE END
		ELSE END
	END HandlePropMsg;
	
	PROCEDURE (v: StdViewWrapper) HandlePropMsg (VAR msg: Properties.Message);
	BEGIN Views.HandlePropMsg(v.inner, msg)
	END HandlePropMsg;
	
	PROCEDURE New(): View;
	VAR v: StdView;
	BEGIN NEW(v); RETURN v
	END New;
	
	PROCEDURE Wrap(inner: View): StdViewWrapper;
		VAR v: StdViewWrapper;
	BEGIN
		NEW(v);
		WITH inner: StdView DO
			v.inner := inner;
			Stores.Join(v, v.inner);
			RETURN v
		ELSE RETURN NIL END
	END Wrap;
	
	PROCEDURE Do*;
		VAR v1: View; v2: StdViewWrapper;
	BEGIN
		v1 := New();
		v2 := Wrap(v1);
		IF Properties.ThisType(v1, "DemoWrapper.StdView") # NIL THEN
			Log.Bool(v1 IS StdView); Log.Ln;
		END;
		IF Properties.ThisType(v2, "DemoWrapper.StdView") # NIL THEN
			Log.Bool(TRUE); Log.Ln;
		END;
	END Do;

END DemoWrapper.

DemoWrapper.Do
Here this code even can not be compiled:

Code: Select all

Log.Bool(v2 IS StdView); Log.Ln;
Also the same situation if you wrap the TextViews.View by the ObxWrappers.View.
ObxWrappers.View is not heir of TextViews.View.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#52 fixing wrong DevCommanders.par.beg/end

Post by Josef Templ »

Thanks. There are still some questions open.
For example: Why is the Properties.TypePref message handled in TextViews.View
but not in FormViews.View?
Anyway, for the DevCommanders changes it is probably best to leave it as it is, i.e.
to use the clumsy Properties.ThisType procedure instead of the type test operator IS.
This way there are no observable changes even if somebody creates a wrapper
around DevCommander views.

- Josef
Post Reply