EiffelStudio 17.05 is now available!

[Eiffel Users]

We are pleased to announce the availability of EiffelStudio 17.05.

Download it now and see the release notes.

The major highlights are:

• The EiffelStudio Inspector checks obsolete features and obsolete calls, then make the users aware of coming removal based on the date associated with obsolete message.
• It is now possible to restore recently closed tabs (using shortcut: Ctrl+Shift+T or contextual menu: Right clicking on tab).
• Using Pick&Drop functionality, users can now pick token for local variables and arguments from the EiffelStudio editor and formatters; then drop it into editor to get the cursor moved to related declaration.
• Added Visual Studio 2017 support for C compilation on Windows.
• Updated libraries and examples included with EiffelStudio installation to avoid obsolete feature calls.

Happy Eiffeling,

-- The Eiffel Software Team

[Berend de Boer]

>>>>> "Eiffel" == Eiffel Users <eiffel...@googlegroups.com> writes:

Eiffel> Download it now and see the release notes.

Execution parameters are not saved for me (Ubuntu 17.04). Is this a bug?

I.e. after restarting studio, execution parameters are always empty.


--
All the best,

Berend de Boer

[Berend de Boer]

>>>>> "Berend" == Berend de Boer <ber...@pobox.com> writes:

Berend> [1 <text/plain; UTF-8 (7bit)>]

>>>>> "Eiffel" == Eiffel Users <eiffel...@googlegroups.com> writes:

Berend> Execution parameters are not saved for me (Ubuntu
Berend> 17.04). Is this a bug?

Berend> I.e. after restarting studio, execution parameters are
Berend> always empty.

Same thing happens to me with 17.01.

Both also have the very annoying feature that if you change a file
outside the IDE, this is no longer picked up.

[Chris Tillman]

In 17.01 (17.01.9.9700 GPL Edition - linux-x86-64) my execution parameters stay put between invocations, and external file changes are immediately picked up when I switch back to EiffelStudio.

I haven't got 17.05 yet ...

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--

Chris Tillman
Developer

[Thomas Beale]

I just installed 17.05. My archetype workbench application now fails to compile with ... well quite a lot of obsolete call warnings, but also various errors of the following kind from the Docking library calls:

~~~~~~~~~~~~~~~~~~~~~~~~

Error code: VUAR(1)

Error: wrong number of actual arguments in feature call. 

What to do: make sure that number of actuals matches number of formals.

Class: GUI_DOCKING_EDITOR_CONTROLLER

Feature: add_new_tool

Called feature: make_with_widget_title_pixmap (a_widget: EV_WIDGET; a_pixmap: EV_PIXMAP; a_unique_title: READABLE_STRING_32; a_docking_manager: SD_DOCKING_MANAGER) from SD_CONTENT

Number of formals: 4

Number of actuals: 3

Line: 195

        active_tool_id := docking_tools.count + 1

->      create docking_pane.make_with_widget_title_pixmap (a_gui_tool.ev_root_container, Editor_pixmap, Editor_group_name + " #" + active_tool_id.out)

        docking_pane.close_request_actions.extend (agent remove_tool (active_tool_id))

~~~~~~~~~~~~~~~~~~~~~~

the change appears to be that now a docking_manager 4th parameter has been added. I can see how to potentially fix this, since in my MAIN_WINDOW I create an internal_docking_manager instance, so I suppose I need to do this in an inherited SHARED object, but I'd prefer to see a) some documentation on what the intended changed usage of the library now is and b) some justification for this change (maybe it makes sense, but it seems strangely inconvenient when everything was working nicely before).

thanks

- thomas

[Thomas Beale]

Another strange error report I am getting with 17.05:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Warning code: Obsolete Call

Warning: call uses obsolete feature.

What to do: update to new feature at your earliest convenience. The

  feature is still available but may be removed in the future.

Class: DT_OBJECT_CONVERTER

Feature: populate_dt_attr_from_eif_sequence

Obsolete feature: to_string_32: STRING_32 (class TYPE)

Obsolete message: Use 'name_32' instead. [2017-05-31]

Line: 1229

    io.put_string (indent_str + "DT_OBJECT_CONVERTER.populate_dt_attr_from_eif_sequence (SEQUENCE of DT primitive): from_obj_proc.call ([DT_ATTRIBUTE_NODE ('" +

->    a_dt_attr.im_attr_name + "'), '" + an_eif_seq.item.generating_type + "', " + an_eif_seq.index.out + ")%N")

  end

~~~~~~~~~~~~~~~~~~~~~~~~~

There is no direct call to to_string_32 in this class, so I suppose the error refers to a call buried in one of the calls that are made. This seems a strange way to report an error. Do I need to manually look for where the call really is?

Secondly, there are errors saying to convert both to_string_32 and to_string_8 calls to name_32. Is this correct?

- thomas

[Peter Gummer]

Hi Thomas,

According to the release notes at https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.05 …

Breaking changes

• To have a fully void-safe docking library, some creation procedures were updated and now require a docking manager object as argument.

Peter

On 28 Jun 2017, at 18:28, Thomas Beale <wolan...@gmail.com> wrote:

I just installed 17.05. My archetype workbench application now fails to compile with ... well quite a lot of obsolete call warnings, but also various errors of the following kind from the Docking library calls:

...

[Alexander Kogtenkov]

The issue is with the feature `generating_type`. It returns TYPE, but is used in the context where STRING is required. The conversion features to STRING_nn in the class TYPE were marked as obsolete long time ago. Unfortunately, the compiler did not report obsolete calls involved in conversion. This was finally fixed in EiffelStudio 17.05. As a result you get a lot "new" warning messages. In order to fix them, `name_32` that returns a string should be called directly. The idea of using `name_32` instead of `name_8` is that in long term STRING_8 should become a legacy class and user interaction should be done with STRING_32 instead. So, calling `name_32` instead  of `name_8` is a preferred way to fix the issue.

Hope this helps,
Alexander Kogtenkov

Thomas Beale <wolan...@gmail.com>:

[Thomas Beale]

Ah - sorry for the noise. I did actually make a point of reading some release notes but I see now that it must have been an earlier draft that was incomplete (or maybe it was complete and I just read it too fast ;). Ideally I still think the docking lib should have better documentation, but I don't personally need it right now, as I more or less know what I'm doing with it.

- thomas

[Thomas Beale]

Alex, 

thanks for this. I made one such change, and now I have a problem:

the fixed call is:

    errors.add_error (ec_dt_container_gen_param_type_mismatch, <<(1).out, a_hash_table.generating_type.name_32, type_name_of_type (att_static_cont_item_tid), val.generating_type.name_32>>, "populate_eif_container_from_dt")

and the signature of add_error() is:

    add_error (a_code: STRING; args: detachable ARRAY[STRING]; a_loc: detachable STRING)

Now I get the error that the <<>> string array is an ARRAY [ANY] rather than the required ARRAY [STRING_8]. The 'ANY' is being inferred because there is a mixture of STRING_8 and STRING_32; the latter 'STRING_8' is being silently assumed by the compiler when it sees the 'STRING' in the above signature. I don't remember the rule for how this happens, and I also don't understand why we can't any STRING_32, except for talking to Windows UI libs (apparently it's needed there). (Our app is all Unicode UTF-8, and ideally I don't want any STRING_32 anywhere...)

In any case, to at least get things compiling, I need to have a way of including a obj.generating_type call that generates a normal STRING_8. But there is no 'name_8'...

I can do an explicit conversion via STRING_32.to_string_8; this works, but it means that every place I had x.generating_type (reasonably common in this application), now I have to put x.generating_type.name_32.as_string_8.

That seems pretty awful. Wouldn't it be better to have a 'name' feature that is statically defined as STRING (or IMMUTABLE_STRING), and converted silently as needed to the 8 or 32 form?

Or better, just get rid of the static type declarations with _32 and _8 altogether!

- thomas

[Alexander Kogtenkov]

I must have misspelled the 8-bit version of the feature, it is `name`, not `name_8`. So, you can use it instead of `name_32.as_string_8`, if your code is stick to STRING_8.

In the long term the idea is to use only Unicode strings. Currently they are STRING_32. After the migration, STRING_32 should become STRING without any suffix, so no `name_32` and `name_8` would be required. Unfortunately, at the moment there is no obvious path to make this migration smooth, and, of course, we have to find a solution to avoid issues on user's side before starting it. Anyway, introduction of PATH was a huge step in this direction. With strings the things are more complicated though.