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

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

Postby Josef Templ » Mon May 25, 2015 7:28 am

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/projects/blackbox/repository/revisions/55d80e48b0452a07236ad56dde1570a44fb7ec1e.

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
Josef Templ
 
Posts: 2003
Joined: Tue Sep 17, 2013 6:50 am

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

Postby DGDanforth » Tue May 26, 2015 5:05 am

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
DGDanforth
 
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA

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

Postby Josef Templ » Tue May 26, 2015 10:07 am

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
User avatar
Josef Templ
 
Posts: 2003
Joined: Tue Sep 17, 2013 6:50 am

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

Postby Ivan Denisov » Tue May 26, 2015 4:59 pm

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.
Ivan Denisov
 
Posts: 1694
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

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

Postby Josef Templ » Wed May 27, 2015 7:47 am

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
User avatar
Josef Templ
 
Posts: 2003
Joined: Tue Sep 17, 2013 6:50 am


Return to Resolved (Bugs)

Who is online

Users browsing this forum: No registered users and 1 guest

cron