Help with library update

[David Jenkins]

I'm going to start upgrading the "editor" library to complete void safety. It will be fun, and I'll learn something.

I'd like to ask first about a point Thomas Beale made. He said one improvement he was making to the "docking" library was to remove irrelevant pre- and postconditions. I take that to mean statements like "arg /= Void" in a precondition, where "'arg" is a routine argument that's attached by default (IOW, not marked "detachable"). Am I right about that? If I am, is removing such statements what we should be doing? Void checks in pre- and postconditions are extraneous in a completely void safe environment, but they're desirable for non-void safe code. Up through release 7.3 of EiffelStudio there has been two sets of project configuration (.ecf) files, one non-void safe, the other void safe (to varying degrees), but only one set of source files. If the "arg /= Void" statements are removed from preconditions (and similarly with "Result /= Void" for postconditions, where the return type of a feature is attached by default), then the source code will really only be useful for completely void-safe systems, and there will necessarily be two sets of source code, one each for void safe and non-void safe libraries. I'm not advocating an approach, I just want to know what the direction is.

Also, what release of EiffelStudio should I be using?

[Emmanuel Stapf]

Hi David,

> I'm going to start upgrading the "editor" library to complete void
> safety. It will be fun, and I'll learn something.

Great.

> I'd like to ask first about a point Thomas Beale made. He said one
> improvement he was making to the "docking" library was to remove
> irrelevant pre- and postconditions. I take that to mean statements like
> "arg /= Void" in a precondition, where "'arg" is a routine argument
> that's attached by default (IOW, not marked "detachable"). Am I right
> about that? If I am, is removing such statements what we should be doing?

I should have answer Thomas on that yesterday, so I'll use your email for the answer. To make it easier on reviewer, we should just do one change at a time. So we should just stick to make it compile in complete void-safe mode with as little as possible changes anywhere else.

Regardless of that, we do not want to remove such contracts yet because there are still a lot of code which is not void-safe (including and unfortunately the Eiffel compiler itself).

> Also, what release of EiffelStudio should I be using?

You should use the latest development release. They are at ftp://beta:bet...@ftp.eiffel.com/14.05/

Manu

[David Jenkins]

Manu, Thanks for the reply. I'll follow your instructions & probably get started this afternoon.

[David Jenkins]

Hi Manu,

I'm down to about 80 compile errors from over 300. I should finish upgrading so there are no compile errors in the next few days. Then I'll do a "diff" of the new library and the original as a review and correct any mistakes. I should have something to send you by the end of the week.

--
For more messaging options, visit this group at http://forum.eiffel.com.
Information on the Eiffelstudio project: http://dev.eiffel.com.

[Emmanuel Stapf]

Great. Let us know when this will be available.

 

Manu

[David Jenkins]

Hi Manu,

I'm down to 1 compile-time error to fix, but it seems the compiler has saved the best (or worst) for last. The error is a VEVI, raised in class TEXT_PANEL. Here's what the compiler says:

VEVI: Variable is not properly set. Attribute(s): refresh_line_number_agent, update_scroll_agent

Error code: VEVI

Error: variable is not properly set.

What to do: ensure the variable is properly set by the corresponding

  setter instruction.

Class: TEXT_PANEL

Feature: register_observers

Creation procedure: default_create declared in TEXT_PANEL

Attribute(s): refresh_line_number_agent, update_scroll_agent

Line: 185

      do

->      text_displayed.add_lines_observer (Current)

        text_displayed.add_edition_observer (Current)

The attributes in question are defined in TEXT_PANEL this way:

refresh_line_number_agent: PROCEDURE [ANY, TUPLE]

update_scroll_agent: PROCEDURE [like Current, TUPLE]

They're initialized to temporary values in "default_create"

 default_create -- Default creation do create widget -- Initialize with unexecutable agent. initialize is_initialized := True update_scroll_agent := agent do check False end end refresh_line_number_agent := agent do check False end end end

and set to useful values in "user_initialization", which is called by "initialize", in turn called in "default_create":

                        update_scroll_agent := agent update_scrollbars_display 

refresh_line_number_agent := agent refresh_line_number_display

IOW, it appears to me that "update_scroll_agent" and "refresh_line_number_agent" are actually properly set twice during object creation: once in "default_create", and again for good measure and correctly in "user_initialization". Apparently the compiler however thinks otherwise.

(I should point out that I moved the call to "initialize" in "default_create" up from where it was originally, to correct a larger number of VEVI errors for other attributes that are also set in "user_initialization".)

I can fix this by making the attributes self-initializing

update_scroll_agent: PROCEDURE [like Current, TUPLE]

attribute

Result := agent do check False end end

end

but once I do, other attributes start appearing as VEVI errors, not properly set. I can fix all of them by making them self-initializing, but before I do I thought I'd ask you first. 

I must not fully understand the rules for complete void safety involving agents.

So close, and yet so far ...

[Emmanuel Stapf]

This is a general issue with agent initialization because they involve an implicit reference to the current object and thus if not all attributes are set you are not supposed to be able to use Current.

 

So far we have been lucky that there was only one agent to initialize this way and putting its initialization as the last entry in the creation procedure was enough to get rid of the VEVI error.

 

The above was to provide some background.

 

In this particular case, we have decided to never use self-initialization attributes to work around this kind of errors. We either make it detachable or find a solution.

 

It is hard to provide an answer to your problem, but you can send me the diff of what you have and can provide you with hopefully a solution to this problem.

[David Jenkins]

Thanks for the reply, your advice helped. I moved around some of the attribute initializations, and now everything compiles. I'd like to review my changes once at least before sending it to you. I'll try to finish by Friday afternoon, if that's ok.

[David Jenkins]

Hello Manu,

I've attached the editor library upgraded to complete void safety. All files are included, both those that have changed and those that have not. I've reviewed all changes but haven't yet tested it. I'll try to get to that this weekend. I'm confident it will work correctly, but it should be tested of course.

On Tue, Mar 11, 2014 at 3:10 PM, Emmanuel Stapf <ma...@eiffel.com> wrote:

[David Jenkins]

I made a few changes to the "test" system that's included with the "editor" library, so it would compile with complete void safety, and then ran AutoTest. The changes I made passed the test.

Let me know if there are other tests you think I should run.

I can upgrade another library, if you need the help.

On Tue, Mar 11, 2014 at 3:10 PM, Emmanuel Stapf <ma...@eiffel.com> wrote: