[eiffel-users] OpenSSL ssleay32.lib

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

[eiffel-users] OpenSSL ssleay32.lib

Larry Rix
Hi All,

So—I have 17.05 installed. I installing VS 17 CE. Interestingly enough, when ES 17.05 compiles it shows that it is using VC 14 (i.e. Preparing C compilation using Microsoft Visual Studio 2015 VC++ (14.0)... )

Ought I be expecting to see a different message when compiling (i.e. Preparing C compilation using Microsoft Visual Studio 2017 VC++ (16.0)... or something like that)?


Beyond that—I installed the 64 bit version of ES 17.05 GPL, which is fantastic. Love it. However, my use of SSL (for cUrl I think) is not working. I recall going through this before, where Javier provided me with appropriate ssleay32.lib and libeay32.lib files. I then had to create the appropriate subdirectory under $ES\unstable\library\network\socket\netssl\spec --> windows\lib\msc_vc140 and then copy in the two lib files.

In this case, I did a repeat of that action except using win64 instead of windows in the path creation. The compiler is then happy, but I think the system won't run because the lib files are 32 bit and ES is compiling in 64, so the resulting EXE fails to execute.

This makes me wonder about the solution:

1. Are there 64 bit lib files to use instead of the 32?
2. Are there switches for the compiler to make some sort of translation from 64-to-32-to-64 when it is compiling those lib file calls into the EXE?
3. Something else?


BTW: Manu had mentioned that the 17.05 version might handle the compiler error I was getting previously. It appears that this is in fact what has happened--the error has been handled. The only remaining matter is this ssleay/libeay.lib issue.


Thank you all for your assist!

--
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: OpenSSL ssleay32.lib

Larry Rix
Well, well, well ... 3rd time is a charm perhaps?

I deleted the EIFGENs to force a clean compile.

I copied in files from http://www.indyproject.org/Sockets/fpc/OpenSSLforWin64.en.aspx --> FAIL! It would not link.

I deleted the files above, found the original *.lib files that Javier sent me and tried them again.

SUCCESS!! All's well that ends well, but I don't know what I did to make it work.

I do still have the question about the VC14 even after installing VS17CE. Makes me wonder if the VC14 has anything to do with the success and if I am really making 64-bit EXEs?

--
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: OpenSSL ssleay32.lib

javier hector
Hi Larry,

1) You can get the list of C/C++ compilers, running  from the command line espawn -l 

On my side the output is

>Eiffel Environment Command Spawn Utility - Version: 17.05
>Copyright Eiffel Software 1985-2017. All Rights Reserved.

>Available C/C++ compilers:

  > VC140:  Microsoft Visual Studio 2015 VC++ (14.0)

2) You can check the Visual Studio C++ compiler version using the following command `cl' as follow

>cl
>Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
>Copyright (C) Microsoft Corporation.  All rights reserved.

>usage: cl [ option... ] filename... [ /link linkoption... ]

if you get a 32 version, go to the VisualStudio directory (%PATH_TO_VS%) and execute ``vcvarsall.bat x64`
you will find it under %PATH_TO_VS%\VC 


By the way, now there is a new tool provided by VC ++ Team to build C++ Open source libraries in a simple way.

So to generate the OpenSSL static library for x64 you just need to run the following command (after you have installed vckpg tool).

vcpkg install openssl:x64-windows-static

Hope this helps
/Javier



On Saturday, June 3, 2017 at 10:34:45 AM UTC-3, Larry Rix wrote:
Well, well, well ... 3rd time is a charm perhaps?

I deleted the EIFGENs to force a clean compile.

I copied in files from <a href="http://www.indyproject.org/Sockets/fpc/OpenSSLforWin64.en.aspx" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.indyproject.org%2FSockets%2Ffpc%2FOpenSSLforWin64.en.aspx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG8oe-nZKbH8mJ08xqGPnQ802aecA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.indyproject.org%2FSockets%2Ffpc%2FOpenSSLforWin64.en.aspx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG8oe-nZKbH8mJ08xqGPnQ802aecA&#39;;return true;">http://www.indyproject.org/Sockets/fpc/OpenSSLforWin64.en.aspx --> FAIL! It would not link.

I deleted the files above, found the original *.lib files that Javier sent me and tried them again.

SUCCESS!! All's well that ends well, but I don't know what I did to make it work.

I do still have the question about the VC14 even after installing VS17CE. Makes me wonder if the VC14 has anything to do with the success and if I am really making 64-bit EXEs?

--
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: OpenSSL ssleay32.lib

Larry Rix
Looks like this for me, which I think is like yours:

EiffelStudio is ready to be used for the win64 platform and msc_vc140 C compiler.

C:\Program Files\Eiffel Software\EiffelStudio 17.05 GPL>espawn -l
Eiffel Environment Command Spawn Utility - Version: 17.05
Copyright Eiffel Software 1985-2017. All Rights Reserved.

Available C/C++ compilers:

   VC140:  Microsoft Visual Studio 2015 VC++ (14.0)
   VC120:  Microsoft Visual Studio 2013 VC++ (12.0)
   VC110:  Microsoft Visual Studio 2012 VC++ (11.0)

C:\Program Files\Eiffel Software\EiffelStudio 17.05 GPL>


Larry Rix
Moonshot Software
Rocket science for everyone!
Savannah, GA
770-295-9729



On Sun, Jun 4, 2017 at 11:49 AM, javier hector <[hidden email]> wrote:
Hi Larry,

1) You can get the list of C/C++ compilers, running  from the command line espawn -l 

On my side the output is

>Eiffel Environment Command Spawn Utility - Version: 17.05
>Copyright Eiffel Software 1985-2017. All Rights Reserved.

>Available C/C++ compilers:

  > VC140:  Microsoft Visual Studio 2015 VC++ (14.0)

2) You can check the Visual Studio C++ compiler version using the following command `cl' as follow

>cl
>Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
>Copyright (C) Microsoft Corporation.  All rights reserved.

>usage: cl [ option... ] filename... [ /link linkoption... ]

if you get a 32 version, go to the VisualStudio directory (%PATH_TO_VS%) and execute ``vcvarsall.bat x64`
you will find it under %PATH_TO_VS%\VC 


By the way, now there is a new tool provided by VC ++ Team to build C++ Open source libraries in a simple way.

So to generate the OpenSSL static library for x64 you just need to run the following command (after you have installed vckpg tool).

vcpkg install openssl:x64-windows-static

Hope this helps
/Javier



On Saturday, June 3, 2017 at 10:34:45 AM UTC-3, Larry Rix wrote:
Well, well, well ... 3rd time is a charm perhaps?

I deleted the EIFGENs to force a clean compile.

I copied in files from http://www.indyproject.org/Sockets/fpc/OpenSSLforWin64.en.aspx --> FAIL! It would not link.

I deleted the files above, found the original *.lib files that Javier sent me and tried them again.

SUCCESS!! All's well that ends well, but I don't know what I did to make it work.

I do still have the question about the VC14 even after installing VS17CE. Makes me wonder if the VC14 has anything to do with the success and if I am really making 64-bit EXEs?

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

--
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: OpenSSL ssleay32.lib

Larry Rix
In reply to this post by javier hector
And the cl returns:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>

