[eiffel-users] EiffelStudio 17.05 is now available!

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[eiffel-users] EiffelStudio 17.05 is now available!

'Alexander Kogtenkov' via 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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] EiffelStudio 17.05 is now available!

Berend de Boer
>>>>> "Eiffel" == Eiffel Users <[hidden email]> 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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] EiffelStudio 17.05 is now available!

Berend de Boer
>>>>> "Berend" == Berend de Boer <[hidden email]> writes:

    Berend> [1 <text/plain; UTF-8 (7bit)>]
>>>>> "Eiffel" == Eiffel Users <[hidden email]> 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.

--
All the best,

Berend de Boer

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] EiffelStudio 17.05 is now available!

ctillman
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 ...

On Sat, Jun 24, 2017 at 4:49 PM, Berend de Boer <[hidden email]> wrote:
"Berend" == Berend de Boer <[hidden email]> writes:

   Berend> [1 <text/plain; UTF-8 (7bit)>]
"Eiffel" == Eiffel Users <[hidden email]> 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.


--
All the best,

Berend de Boer

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.



--
Chris Tillman
Developer

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[eiffel-users] Re: EiffelStudio 17.05 is now available!

Thomas Beale-4
In reply to this post by 'Alexander Kogtenkov' via Eiffel Users

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

On Wednesday, May 31, 2017 at 9:55:56 AM UTC+1, Eiffel Users wrote:
We are pleased to announce the availability of EiffelStudio 17.05.

<a href="https://www.eiffel.org/downloads" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdownloads\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFGMYZ91geWgeKx-WtXq2tIuZZS9w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdownloads\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFGMYZ91geWgeKx-WtXq2tIuZZS9w&#39;;return true;">Download it now and see the <a href="https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.05" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FRelease%2520notes%2520for%2520EiffelStudio%252017.05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEV3wNPL2J2bksecogytRtJEXSDPQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FRelease%2520notes%2520for%2520EiffelStudio%252017.05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEV3wNPL2J2bksecogytRtJEXSDPQ&#39;;return true;">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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[eiffel-users] Re: EiffelStudio 17.05 is now available!

Thomas Beale-4
In reply to this post by 'Alexander Kogtenkov' via Eiffel Users
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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] Re: EiffelStudio 17.05 is now available!

Peter Gummer-6
In reply to this post by Thomas Beale-4
Hi Thomas,

According to the release notes at <a href="https://www.eiffel.org/doc/eiffelstudio/Release notes for EiffelStudio 17.05" class="">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 <[hidden email]> 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:

...

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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] Re: EiffelStudio 17.05 is now available!

'Alexander Kogtenkov' via Eiffel Users
In reply to this post by Thomas Beale-4
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 <[hidden email]>:

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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] Re: EiffelStudio 17.05 is now available!

Thomas Beale-4
In reply to this post by Peter Gummer-6
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

On Wednesday, June 28, 2017 at 10:36:07 AM UTC+1, Peter Gummer wrote:
Hi Thomas,

According to the release notes at <a href="https://www.eiffel.org/doc/eiffelstudio/Release+notes+for+EiffelStudio+17.05" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FRelease%2Bnotes%2Bfor%2BEiffelStudio%2B17.05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFMjd_RP13HjSfB2xcn5P5Ts6iATQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FRelease%2Bnotes%2Bfor%2BEiffelStudio%2B17.05\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFMjd_RP13HjSfB2xcn5P5Ts6iATQ&#39;;return true;">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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="oLveFo-YDwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">wolan...@...> 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:

...

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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] Re: EiffelStudio 17.05 is now available!

Thomas Beale-4
In reply to this post by 'Alexander Kogtenkov' via Eiffel Users
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

On Wednesday, June 28, 2017 at 10:51:41 AM UTC+1, Alexander Kogtenkov wrote:
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1I_jwGiZDwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">wolan...@...>:

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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[2]: [eiffel-users] Re: EiffelStudio 17.05 is now available!

'Alexander Kogtenkov' via Eiffel Users
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.

Alexander Kogtenkov


Thomas Beale <[hidden email]>:

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

On Wednesday, June 28, 2017 at 10:51:41 AM UTC+1, Alexander Kogtenkov wrote:
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 <[hidden email]>:

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

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Loading...