Void safe vision library

[the blind squirrel]

Dear friends of Eiffel,

I am rewriting a WEL application I wrote several years ago to use Vision2. I have all the user interface classes built (more or less), using EiffelBuild and EiffelStuio 6.4 for Linux. The application, such as it is (only 2 user interface classes plus a few supporting classes created by EiffelBuild), compiles without error using the standard, non-void-safe 'base' and 'vision' libraries. It also compiles without error with void safety set to 'on demand void safety'. It runs successfully too.

However, switching to 'complete void safety', and replacing the standard 'base' and 'vision2' libraries with 'base-safe' and 'vision2' void safe libraries, then recompiling after cleaning, results in numerous compilation errors. Most are in classes from the vision2 library, others in the CONSTANTS_IMP class generated by EiffelBuild. When choosing the void safe libraries to use, I first removed the non-void-safe libraries, then, using the 'Add library' dialog of 'Project settings', checked the 'Show only void safe libraries' box, and selected 'base-safe' and 'vision2'.

Have I selected the correct libraries? Is there something else I need to do to get a clean compile? Are the classes generated by EiffelBuild void safe?

I would greatly appreciate any advice, and apologize if this topic has already been covered. I did search the archive but came up empty.


David Jenkins

[peter7723]

--- In [hidden email], "djenkins99a"
> Have I selected the correct libraries? Is there something else I need to do to get a clean compile? Are the classes generated by EiffelBuild void safe?

Hello David.

Did you run EiffelStudio in Experiment Mode? In Windows, use the shortcut or start estudio or ec with the "experiment" switch. E.G.,

C:\Eiffel64\studio\spec\windows\bin\estudio.exe -experiment

Peter Horan

[the blind squirrel]

Hello Peter,

Thank you for your message. '-experiment' made a huge difference! All of
the errors related to the vision2 library disappeared.

There are still errors in the classes generated by EiffelBuild. Many are
in the CONSTANTS class, where objects created in once functions are
referenced, like this:

     box_height: INTEGER is
             -- `Result' is INTEGER constant named `box_height'.
         do
             Result := box_height_cell.item    -- The compiler flags this
line
         end

The compiler throws a VUTA error on 'box_height_cell', which is declared
as a once function:

     box_height_cell: CELL [INTEGER] is
             --`Result' is once access to a cell holding vale of
`box_height'.
         once
             create Result.put (50)
         end

To me, this appears to be perfectly void safe. 'box_height_cell' will
always be attached to an object, since it's the result of a once
function. Apparently the compiler thinks otherwise.

How do I resolve an error like this? Are once functions not part of the
'experiment'?

Another even more puzzling error is thrown in this routine:

     make_and_launch
             -- Create `Current', build and display `main_window',
             -- then launch the application.
         do
             default_create
             create main_window
             main_window.show   -- the compiler flags this line
             launch
         end

I get another VUTA error on the 3rd line. This really surprised me,
since 'main_window' is created in the preceding line. It has to be
attached at that point, doesn't it?

--- In [hidden email], "peter7723" <peter@...> wrote:
>
> --- In [hidden email], "djenkins99a"
> > Have I selected the correct libraries? Is there something else I
need to do to get a clean compile? Are the classes generated by
EiffelBuild void safe?
>
> Hello David.
>
> Did you run EiffelStudio in Experiment Mode? In Windows, use the
shortcut or start estudio or ec with the "experiment" switch. E.G.,
>
> C:\Eiffel64\studio\spec\windows\bin\estudio.exe -experiment
>
> Peter Horan
>



[Non-text portions of this message have been removed]

[peter7723]

--- In [hidden email], "djenkins99a" <djenkins99@...> wrote:

>
> Hello Peter,
>
> Thank you for your message. '-experiment' made a huge difference! All of
> the errors related to the vision2 library disappeared.
>
> There are still errors in the classes generated by EiffelBuild. Many are
> in the CONSTANTS class, where objects created in once functions are
> referenced, like this:
>
>      box_height: INTEGER is
>              -- `Result' is INTEGER constant named `box_height'.
>          do
>              Result := box_height_cell.item    -- The compiler flags this
> line
>          end
>
> The compiler throws a VUTA error on 'box_height_cell', which is declared
> as a once function:
>
>      box_height_cell: CELL [INTEGER] is
>              --`Result' is once access to a cell holding vale of
> `box_height'.
>          once
>              create Result.put (50)
>          end
>
> To me, this appears to be perfectly void safe. 'box_height_cell' will
> always be attached to an object, since it's the result of a once
> function. Apparently the compiler thinks otherwise.

No. It is not attached before its first use and the once routine excuted. If you have checked "Are typed attached by default?", you will get VUTA.

> How do I resolve an error like this? Are once functions not part of the
> 'experiment'?
>
> Another even more puzzling error is thrown in this routine:
>
>      make_and_launch
>              -- Create `Current', build and display `main_window',
>              -- then launch the application.
>          do
>              default_create
>              create main_window
>              main_window.show   -- the compiler flags this line
>              launch
>          end
>
> I get another VUTA error on the 3rd line. This really surprised me,
> since 'main_window' is created in the preceding line. It has to be
> attached at that point, doesn't it?

Yes. That is what one would expect. But, it is possible becuase main_window is accessible from elsewhere (multi-threading and other obscure (obtuse) sigle threade situations for main_window to be void. The guarantee is intende to be 100%.

Instead, mark main_window detachable and use a void test.

      make_and_launch
              -- Create `Current', build and display `main_window',
              -- then launch the application.
          do
              default_create
              create main_window
              if attached main_window as m_w then
                  m_w.show
              launch
          end


Local variables can also be used:
      make_and_launch
              -- Create `Current', build and display `main_window',
              -- then launch the application.
          local
              m_w: MAIN_WINDOW
          do
              default_create
              create m_w
              m_w.show   -- the compiler flags this line
              main_window := m_w
              launch
          end

The point about local variables is that they are private to the routine.

Peter Horan

[the blind squirrel]

Hello Peter,

Thank you again for your reply. I have a few more questions, I'm
obviously struggling to understand the void safety rules.

> >
> > The compiler throws a VUTA error on 'box_height_cell', which is
declared

> > as a once function:
> >
> > box_height_cell: CELL [INTEGER] is
> > --`Result' is once access to a cell holding vale of
> > `box_height'.
> > once
> > create Result.put (50)
> > end
> >
> > To me, this appears to be perfectly void safe. 'box_height_cell'

will
> > always be attached to an object, since it's the result of a once
> > function. Apparently the compiler thinks otherwise.
>
> No. It is not attached before its first use and the once routine
excuted. If you have checked "Are typed attached by default?", you will
get VUTA.

I understand your explanation, but doesn't this subject all once
functions returning an attached type to a Catch-22, where the value that
the function returns isn't attached before it's called, but it can't be
called (the compiler will throw a VUTA) because it's not attached? This
implies, to me anyway, that once functions returning an attached type
can never be used in a void safe application. That would be a shame.

> > make_and_launch
> > -- Create `Current', build and display `main_window',
> > -- then launch the application.
> > do
> > default_create
> > create main_window
> > main_window.show -- the compiler flags this line
> > launch
> > end
> >
> > I get another VUTA error on the 3rd line. This really surprised me,
> > since 'main_window' is created in the preceding line. It has to be
> > attached at that point, doesn't it?
>
> Yes. That is what one would expect. But, it is possible becuase

main_window is accessible from elsewhere (multi-threading and other
obscure (obtuse) sigle threade situations for main_window to be void.
The guarantee is intende to be 100%.
>

I should have given you more information about 'make_and_launch'.
EiffelBuild generated a root class, VISION2_APPLICATION, for me.
'make_and_launch' is its sole creation procedure:

class
     VISION2_APPLICATION

inherit
     EV_APPLICATION

create
     make_and_launch
feature {NONE} -- Initialization
     make_and_launch
             -- Create `Current', build and display `main_window',
             -- then launch the application.
         do
             default_create
             create main_window
             main_window.show
             launch
         end

'main_window' is an attribute of VISION2_APPLICATION:

feature {NONE} -- Implementation

     main_window: MAIN_WINDOW

It seems to me that the creation procedure has to be able to attach all
its attachable attributes, under all circumstances, multi-threading or
otherwise. Failing that, they're unusable.

Also, the way I read the explanation and example on page 7 of the
void-safe-eiffel paper (found at
http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf),
'main_window' is properly set at the moment 'show' is invoked.
void-safe-eiffel says that

"A variable x of type T is properly set at a certain position if one of
the instructions preceding that position is an assignment to x (which,
thanks to the Attachment Preservation rule, gives it an attached value
if T is an attached type) or a creation instruction of target x (of the
form create x)."
I learned long ago not to suspect that the compiler has made an error,
but in this case, I think it's wrong.



[Non-text portions of this message have been removed]

[Jimmy Johnson]

What is this "experimental" mode?  Must I use that when converting my libraries to void safety?



--- In [hidden email], "peter7723" <peter@...> wrote:

>
> --- In [hidden email], "djenkins99a"
> > Have I selected the correct libraries? Is there something else I need to do to get a clean compile? Are the classes generated by EiffelBuild void safe?
>
> Hello David.
>
> Did you run EiffelStudio in Experiment Mode? In Windows, use the shortcut or start estudio or ec with the "experiment" switch. E.G.,
>
> C:\Eiffel64\studio\spec\windows\bin\estudio.exe -experiment
>
> Peter Horan
>

[Emmanuel Stapf]

> What is this "experimental" mode?  Must I use that when converting my
> libraries to void safety?

Indeed. When using the experimental mode you are using a different set of
libraries that are really void-safe. When you are not using this option, your code
might not be truly void-safe when manipulating ARRAYs/SPECIALs. The other reason
for having the option is some tiny breaking changes we introduced on purpose for
notifying our users how to properly handle the ARRAY/SPECIAL case; we wanted
people upgrading to 6.4 to be immune from those changes unless explicitly
requested. And we will continue this in 6.5 although to make it clearer where
void-safe can be used, we are most likely going to remove all the -safe variant of
ECFs when not using experimental.
 
Regards,
Manu

[peter7723]

--- In [hidden email], "the blind squirrel" <djenkins99@...> wrote:

> > > The compiler throws a VUTA error on 'box_height_cell', which is
> declared
> > > as a once function:
> > >
> > > box_height_cell: CELL [INTEGER] is


> I understand your explanation, but doesn't this subject all once
> functions returning an attached type to a Catch-22, where the value that
> the function returns isn't attached before it's called, but it can't be
> called (the compiler will throw a VUTA) because it's not attached? This
> implies, to me anyway, that once functions returning an attached type
> can never be used in a void safe application. That would be a shame.

You could call the once function when initialising the object referencing the once function feature during creation.

Or you could mark it detachable:
   box_height_cell: detachable CELL [INTEGER]
      once
         ...
      end

> I should have given you more information about 'make_and_launch'.
> EiffelBuild generated a root class, VISION2_APPLICATION, for me.
> 'make_and_launch' is its sole creation procedure:
>
> class
>      VISION2_APPLICATION
>
> inherit
>      EV_APPLICATION
>
> create
>      make_and_launch
> feature {NONE} -- Initialization
>      make_and_launch
>              -- Create `Current', build and display `main_window',
>              -- then launch the application.
>          do
>              default_create
>              create main_window
>              main_window.show
>              launch
>          end
>
> 'main_window' is an attribute of VISION2_APPLICATION:
>
> feature {NONE} -- Implementation
>
>      main_window: MAIN_WINDOW
>
> It seems to me that the creation procedure has to be able to attach all
> its attachable attributes, under all circumstances, multi-threading or
> otherwise. Failing that, they're unusable.
>
> Also, the way I read the explanation and example on page 7 of the
> void-safe-eiffel paper (found at
> http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf),
> 'main_window' is properly set at the moment 'show' is invoked.
> void-safe-eiffel says that
>
> "A variable x of type T is properly set at a certain position if one of
> the instructions preceding that position is an assignment to x (which,
> thanks to the Attachment Preservation rule, gives it an attached value
> if T is an attached type) or a creation instruction of target x (of the
> form create x ...)."
> I learned long ago not to suspect that the compiler has made an error,
> but in this case, I think it's wrong.

I can't answer this. I have been annoyed by similar things. It may be as simple that the implementation lags the thinking - the paper is dated 2009. The void-safe compiler is a "work in progress".

Peter Horan

[the blind squirrel]

Peter,

Thank you once again for your answer. Although I haven't tried it yet
today (my opportunities to work with Eiffel must be wedged in between my
regular, paying job and all the other responsibilities of life not
related to the fun of working with Eiffel), I would bet your suggestion,
to call the once function in the creation procedure, would work. But I
don't see why that should be necessary. I still think there's a problem
with once functions that return an attachable type.  I need to read the
void-safe-eiffel document again (that would make at least the 10th time;
I used to be a lot smarter)--I'm taking it to be the up-to-date gospel
on void safety in Eiffel. Then what I think I will do is put together a
simple test application, and post a separate thread about this.

It would also be good to know, from the compiler writers, why the call
to 'main_window' in the creation procedure fails. Perhaps one of them
can fill us in on how completely the compiler conforms to the void
safety rules. I think we agree that there is still work to be done.
--- In [hidden email], "peter7723" <peter@...> wrote:
>
>
>
> --- In [hidden email], "the blind squirrel"
djenkins99@ wrote:

>
> > > > The compiler throws a VUTA error on 'box_height_cell', which is
> > declared
> > > > as a once function:
> > > >
> > > > box_height_cell: CELL [INTEGER] is
>
>
> > I understand your explanation, but doesn't this subject all once
> > functions returning an attached type to a Catch-22, where the value

that
> > the function returns isn't attached before it's called, but it can't
be
> > called (the compiler will throw a VUTA) because it's not attached?
This
> > implies, to me anyway, that once functions returning an attached
type
> > can never be used in a void safe application. That would be a shame.
>
> You could call the once function when initialising the object
referencing the once function feature during creation.

>
> Or you could mark it detachable:
>    box_height_cell: detachable CELL [INTEGER]
>       once
>          ...
>       end
>
> > I should have given you more information about 'make_and_launch'.
> > EiffelBuild generated a root class, VISION2_APPLICATION, for me.
> > 'make_and_launch' is its sole creation procedure:
> >
> > class
> >      VISION2_APPLICATION
> >
> > inherit
> >      EV_APPLICATION
> >
> > create
> >      make_and_launch
> > feature {NONE} -- Initialization
> >      make_and_launch
> >              -- Create `Current', build and display `main_window',
> >              -- then launch the application.
> >          do
> >              default_create
> >              create main_window
> >              main_window.show
> >              launch
> >          end
> >
> > 'main_window' is an attribute of VISION2_APPLICATION:
> >
> > feature {NONE} -- Implementation
> >
> >      main_window: MAIN_WINDOW
> >
> > It seems to me that the creation procedure has to be able to attach

all
> > its attachable attributes, under all circumstances, multi-threading
or
> > otherwise. Failing that, they're unusable.
> >
> > Also, the way I read the explanation and example on page 7 of the
> > void-safe-eiffel paper (found at
> > http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf),
> > 'main_window' is properly set at the moment 'show' is invoked.
> > void-safe-eiffel says that
> >
> > "A variable x of type T is properly set at a certain position if one
of
> > the instructions preceding that position is an assignment to x
(which,
> > thanks to the Attachment Preservation rule, gives it an attached
value
> > if T is an attached type) or a creation instruction of target x (of
the
> > form create x ...)."
> > I learned long ago not to suspect that the compiler has made an
error,
> > but in this case, I think it's wrong.
>
> I can't answer this. I have been annoyed by similar things. It may be
as simple that the implementation lags the thinking - the paper is dated
2009. The void-safe compiler is a "work in progress".
>
> Peter Horan
>

[Emmanuel Stapf]

> I should have given you more information about 'make_and_launch'.
> EiffelBuild generated a root class, VISION2_APPLICATION, for me.
> 'make_and_launch' is its sole creation procedure:
>
> class
>      VISION2_APPLICATION
>
> inherit
>      EV_APPLICATION
>
> create
>      make_and_launch
> feature {NONE} -- Initialization
>      make_and_launch
>              -- Create `Current', build and display `main_window',
>              -- then launch the application.
>          do
>              default_create
>              create main_window
>              main_window.show
>              launch
>          end
>
> 'main_window' is an attribute of VISION2_APPLICATION:
>
> feature {NONE} -- Implementation
>
>      main_window: MAIN_WINDOW

As pointed out a few month ago in the mailing list the version of EiffelBuild
included in EiffelStudio 6.4 does not generate void-safe code. The 6.5 version
will.

The reason why we flag the above code as an error is that at the end of
`default_create' (defined in the parent classe), we use `Current' as a consequence
this is an error to use Current if not all attached attributes are not yet set. In
the void-safe version of EiffelVision2, we provide a new routine
`create_interface_objects' that you have to redefine if inheriting from an
EiffelVision class to create your attached attributes before `Current' is being
used.

A possible alternative is to mark `main_window' detachable but stable. The stable
notion not yet standardized by ECMA but you can use it in a non-breaking syntax
manner via the `note' clause:

        main_window: detachable MAIN_WINDOW note option: stable attribute end

Now the code above will compile just fine. The stable qualifier basically says
that even though it is a detachable attribute, once set it cannot be unset.

Hope this helps,
Manu

[the blind squirrel]

Manu,

Thank you very much for replying. Of course, I have some additional
questions.

> > feature {NONE} -- Initialization
> >      make_and_launch
> >              -- Create `Current', build and display `main_window',
> >              -- then launch the application.
> >          do
> >              default_create
> >              create main_window
> >              main_window.show
> >              launch
> >          end
> >
> > 'main_window' is an attribute of VISION2_APPLICATION:
> >
> > feature {NONE} -- Implementation
> >
> >      main_window: MAIN_WINDOW
>
> As pointed out a few month ago in the mailing list the version of

EiffelBuild
> included in EiffelStudio 6.4 does not generate void-safe code. The 6.5
version
> will.

OK, thank you. Sorry I missed this notice. I'll try to pay better
attention!

>
> The reason why we flag the above code as an error is that at the end
of
> `default_create' (defined in the parent classe), we use `Current'

Since I've obviously missed one announcement, can you clear up for me
what the current status of default_create for attached-type entities is?
The ECMA document (section 7.13, fourth bullet point) indicates that
attached type entities can be attached by default, via default_create.
But 'void-safe-eiffel' doesn't mention 'default_create'. Is the 'create'
directive now required for instantiating attached-type entities (IOW,
there is no default creation for attached-type entities)?

> as a consequence
> this is an error to use Current if not all attached attributes are not
yet set. In
> the void-safe version of EiffelVision2, we provide a new routine
> `create_interface_objects' that you have to redefine if inheriting
from an
> EiffelVision class to create your attached attributes before `Current'
is being
> used.

I don't understand why the use of Current in the default_create of
MAIN_WINDOW, inherited from EV_ANY, matters at the line the compiler
flags: 'main_window.show'. All creation procedure instructions are
complete at that point, so 'main_window' should be fully instantiated.
It's an even simpler case than the first example on page 7 of
'void-safe-eiffel' (labeled 'r'), because there are no intervening
instructions. How could 'main_window.show' not be a void safe call at
this point? Or is the compiler really trying to alert me to the previous
line, 'create main_window', which shouldn't be performed in
'make_and_launch', but instead in 'create_interface_objects'? That would
also be surprising, because 'make_and_launch' is just doing what all
creation procedures should do, instantiate  attached attributes.
>
> A possible alternative is to mark `main_window' detachable but stable.
The stable
> notion not yet standardized by ECMA but you can use it in a
non-breaking syntax
> manner via the `note' clause:
>
>  main_window: detachable MAIN_WINDOW note option: stable attribute end

Peter Horan also suggested making 'main_window' detachable. I appreciate
the suggestion, and I'm certain it would work, but to me it comes across
as a work-around. 'main_window' has to be attached--it wouldn't be much
of a GUI application if the 'main_window' were Void!

So as not to be completely pig-headed, I commented out 'main_window' as
a class attribute, and made it a local entity of 'make_and_launch',
still attached. This time the compiler was happy, no error. But I'd
really appreciate knowing why it's ever an error to instantiate an
attribute, like 'main_window', in a creation procedure.

>
> Now the code above will compile just fine. The stable qualifier
basically says
> that even though it is a detachable attribute, once set it cannot be
unset.
>
> Hope this helps,
> Manu
>

[Emmanuel Stapf]

> Since I've obviously missed one announcement, can you clear up for me
> what the current status of default_create for attached-type entities is?

There is nothing special about `default_create' compared to other creation
procedures. The rule is that at the end of each creation procedures of a class,
all attributes which are declared attached should be set. In addition to that
rule, it is also said that `Current' cannot be used in a creation procedure if not
all attributes which are declared attached are set.

> The ECMA document (section 7.13, fourth bullet point) indicates that
> attached type entities can be attached by default, via default_create.

A new revision of ECMA is in progress and in this revision we have dropped that
requirement where if an entity provides `default_create' then you do not need to
create it immediately. The rationale was discussed on this mailing list a few
months ago and was implemented first in 6.4.

> I don't understand why the use of Current in the default_create of
> MAIN_WINDOW, inherited from EV_ANY, matters at the line the compiler
> flags: 'main_window.show'. All creation procedure instructions are

See the content of `default_create' which is using `Current' before `main_window'
is created.

> So as not to be completely pig-headed, I commented out 'main_window' as
> a class attribute, and made it a local entity of 'make_and_launch',
> still attached. This time the compiler was happy, no error. But I'd
> really appreciate knowing why it's ever an error to instantiate an
> attribute, like 'main_window', in a creation procedure.

Hopefully the above will give you enough information to understand.
Regards,
Manu