So--looks like I have VS17CE installed okay for 32-bit and ES 64-bit is okay with that. I presume the 32-bit compiler and compile 64 bit EXEs based on switches or no?

--
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: OpenSSL ssleay32.lib

Larry Rix
In reply to this post by javier hector
https://developers.slashdot.org/story/16/06/04/1429248/microsoft-declines-to-make-a-64-bit-visual-studio

Looks like MS won't make a 64 bit VS, so the C compiler must be capable of making 64 bit EXEs based on switches, yes?

--
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] ES17.05 Capability Complete Void Safety?

Jonathan Ostroff
I have a question about ECF files in 17.05 for complete Void safety. The ECF file below seems to work ok, i.e. all the libraries and clusters appear to satisfy complete Void safety, attached by default, full class checking etc. 

But I am not sure why that is. Previously there would be a Void safe settings. What we now have, it appears, is a capability declaration

<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>

1. What is the effect of the above capability declaration on clusters such as cluster “root", etc.? Is it the above declaration that ensures that all the clusters and libraries are Void safe?

2. The project below imports the library “espec” (this is a testing library developed by us at York University) in the contributed folder. The ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in a Void safe manner for the project defined below. So it would seem that library ECF files need not state anything about their Void safety? [Presumably because of the capability declaration in #1]

3. It also seems that the above Void safety automatically results in the effect that all types as attached by default?

Just checking to ensure that our tools generate the correct ECF files for what was previously explicitly declared in ECF files to achieve attached by default, complete Void safety and standard syntax. Also Full Class Checking. 

Thanks for any help,

Jonathan

P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu & the Eiffel team, and the ECMA members for moving forward on this. It’s been a demanding but productive journey. 

=====
<?xml version="1.0" encoding="ISO-8859-1"?>
<target name="messenger">
<root class="ROOT" feature="make"/>
<file_rule>
<exclude>/CVS$</exclude>
<exclude>/EIFGENs$</exclude>
<exclude>/\.git$</exclude>
<exclude>/\.svn$</exclude>
</file_rule>
<option warning="true" is_obsolete_routine_type="true">
<assertions precondition="true" postcondition="true" check="true" invariant="true" loop="true" supplier_precondition="true"/>
</option>
<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>
<precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
<library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
<renaming old_name="SET" new_name="EIFFEL_SET"/>
<renaming old_name="BAG" new_name="EIFFEL_BAG"/>
</library>
<library name="espec" location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
<library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
<library name="encoding" location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
<library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
<library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
<library name="gobo_parse" location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
<library name="gobo_structure" location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
<library name="gobo_utility" location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
<library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
<library name="vision2" location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
  <cluster name="messenger" location=".\messenger\" recursive="true"/>
<cluster name="generated_code" location=".\generated_code\" recursive="true"/>
<cluster name="root" location=".\root\" recursive="true"/>
</target>
</system>

--
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] ES17.05 Capability Complete Void Safety?

'Alexander Kogtenkov' via Eiffel Users
Dear Jonathan,

Capabilities were introduced in EiffelStudio 17.01 as mentioned in the release notes

   https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01 

Some lower-level details could also be found at the developers site:

   https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features 

Answering your specific questions:

1. Capabilities are specified at the level of a target, not a cluster or a class, and are applied to all classes from the clusters belonging to the target. This is the part "support", i.e. what the classes are capable of. E.g., <void_safety support="all"/> means all classes of the associated target are completely void-safe.

As to libraries or an inherited target, their capabilities should be sufficient for the current target, i.e. they should provide the same or better guarantees. If the current target has complete void safety, all used libraries should be completely void-safe as well.

So, yes, with <void_safety support="all"/>, all used libraries are also completely void-safe.

As to the part "use", this is the current setting used to compile the target, not to check the rules. E.g., one can build a single-threaded application even if it supports SCOOP capability - this depends on the application requirements.

2. According to compatibility table at

   https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options 

if no specific setting is given, starting from EiffelStudio 14.05 the default void safety is complete. This applies to "espec" library ECF as well, i.e. it is completely void safe according to the default void safety settings. These defaults are tightly coupled with ECF schema version, so old projects can be compiled even with a newer compiler using default settings of the earlier ECF version.

3. Attached-by-default is another compatibility setting that is True by default starting from EiffelStudio 7.0. This option is going to disappear altogether soon.

You can consult default values of other compatibility options in the table mentioned above.

Best regards,
Alexander Kogtenkov


Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff <[hidden email]>:

I have a question about ECF files in 17.05 for complete Void safety. The ECF file below seems to work ok, i.e. all the libraries and clusters appear to satisfy complete Void safety, attached by default, full class checking etc. 

But I am not sure why that is. Previously there would be a Void safe settings. What we now have, it appears, is a capability declaration

<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>

1. What is the effect of the above capability declaration on clusters such as cluster “root", etc.? Is it the above declaration that ensures that all the clusters and libraries are Void safe?

2. The project below imports the library “espec” (this is a testing library developed by us at York University) in the contributed folder. The ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in a Void safe manner for the project defined below. So it would seem that library ECF files need not state anything about their Void safety? [Presumably because of the capability declaration in #1]

3. It also seems that the above Void safety automatically results in the effect that all types as attached by default?

Just checking to ensure that our tools generate the correct ECF files for what was previously explicitly declared in ECF files to achieve attached by default, complete Void safety and standard syntax. Also Full Class Checking. 

Thanks for any help,

Jonathan

P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu & the Eiffel team, and the ECMA members for moving forward on this. It’s been a demanding but productive journey. 

=====
<?xml version="1.0" encoding="ISO-8859-1"?>
<target name="messenger">
<root class="ROOT" feature="make"/>
<file_rule>
<exclude>/CVS$</exclude>
<exclude>/EIFGENs$</exclude>
<exclude>/\.git$</exclude>
<exclude>/\.svn$</exclude>
</file_rule>
<option warning="true" is_obsolete_routine_type="true">
<assertions precondition="true" postcondition="true" check="true" invariant="true" loop="true" supplier_precondition="true"/>
</option>
<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>
<precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
<library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
<renaming old_name="SET" new_name="EIFFEL_SET"/>
<renaming old_name="BAG" new_name="EIFFEL_BAG"/>
</library>
<library name="espec" location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
<library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
<library name="encoding" location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
<library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
<library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
<library name="gobo_parse" location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
<library name="gobo_structure" location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
<library name="gobo_utility" location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
<library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
<library name="vision2" location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
  <cluster name="messenger" location=".\messenger\" recursive="true"/>
<cluster name="generated_code" location=".\generated_code\" recursive="true"/>
<cluster name="root" location=".\root\" recursive="true"/>
</target>
</system>

--
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] ES17.05 Capability Complete Void Safety?

Jonathan Ostroff
Thanks for your replies, Alexander, which I very much appreciate. 

I assume that a library would have to specifically declare a Scoop capability for it to be used with Scoop?

Is there any documentation of when a library developed prior to Scoop would be Scoop compatible? For example, the “espec” library does not use threading etc. There are no declarations of “separate” anywhere in the code. It would seem to be Scoop compatible. Are there any precautions that need to be taken?

Thanks and regards,

Jonathan


On Jun 9, 2017, at 6:22 AM, 'Alexander Kogtenkov' via Eiffel Users <[hidden email]> wrote:

Dear Jonathan,

Capabilities were introduced in EiffelStudio 17.01 as mentioned in the release notes

   https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01 

Some lower-level details could also be found at the developers site:

   https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features 

Answering your specific questions:

1. Capabilities are specified at the level of a target, not a cluster or a class, and are applied to all classes from the clusters belonging to the target. This is the part "support", i.e. what the classes are capable of. E.g., <void_safety support="all"/> means all classes of the associated target are completely void-safe.

As to libraries or an inherited target, their capabilities should be sufficient for the current target, i.e. they should provide the same or better guarantees. If the current target has complete void safety, all used libraries should be completely void-safe as well.

So, yes, with <void_safety support="all"/>, all used libraries are also completely void-safe.

As to the part "use", this is the current setting used to compile the target, not to check the rules. E.g., one can build a single-threaded application even if it supports SCOOP capability - this depends on the application requirements.

2. According to compatibility table at

   https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options 

if no specific setting is given, starting from EiffelStudio 14.05 the default void safety is complete. This applies to "espec" library ECF as well, i.e. it is completely void safe according to the default void safety settings. These defaults are tightly coupled with ECF schema version, so old projects can be compiled even with a newer compiler using default settings of the earlier ECF version.

3. Attached-by-default is another compatibility setting that is True by default starting from EiffelStudio 7.0. This option is going to disappear altogether soon.

You can consult default values of other compatibility options in the table mentioned above.

Best regards,
Alexander Kogtenkov


Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff <[hidden email]>:

I have a question about ECF files in 17.05 for complete Void safety. The ECF file below seems to work ok, i.e. all the libraries and clusters appear to satisfy complete Void safety, attached by default, full class checking etc. 

But I am not sure why that is. Previously there would be a Void safe settings. What we now have, it appears, is a capability declaration

<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>

1. What is the effect of the above capability declaration on clusters such as cluster “root", etc.? Is it the above declaration that ensures that all the clusters and libraries are Void safe?

2. The project below imports the library “espec” (this is a testing library developed by us at York University) in the contributed folder. The ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in a Void safe manner for the project defined below. So it would seem that library ECF files need not state anything about their Void safety? [Presumably because of the capability declaration in #1]

3. It also seems that the above Void safety automatically results in the effect that all types as attached by default?

Just checking to ensure that our tools generate the correct ECF files for what was previously explicitly declared in ECF files to achieve attached by default, complete Void safety and standard syntax. Also Full Class Checking. 

Thanks for any help,

Jonathan

P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu & the Eiffel team, and the ECMA members for moving forward on this. It’s been a demanding but productive journey. 

=====
<?xml version="1.0" encoding="ISO-8859-1"?>
<target name="messenger">
<root class="ROOT" feature="make"/>
<file_rule>
<exclude>/CVS$</exclude>
<exclude>/EIFGENs$</exclude>
<exclude>/\.git$</exclude>
<exclude>/\.svn$</exclude>
</file_rule>
<option warning="true" is_obsolete_routine_type="true">
<assertions precondition="true" postcondition="true" check="true" invariant="true" loop="true" supplier_precondition="true"/>
</option>
<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>
<precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
<library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
<renaming old_name="SET" new_name="EIFFEL_SET"/>
<renaming old_name="BAG" new_name="EIFFEL_BAG"/>
</library>
<library name="espec" location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
<library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
<library name="encoding" location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
<library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
<library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
<library name="gobo_parse" location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
<library name="gobo_structure" location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
<library name="gobo_utility" location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
<library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
<library name="vision2" location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
  <cluster name="messenger" location=".\messenger\" recursive="true"/>
<cluster name="generated_code" location=".\generated_code\" recursive="true"/>
<cluster name="root" location=".\root\" recursive="true"/>
</target>
</system>


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

--
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] ES17.05 Capability Complete Void Safety?

'Alexander Kogtenkov' via Eiffel Users
By default a project is SCOOP-capable. And usually if it does not use native multithreading directly, and does not use separate types, it is SCOOP-compatible, except for generic classes with unconstrained genericity, where the default constraint is "detachable separate ANY". For most existing code this is indeed the case. The same applies to "espec".

With unconstraint genericity one would either need to take care about calls on expressions of formal generic types - they have to be wrapped. Alternatively, non-separate constraints could be added.

At the moment the following libraries are SCOOP-incompatible:
- Thread - it breaks SCOOP assumptions by using free threading model without any guarantee for transactional access to objects
- Process - it uses Thread (an alternative is to use BaseProcess (a slightly limited version of Process) that does not rely on Thread)
- Testing - it relies on Thread and there is no good replacement yet
So, if a project or a library does not rely on these SCOOP-incompatible libraries, there are good chances that it is SCOOP-compatible.

Best regards,
Alexander Kogtenkov

Jonathan Ostroff <[hidden email]>:

Thanks for your replies, Alexander, which I very much appreciate. 

I assume that a library would have to specifically declare a Scoop capability for it to be used with Scoop?

Is there any documentation of when a library developed prior to Scoop would be Scoop compatible? For example, the “espec” library does not use threading etc. There are no declarations of “separate” anywhere in the code. It would seem to be Scoop compatible. Are there any precautions that need to be taken?

Thanks and regards,

Jonathan


On Jun 9, 2017, at 6:22 AM, 'Alexander Kogtenkov' via Eiffel Users <[hidden email]> wrote:

Dear Jonathan,

Capabilities were introduced in EiffelStudio 17.01 as mentioned in the release notes

   https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01 

Some lower-level details could also be found at the developers site:

   https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features 

Answering your specific questions:

1. Capabilities are specified at the level of a target, not a cluster or a class, and are applied to all classes from the clusters belonging to the target. This is the part "support", i.e. what the classes are capable of. E.g., <void_safety support="all"/> means all classes of the associated target are completely void-safe.

As to libraries or an inherited target, their capabilities should be sufficient for the current target, i.e. they should provide the same or better guarantees. If the current target has complete void safety, all used libraries should be completely void-safe as well.

So, yes, with <void_safety support="all"/>, all used libraries are also completely void-safe.

As to the part "use", this is the current setting used to compile the target, not to check the rules. E.g., one can build a single-threaded application even if it supports SCOOP capability - this depends on the application requirements.

2. According to compatibility table at

   https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options 

if no specific setting is given, starting from EiffelStudio 14.05 the default void safety is complete. This applies to "espec" library ECF as well, i.e. it is completely void safe according to the default void safety settings. These defaults are tightly coupled with ECF schema version, so old projects can be compiled even with a newer compiler using default settings of the earlier ECF version.

3. Attached-by-default is another compatibility setting that is True by default starting from EiffelStudio 7.0. This option is going to disappear altogether soon.

You can consult default values of other compatibility options in the table mentioned above.

Best regards,
Alexander Kogtenkov


Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff <[hidden email]>:

I have a question about ECF files in 17.05 for complete Void safety. The ECF file below seems to work ok, i.e. all the libraries and clusters appear to satisfy complete Void safety, attached by default, full class checking etc. 

But I am not sure why that is. Previously there would be a Void safe settings. What we now have, it appears, is a capability declaration

<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>

1. What is the effect of the above capability declaration on clusters such as cluster “root", etc.? Is it the above declaration that ensures that all the clusters and libraries are Void safe?

2. The project below imports the library “espec” (this is a testing library developed by us at York University) in the contributed folder. The ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in a Void safe manner for the project defined below. So it would seem that library ECF files need not state anything about their Void safety? [Presumably because of the capability declaration in #1]

3. It also seems that the above Void safety automatically results in the effect that all types as attached by default?

Just checking to ensure that our tools generate the correct ECF files for what was previously explicitly declared in ECF files to achieve attached by default, complete Void safety and standard syntax. Also Full Class Checking. 

Thanks for any help,

Jonathan

P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu & the Eiffel team, and the ECMA members for moving forward on this. It’s been a demanding but productive journey. 

=====
<?xml version="1.0" encoding="ISO-8859-1"?>
<target name="messenger">
<root class="ROOT" feature="make"/>
<file_rule>
<exclude>/CVS$</exclude>
<exclude>/EIFGENs$</exclude>
<exclude>/\.git$</exclude>
<exclude>/\.svn$</exclude>
</file_rule>
<option warning="true" is_obsolete_routine_type="true">
<assertions precondition="true" postcondition="true" check="true" invariant="true" loop="true" supplier_precondition="true"/>
</option>
<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>
<precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
<library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
<renaming old_name="SET" new_name="EIFFEL_SET"/>
<renaming old_name="BAG" new_name="EIFFEL_BAG"/>
</library>
<library name="espec" location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
<library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
<library name="encoding" location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
<library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
<library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
<library name="gobo_parse" location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
<library name="gobo_structure" location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
<library name="gobo_utility" location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
<library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
<library name="vision2" location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
  <cluster name="messenger" location=".\messenger\" recursive="true"/>
<cluster name="generated_code" location=".\generated_code\" recursive="true"/>
<cluster name="root" location=".\root\" recursive="true"/>
</target>
</system>

--
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: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?

Louis M
Hi,

There is also the "once ("PROCESS")" feature that is not handled well in SCOOP. In fact, in my case, it is a very big deal since I have a lot of singletons (with shared object) in my projects.

Good day,

Louis M

Le vendredi 9 juin 2017 11:35:36 UTC-4, Alexander Kogtenkov a écrit :
By default a project is SCOOP-capable. And usually if it does not use native multithreading directly, and does not use separate types, it is SCOOP-compatible, except for generic classes with unconstrained genericity, where the default constraint is "detachable separate ANY". For most existing code this is indeed the case. The same applies to "espec".

With unconstraint genericity one would either need to take care about calls on expressions of formal generic types - they have to be wrapped. Alternatively, non-separate constraints could be added.

At the moment the following libraries are SCOOP-incompatible:
- Thread - it breaks SCOOP assumptions by using free threading model without any guarantee for transactional access to objects
- Process - it uses Thread (an alternative is to use BaseProcess (a slightly limited version of Process) that does not rely on Thread)
- Testing - it relies on Thread and there is no good replacement yet
So, if a project or a library does not rely on these SCOOP-incompatible libraries, there are good chances that it is SCOOP-compatible.

Best regards,
Alexander Kogtenkov

Jonathan Ostroff <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="qhC7eR4MBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jonathan....@...>:

Thanks for your replies, Alexander, which I very much appreciate. 

I assume that a library would have to specifically declare a Scoop capability for it to be used with Scoop?

Is there any documentation of when a library developed prior to Scoop would be Scoop compatible? For example, the “espec” library does not use threading etc. There are no declarations of “separate” anywhere in the code. It would seem to be Scoop compatible. Are there any precautions that need to be taken?

Thanks and regards,

Jonathan


On Jun 9, 2017, at 6:22 AM, 'Alexander Kogtenkov' via Eiffel Users <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="qhC7eR4MBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eiffel...@...> wrote:

Dear Jonathan,

Capabilities were introduced in EiffelStudio 17.01 as mentioned in the release notes

   <a style="font-family:Helvetica;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" href="https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01" 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.01\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoTcOwfecS0VYmBc6zihoiH9M7IA&#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.01\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoTcOwfecS0VYmBc6zihoiH9M7IA&#39;;return true;">https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01 

Some lower-level details could also be found at the developers site:

   <a style="font-family:Helvetica;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" href="https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdev.eiffel.com%2FEiffelStudio_17.01_Releases%23New_features\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmBz3N7AQjMk4xtOMqSOxBNTEVMg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdev.eiffel.com%2FEiffelStudio_17.01_Releases%23New_features\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmBz3N7AQjMk4xtOMqSOxBNTEVMg&#39;;return true;">https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features 

Answering your specific questions:

1. Capabilities are specified at the level of a target, not a cluster or a class, and are applied to all classes from the clusters belonging to the target. This is the part "support", i.e. what the classes are capable of. E.g., <void_safety support="all"/> means all classes of the associated target are completely void-safe.

As to libraries or an inherited target, their capabilities should be sufficient for the current target, i.e. they should provide the same or better guarantees. If the current target has complete void safety, all used libraries should be completely void-safe as well.

So, yes, with <void_safety support="all"/>, all used libraries are also completely void-safe.

As to the part "use", this is the current setting used to compile the target, not to check the rules. E.g., one can build a single-threaded application even if it supports SCOOP capability - this depends on the application requirements.

2. According to compatibility table at

   <a style="font-family:Helvetica;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" href="https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FEiffel%2520compatibility%2520options\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEdWUj6KkWI9MCVrCom7WEZ5FDjdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FEiffel%2520compatibility%2520options\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEdWUj6KkWI9MCVrCom7WEZ5FDjdA&#39;;return true;">https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options 

if no specific setting is given, starting from EiffelStudio 14.05 the default void safety is complete. This applies to "espec" library ECF as well, i.e. it is completely void safe according to the default void safety settings. These defaults are tightly coupled with ECF schema version, so old projects can be compiled even with a newer compiler using default settings of the earlier ECF version.

3. Attached-by-default is another compatibility setting that is True by default starting from EiffelStudio 7.0. This option is going to disappear altogether soon.

You can consult default values of other compatibility options in the table mentioned above.

Best regards,
Alexander Kogtenkov


Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="qhC7eR4MBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jonathan....@...>:

I have a question about ECF files in 17.05 for complete Void safety. The ECF file below seems to work ok, i.e. all the libraries and clusters appear to satisfy complete Void safety, attached by default, full class checking etc. 

But I am not sure why that is. Previously there would be a Void safe settings. What we now have, it appears, is a capability declaration

<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>

1. What is the effect of the above capability declaration on clusters such as cluster “root", etc.? Is it the above declaration that ensures that all the clusters and libraries are Void safe?

2. The project below imports the library “espec” (this is a testing library developed by us at York University) in the contributed folder. The ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in a Void safe manner for the project defined below. So it would seem that library ECF files need not state anything about their Void safety? [Presumably because of the capability declaration in #1]

3. It also seems that the above Void safety automatically results in the effect that all types as attached by default?

Just checking to ensure that our tools generate the correct ECF files for what was previously explicitly declared in ECF files to achieve attached by default, complete Void safety and standard syntax. Also Full Class Checking. 

Thanks for any help,

Jonathan

P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu & the Eiffel team, and the ECMA members for moving forward on this. It’s been a demanding but productive journey. 

=====
<?xml version="1.0" encoding="ISO-8859-1"?>
<system xmlns="<a href="http://www.eiffel.com/developers/xml/configuration-1-16-0" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFW97HgsQjMeOmSO38wFnYj9ma5kw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFW97HgsQjMeOmSO38wFnYj9ma5kw&#39;;return true;">http://www.eiffel.com/developers/xml/configuration-1-16-0" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFERp6A_kcvqihMCKJ7EHX8O14vIA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFERp6A_kcvqihMCKJ7EHX8O14vIA&#39;;return true;">http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="<a href="http://www.eiffel.com/developers/xml/configuration-1-16-0" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFW97HgsQjMeOmSO38wFnYj9ma5kw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFW97HgsQjMeOmSO38wFnYj9ma5kw&#39;;return true;">http://www.eiffel.com/developers/xml/configuration-1-16-0<a href="http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0.xsd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJ146uBmxdAkbFUg8m1oK9RF5mcg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0.xsd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJ146uBmxdAkbFUg8m1oK9RF5mcg&#39;;return true;">http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd" name="messenger" uuid="36ACE60F-96C1-445E-9755-6F88602EB468">
<target name="messenger">
<root class="ROOT" feature="make"/>
<file_rule>
<exclude>/CVS$</exclude>
<exclude>/EIFGENs$</exclude>
<exclude>/\.git$</exclude>
<exclude>/\.svn$</exclude>
</file_rule>
<option warning="true" is_obsolete_routine_type="true">
<assertions precondition="true" postcondition="true" check="true" invariant="true" loop="true" supplier_precondition="true"/>
</option>
<capability>
<concurrency support="scoop"/>
<void_safety support="all" use="all"/>
</capability>
<precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
<library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
<renaming old_name="SET" new_name="EIFFEL_SET"/>
<renaming old_name="BAG" new_name="EIFFEL_BAG"/>
</library>
<library name="espec" location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
<library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
<library name="encoding" location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
<library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
<library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
<library name="gobo_parse" location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
<library name="gobo_structure" location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
<library name="gobo_utility" location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
<library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
<library name="vision2" location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
  <cluster name="messenger" location=".\messenger\" recursive="true"/>
<cluster name="generated_code" location=".\generated_code\" recursive="true"/>
<cluster name="root" location=".\root\" recursive="true"/>
</target>
</system>

--
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: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?

Emmanuel Stapf
Administrator
What do you mean by not handled well? The only impact of a once per
process is that in SCOOP its type should be marked `separate` to
highlight the fact the instance will be shared among multiple SCOOP
processors.

Manu

On Wed, Jun 14, 2017 at 8:21 AM, Louis M <[hidden email]> wrote:

> Hi,
>
> There is also the "once ("PROCESS")" feature that is not handled well in
> SCOOP. In fact, in my case, it is a very big deal since I have a lot of
> singletons (with shared object) in my projects.
>
> Good day,
>
> Louis M
>
> Le vendredi 9 juin 2017 11:35:36 UTC-4, Alexander Kogtenkov a écrit :
>>
>> By default a project is SCOOP-capable. And usually if it does not use
>> native multithreading directly, and does not use separate types, it is
>> SCOOP-compatible, except for generic classes with unconstrained genericity,
>> where the default constraint is "detachable separate ANY". For most existing
>> code this is indeed the case. The same applies to "espec".
>>
>> With unconstraint genericity one would either need to take care about
>> calls on expressions of formal generic types - they have to be wrapped.
>> Alternatively, non-separate constraints could be added.
>>
>> At the moment the following libraries are SCOOP-incompatible:
>> - Thread - it breaks SCOOP assumptions by using free threading model
>> without any guarantee for transactional access to objects
>> - Process - it uses Thread (an alternative is to use BaseProcess (a
>> slightly limited version of Process) that does not rely on Thread)
>> - Testing - it relies on Thread and there is no good replacement yet
>> So, if a project or a library does not rely on these SCOOP-incompatible
>> libraries, there are good chances that it is SCOOP-compatible.
>>
>> Best regards,
>> Alexander Kogtenkov
>>
>> Jonathan Ostroff <[hidden email]>:
>>
>> Thanks for your replies, Alexander, which I very much appreciate.
>>
>> I assume that a library would have to specifically declare a Scoop
>> capability for it to be used with Scoop?
>>
>> Is there any documentation of when a library developed prior to Scoop
>> would be Scoop compatible? For example, the “espec” library does not use
>> threading etc. There are no declarations of “separate” anywhere in the code.
>> It would seem to be Scoop compatible. Are there any precautions that need to
>> be taken?
>>
>> Thanks and regards,
>>
>> Jonathan
>>
>>
>> On Jun 9, 2017, at 6:22 AM, 'Alexander Kogtenkov' via Eiffel Users
>> <[hidden email]> wrote:
>>
>> Dear Jonathan,
>>
>> Capabilities were introduced in EiffelStudio 17.01 as mentioned in the
>> release notes
>>
>>
>> https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01
>>
>> Some lower-level details could also be found at the developers site:
>>
>>    https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features
>>
>> Answering your specific questions:
>>
>> 1. Capabilities are specified at the level of a target, not a cluster or a
>> class, and are applied to all classes from the clusters belonging to the
>> target. This is the part "support", i.e. what the classes are capable of.
>> E.g., <void_safety support="all"/> means all classes of the associated
>> target are completely void-safe.
>>
>> As to libraries or an inherited target, their capabilities should be
>> sufficient for the current target, i.e. they should provide the same or
>> better guarantees. If the current target has complete void safety, all used
>> libraries should be completely void-safe as well.
>>
>> So, yes, with <void_safety support="all"/>, all used libraries are also
>> completely void-safe.
>>
>> As to the part "use", this is the current setting used to compile the
>> target, not to check the rules. E.g., one can build a single-threaded
>> application even if it supports SCOOP capability - this depends on the
>> application requirements.
>>
>> 2. According to compatibility table at
>>
>>
>> https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options
>>
>> if no specific setting is given, starting from EiffelStudio 14.05 the
>> default void safety is complete. This applies to "espec" library ECF as
>> well, i.e. it is completely void safe according to the default void safety
>> settings. These defaults are tightly coupled with ECF schema version, so old
>> projects can be compiled even with a newer compiler using default settings
>> of the earlier ECF version.
>>
>> 3. Attached-by-default is another compatibility setting that is True by
>> default starting from EiffelStudio 7.0. This option is going to disappear
>> altogether soon.
>>
>> You can consult default values of other compatibility options in the table
>> mentioned above.
>>
>> Best regards,
>> Alexander Kogtenkov
>>
>>
>> Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff
>> <[hidden email]>:
>>
>> I have a question about ECF files in 17.05 for complete Void safety. The
>> ECF file below seems to work ok, i.e. all the libraries and clusters appear
>> to satisfy complete Void safety, attached by default, full class checking
>> etc.
>>
>> But I am not sure why that is. Previously there would be a Void safe
>> settings. What we now have, it appears, is a capability declaration
>>
>> <capability>
>> <concurrency support="scoop"/>
>> <void_safety support="all" use="all"/>
>> </capability>
>>
>> 1. What is the effect of the above capability declaration on clusters such
>> as cluster “root", etc.? Is it the above declaration that ensures that all
>> the clusters and libraries are Void safe?
>>
>> 2. The project below imports the library “espec” (this is a testing
>> library developed by us at York University) in the contributed folder. The
>> ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in
>> a Void safe manner for the project defined below. So it would seem that
>> library ECF files need not state anything about their Void safety?
>> [Presumably because of the capability declaration in #1]
>>
>> 3. It also seems that the above Void safety automatically results in the
>> effect that all types as attached by default?
>>
>> Just checking to ensure that our tools generate the correct ECF files for
>> what was previously explicitly declared in ECF files to achieve attached by
>> default, complete Void safety and standard syntax. Also Full Class Checking.
>>
>> Thanks for any help,
>>
>> Jonathan
>>
>> P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu &
>> the Eiffel team, and the ECMA members for moving forward on this. It’s been
>> a demanding but productive journey.
>>
>> =====
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <system xmlns="http://www.eiffel.com/developers/xml/configuration-1-16-0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://www.eiffel.com/developers/xml/configuration-1-16-0http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd"
>> name="messenger" uuid="36ACE60F-96C1-445E-9755-6F88602EB468">
>> <target name="messenger">
>> <root class="ROOT" feature="make"/>
>> <file_rule>
>> <exclude>/CVS$</exclude>
>> <exclude>/EIFGENs$</exclude>
>> <exclude>/\.git$</exclude>
>> <exclude>/\.svn$</exclude>
>> </file_rule>
>> <option warning="true" is_obsolete_routine_type="true">
>> <assertions precondition="true" postcondition="true" check="true"
>> invariant="true" loop="true" supplier_precondition="true"/>
>> </option>
>> <capability>
>> <concurrency support="scoop"/>
>> <void_safety support="all" use="all"/>
>> </capability>
>> <precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
>> <library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
>> <renaming old_name="SET" new_name="EIFFEL_SET"/>
>> <renaming old_name="BAG" new_name="EIFFEL_BAG"/>
>> </library>
>> <library name="espec"
>> location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
>> <library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
>> <library name="encoding"
>> location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
>> <library name="gobo_kernel"
>> location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
>> <library name="gobo_lexical"
>> location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
>> <library name="gobo_parse"
>> location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
>> <library name="gobo_structure"
>> location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
>> <library name="gobo_utility"
>> location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
>> <library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
>> <library name="vision2"
>> location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
>>   <cluster name="messenger" location=".\messenger\" recursive="true"/>
>> <cluster name="generated_code" location=".\generated_code\"
>> recursive="true"/>
>> <cluster name="root" location=".\root\" recursive="true"/>
>> </target>
>> </system>
>
> --
> 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.



--
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

--
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.
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?

Louis M
Maybe it is me who do not understand SCOOP very well, but I think that marking the singleton as separate force you to put every thing that use the singleton as separate. So, if the singleton is used a lot in a system, it means changing a lot of code (attribute definition and separate code statement). I tried to made one of my library SCOOP compatible, but with the once("PROCESS") that I used in my library, the usage of the library (the interface) was a lot more complicated for the users. It is of course my humble opinion.

Good day,

Louis

Le mercredi 14 juin 2017 11:40:15 UTC-4, Emmanuel STAPF [ES] a écrit :
What do you mean by not handled well? The only impact of a once per
process is that in SCOOP its type should be marked `separate` to
highlight the fact the instance will be shared among multiple SCOOP
processors.

Manu

On Wed, Jun 14, 2017 at 8:21 AM, Louis M <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3-W4lrAxAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eif...@...> wrote:

> Hi,
>
> There is also the "once ("PROCESS")" feature that is not handled well in
> SCOOP. In fact, in my case, it is a very big deal since I have a lot of
> singletons (with shared object) in my projects.
>
> Good day,
>
> Louis M
>
> Le vendredi 9 juin 2017 11:35:36 UTC-4, Alexander Kogtenkov a écrit :
>>
>> By default a project is SCOOP-capable. And usually if it does not use
>> native multithreading directly, and does not use separate types, it is
>> SCOOP-compatible, except for generic classes with unconstrained genericity,
>> where the default constraint is "detachable separate ANY". For most existing
>> code this is indeed the case. The same applies to "espec".
>>
>> With unconstraint genericity one would either need to take care about
>> calls on expressions of formal generic types - they have to be wrapped.
>> Alternatively, non-separate constraints could be added.
>>
>> At the moment the following libraries are SCOOP-incompatible:
>> - Thread - it breaks SCOOP assumptions by using free threading model
>> without any guarantee for transactional access to objects
>> - Process - it uses Thread (an alternative is to use BaseProcess (a
>> slightly limited version of Process) that does not rely on Thread)
>> - Testing - it relies on Thread and there is no good replacement yet
>> So, if a project or a library does not rely on these SCOOP-incompatible
>> libraries, there are good chances that it is SCOOP-compatible.
>>
>> Best regards,
>> Alexander Kogtenkov
>>
>> Jonathan Ostroff <[hidden email]>:
>>
>> Thanks for your replies, Alexander, which I very much appreciate.
>>
>> I assume that a library would have to specifically declare a Scoop
>> capability for it to be used with Scoop?
>>
>> Is there any documentation of when a library developed prior to Scoop
>> would be Scoop compatible? For example, the “espec” library does not use
>> threading etc. There are no declarations of “separate” anywhere in the code.
>> It would seem to be Scoop compatible. Are there any precautions that need to
>> be taken?
>>
>> Thanks and regards,
>>
>> Jonathan
>>
>>
>> On Jun 9, 2017, at 6:22 AM, 'Alexander Kogtenkov' via Eiffel Users
>> <[hidden email]> wrote:
>>
>> Dear Jonathan,
>>
>> Capabilities were introduced in EiffelStudio 17.01 as mentioned in the
>> release notes
>>
>>
>> <a href="https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01" 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.01\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoTcOwfecS0VYmBc6zihoiH9M7IA&#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.01\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoTcOwfecS0VYmBc6zihoiH9M7IA&#39;;return true;">https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01
>>
>> Some lower-level details could also be found at the developers site:
>>
>>    <a href="https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdev.eiffel.com%2FEiffelStudio_17.01_Releases%23New_features\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmBz3N7AQjMk4xtOMqSOxBNTEVMg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdev.eiffel.com%2FEiffelStudio_17.01_Releases%23New_features\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmBz3N7AQjMk4xtOMqSOxBNTEVMg&#39;;return true;">https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features
>>
>> Answering your specific questions:
>>
>> 1. Capabilities are specified at the level of a target, not a cluster or a
>> class, and are applied to all classes from the clusters belonging to the
>> target. This is the part "support", i.e. what the classes are capable of.
>> E.g., <void_safety support="all"/> means all classes of the associated
>> target are completely void-safe.
>>
>> As to libraries or an inherited target, their capabilities should be
>> sufficient for the current target, i.e. they should provide the same or
>> better guarantees. If the current target has complete void safety, all used
>> libraries should be completely void-safe as well.
>>
>> So, yes, with <void_safety support="all"/>, all used libraries are also
>> completely void-safe.
>>
>> As to the part "use", this is the current setting used to compile the
>> target, not to check the rules. E.g., one can build a single-threaded
>> application even if it supports SCOOP capability - this depends on the
>> application requirements.
>>
>> 2. According to compatibility table at
>>
>>
>> <a href="https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FEiffel%2520compatibility%2520options\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEdWUj6KkWI9MCVrCom7WEZ5FDjdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.eiffel.org%2Fdoc%2Feiffelstudio%2FEiffel%2520compatibility%2520options\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEdWUj6KkWI9MCVrCom7WEZ5FDjdA&#39;;return true;">https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options
>>
>> if no specific setting is given, starting from EiffelStudio 14.05 the
>> default void safety is complete. This applies to "espec" library ECF as
>> well, i.e. it is completely void safe according to the default void safety
>> settings. These defaults are tightly coupled with ECF schema version, so old
>> projects can be compiled even with a newer compiler using default settings
>> of the earlier ECF version.
>>
>> 3. Attached-by-default is another compatibility setting that is True by
>> default starting from EiffelStudio 7.0. This option is going to disappear
>> altogether soon.
>>
>> You can consult default values of other compatibility options in the table
>> mentioned above.
>>
>> Best regards,
>> Alexander Kogtenkov
>>
>>
>> Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff
>> <[hidden email]>:
>>
>> I have a question about ECF files in 17.05 for complete Void safety. The
>> ECF file below seems to work ok, i.e. all the libraries and clusters appear
>> to satisfy complete Void safety, attached by default, full class checking
>> etc.
>>
>> But I am not sure why that is. Previously there would be a Void safe
>> settings. What we now have, it appears, is a capability declaration
>>
>> <capability>
>> <concurrency support="scoop"/>
>> <void_safety support="all" use="all"/>
>> </capability>
>>
>> 1. What is the effect of the above capability declaration on clusters such
>> as cluster “root", etc.? Is it the above declaration that ensures that all
>> the clusters and libraries are Void safe?
>>
>> 2. The project below imports the library “espec” (this is a testing
>> library developed by us at York University) in the contributed folder. The
>> ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in
>> a Void safe manner for the project defined below. So it would seem that
>> library ECF files need not state anything about their Void safety?
>> [Presumably because of the capability declaration in #1]
>>
>> 3. It also seems that the above Void safety automatically results in the
>> effect that all types as attached by default?
>>
>> Just checking to ensure that our tools generate the correct ECF files for
>> what was previously explicitly declared in ECF files to achieve attached by
>> default, complete Void safety and standard syntax. Also Full Class Checking.
>>
>> Thanks for any help,
>>
>> Jonathan
>>
>> P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu &
>> the Eiffel team, and the ECMA members for moving forward on this. It’s been
>> a demanding but productive journey.
>>
>> =====
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <system xmlns="<a href="http://www.eiffel.com/developers/xml/configuration-1-16-0" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFW97HgsQjMeOmSO38wFnYj9ma5kw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFW97HgsQjMeOmSO38wFnYj9ma5kw&#39;;return true;">http://www.eiffel.com/developers/xml/configuration-1-16-0"
>> xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFERp6A_kcvqihMCKJ7EHX8O14vIA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFERp6A_kcvqihMCKJ7EHX8O14vIA&#39;;return true;">http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="<a href="http://www.eiffel.com/developers/xml/configuration-1-16-0http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0http%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0.xsd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEwF9PQ3MVEhjlGjleDaTACiXbOg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0http%3A%2F%2Fwww.eiffel.com%2Fdevelopers%2Fxml%2Fconfiguration-1-16-0.xsd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEwF9PQ3MVEhjlGjleDaTACiXbOg&#39;;return true;">http://www.eiffel.com/developers/xml/configuration-1-16-0http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd"
>> name="messenger" uuid="36ACE60F-96C1-445E-9755-6F88602EB468">
>> <target name="messenger">
>> <root class="ROOT" feature="make"/>
>> <file_rule>
>> <exclude>/CVS$</exclude>
>> <exclude>/EIFGENs$</exclude>
>> <exclude>/\.git$</exclude>
>> <exclude>/\.svn$</exclude>
>> </file_rule>
>> <option warning="true" is_obsolete_routine_type="true">
>> <assertions precondition="true" postcondition="true" check="true"
>> invariant="true" loop="true" supplier_precondition="true"/>
>> </option>
>> <capability>
>> <concurrency support="scoop"/>
>> <void_safety support="all" use="all"/>
>> </capability>
>> <precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>
>> <library name="base" location="$ISE_LIBRARY\library\base\base.ecf">
>> <renaming old_name="SET" new_name="EIFFEL_SET"/>
>> <renaming old_name="BAG" new_name="EIFFEL_BAG"/>
>> </library>
>> <library name="espec"
>> location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>
>> <library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>
>> <library name="encoding"
>> location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>
>> <library name="gobo_kernel"
>> location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>
>> <library name="gobo_lexical"
>> location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>
>> <library name="gobo_parse"
>> location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>
>> <library name="gobo_structure"
>> location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>
>> <library name="gobo_utility"
>> location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>
>> <library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>
>> <library name="vision2"
>> location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>
>>   <cluster name="messenger" location=".\messenger\" recursive="true"/>
>> <cluster name="generated_code" location=".\generated_code\"
>> recursive="true"/>
>> <cluster name="root" location=".\root\" recursive="true"/>
>> </target>
>> </system>
>
> --
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3-W4lrAxAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eiffel-users...@googlegroups.com.
> Visit this group at <a href="https://groups.google.com/group/eiffel-users" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/eiffel-users&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/eiffel-users&#39;;return true;">https://groups.google.com/group/eiffel-users.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.



--
------------------------------------------------------------------------
Eiffel Software
805-685-1006
<a href="http://www.eiffel.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHBf8xi5WAkrrGUeBXLV-vL1G3l1A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHBf8xi5WAkrrGUeBXLV-vL1G3l1A&#39;;return true;">http://www.eiffel.com
Customer support: <a href="http://support.eiffel.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsupport.eiffel.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEPTpFBJC4hKLyoK4lBIbe5YQR22g&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsupport.eiffel.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEPTpFBJC4hKLyoK4lBIbe5YQR22g&#39;;return true;">http://support.eiffel.com
User group: <a href="http://groups.eiffel.com/join" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fgroups.eiffel.com%2Fjoin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHwhmYV4sqJWqKDmSHi7D9C2etwzg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fgroups.eiffel.com%2Fjoin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHwhmYV4sqJWqKDmSHi7D9C2etwzg&#39;;return true;">http://groups.eiffel.com/join
------------------------------------------------------------------------

--
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: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?

Emmanuel Stapf
Administrator
You are right, the handling separate objects has its trade-off but we
made it simpler with inline separate:

my_routine
    do
        separate my_singleton as singleton do
            singleton.do_something
        end
    end

It is more than before but if you compare this to a traditional
approach in multithreaded programming it is still acceptable:

my_routine
     do
         my_singleton_mutex.lock
         my_singleton.do_something
         my_singleton_mutex.unlock
    end

and I'm not including the rescue clause to unlock the mutex in case of
exceptions.

Also if the singleton is created using a passive region as in :

    create <NONE> Result.make

the separate calls are more efficient since only synchronization and
context switching are done, and the routine `do_something` is executed
locally.

Manu

On Wed, Jun 14, 2017 at 9:21 AM, Louis M <[hidden email]> wrote:

> Maybe it is me who do not understand SCOOP very well, but I think that
> marking the singleton as separate force you to put every thing that use the
> singleton as separate. So, if the singleton is used a lot in a system, it
> means changing a lot of code (attribute definition and separate code
> statement). I tried to made one of my library SCOOP compatible, but with the
> once("PROCESS") that I used in my library, the usage of the library (the
> interface) was a lot more complicated for the users. It is of course my
> humble opinion.
>
> Good day,
>
> Louis

--
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.
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] ES17.05 Capability Complete Void Safety?

Eric Bezault
On 6/14/2017 19:37, Emmanuel Stapf wrote:
> It is more than before but if you compare this to a traditional
> approach in multithreaded programming it is still acceptable:
>
> my_routine
>       do
>           my_singleton_mutex.lock
>           my_singleton.do_something
>           my_singleton_mutex.unlock
>      end

I have many cases in my code where the 'once ("PROCESS")' actually
defines a immutable object (like a user-defined constants when the
types is not a basic type or STRING). In that case, in a multithreaded
environment I don't use mutexes (several threads can access the same
object at the same time). How would that translate in a SCOOP
environment?

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

--
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: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?

Louis M
In reply to this post by Emmanuel Stapf

It is more than before but if you compare this to a traditional
approach in multithreaded programming it is still acceptable:

The problem here is that multithread was not the default settings. So when somebody was using my library, they does not have to handle mutexes. Also, when a user actually enabled multithreading, they understand that multithread needed some synchronisation. But now that SCOOP is the default setting in EiffelStudio, when a new user want to use one of my library, it have to handle separate call almost everywhere in there code. Maybe it is because people does not understand SCOOP yet, but I had a lot's of complain about my library being too difficult to understand because of that.

Also if the singleton is created using a passive region as in :

    create <NONE> Result.make


Hmmm. What is this syntax. Is there a documentation about this?

Thanks,

Louis M

--
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] ES17.05 Capability Complete Void Safety?

Emmanuel Stapf
Administrator
In reply to this post by Eric Bezault
Immutable objects are very important in simplifying SCOOP, but until
they are a first class citizen SCOOP cannot benefit from this.

My naive response for the time being is why do you need it per
process, why not making it a per processor/thread? We have done this
in many cases where there was no semantic differences between having
it per process or per processor/thread.

Manu

On Wed, Jun 14, 2017 at 11:41 AM, Eric Bezault <[hidden email]> wrote:

> On 6/14/2017 19:37, Emmanuel Stapf wrote:
>>
>> It is more than before but if you compare this to a traditional
>> approach in multithreaded programming it is still acceptable:
>>
>> my_routine
>>       do
>>           my_singleton_mutex.lock
>>           my_singleton.do_something
>>           my_singleton_mutex.unlock
>>      end
>
>
> I have many cases in my code where the 'once ("PROCESS")' actually
> defines a immutable object (like a user-defined constants when the
> types is not a basic type or STRING). In that case, in a multithreaded
> environment I don't use mutexes (several threads can access the same
> object at the same time). How would that translate in a SCOOP
> environment?
>
> --
> Eric Bezault
> mailto:[hidden email]
> http://www.gobosoft.com



--
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

--
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.
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?

Emmanuel Stapf
Administrator
In reply to this post by Louis M
This is the reason we introduced capabilities. Simply mark your
library not SCOOP-able and then your users will have to downgrade
their setting to match yours if they do not care about SCOOP. If they
do then they will most likely require you to upgrade their code.

This is the notion of passive region introduced in 15.08 (see
https://www.eiffel.org/doc/eiffelstudio/Major%20changes%20between%20ISE%20Eiffel%2015.01%20and%20ISE%20Eiffel%2015.08).
There is not yet a documentation about the syntax but the definition
is : <<In the SCOOP model, a passive region does not have a processor
attached to it.This means that clients of the passive region need to
apply features logged against a passive region themselves.The logical
consequence of this is that all call to a passive region, including
commands, are executed synchronously.>>

Manu

On Wed, Jun 14, 2017 at 12:00 PM, Louis M <[hidden email]> wrote:

>
>> It is more than before but if you compare this to a traditional
>> approach in multithreaded programming it is still acceptable:
>>
> The problem here is that multithread was not the default settings. So when
> somebody was using my library, they does not have to handle mutexes. Also,
> when a user actually enabled multithreading, they understand that
> multithread needed some synchronisation. But now that SCOOP is the default
> setting in EiffelStudio, when a new user want to use one of my library, it
> have to handle separate call almost everywhere in there code. Maybe it is
> because people does not understand SCOOP yet, but I had a lot's of complain
> about my library being too difficult to understand because of that.
>
>> Also if the singleton is created using a passive region as in :
>>
>>     create <NONE> Result.make
>>
>
> Hmmm. What is this syntax. Is there a documentation about this?
>
> Thanks,
>
> Louis M
>
> --
> 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.



--
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

--
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.
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [eiffel-users] ES17.05 Capability Complete Void Safety?

Eric Bezault
In reply to this post by Emmanuel Stapf
On 6/14/2017 21:02, Emmanuel Stapf wrote:
> Immutable objects are very important in simplifying SCOOP, but until
> they are a first class citizen SCOOP cannot benefit from this.
>
> My naive response for the time being is why do you need it per
> process, why not making it a per processor/thread? We have done this
> in many cases where there was no semantic differences between having
> it per process or per processor/thread.

Most of the time there is indeed no semantic differences.
But there are speed and/or memory differences when it takes
time and/or memory to create these objects. There is also
a speed difference when we have to compare such objects
field by field instead of just doing a reference comparison.
We don't convert our code to use concurrency just for the
beauty of the exercise, but also to improve the performance
of our programs.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

--
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] ES17.05 Capability Complete Void Safety?

Emmanuel Stapf
Administrator
It is a tradeoff, but usually for large objects it is much harder to ensure they are immutable.

Manu

> -----Original Message-----
> From: Eric Bezault [mailto:[hidden email]]
> Sent: Wednesday, June 14, 2017 23:23
> To: Emmanuel Stapf <[hidden email]>
> Cc: Eiffel Users <[hidden email]>; Alexander Kogtenkov
> <[hidden email]>
> Subject: Re: [eiffel-users] ES17.05 Capability Complete Void Safety?
>
> On 6/14/2017 21:02, Emmanuel Stapf wrote:
> > Immutable objects are very important in simplifying SCOOP, but until
> > they are a first class citizen SCOOP cannot benefit from this.
> >
> > My naive response for the time being is why do you need it per
> > process, why not making it a per processor/thread? We have done this
> > in many cases where there was no semantic differences between having
> > it per process or per processor/thread.
>
> Most of the time there is indeed no semantic differences.
> But there are speed and/or memory differences when it takes time
> and/or memory to create these objects. There is also a speed
> difference when we have to compare such objects field by field instead
> of just doing a reference comparison.
> We don't convert our code to use concurrency just for the beauty of
> the exercise, but also to improve the performance of our programs.
>
> --
> Eric Bezault
> mailto:[hidden email]
> http://www.gobosoft.com

--
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.
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Loading...