Thanks very much. I think it's beginning to soak in. On Sun, Jun 25, 2017 at 9:44 PM, 'Alexander Kogtenkov' via Eiffel Users < eiffel...@googlegroups.com> wrote: > 32 printed by the C program means 32 bytes. Given that the array contains > 8 elements and each element is 4 bytes, 32 = 8 * 4. > >

32 printed by the C program means 32 bytes. Given that the array contains 8 elements and each element is 4 bytes, 32 = 8 * 4. In C, for (complete) arrays, sizeof gives the number of bytes occupied by the whole array. If memory occupied by a pointer is of interest instead, either &a should be

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 wrote:

There's something I don't understand. When I check in a C program on my x86_64 GNU/Linux machine const int a[8] = { 0, 1, 2, 3, 4, 5, 6, 7 }; int i, sum; printf ("%lu, %lu", sizeof (a) , sizeof (*a)); I get 32, 4 In EiffelStudio, when I check {PLATFORM}.Integer_32_bytes I get 4, so

Berend> [1 ] >>>>> "Eiffel" == Eiffel Users 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

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

Hello all, trying to setup estudio 16.05 gpl with visual studio 2017 community edition installed: my environment variable is set, but espawn.exe -l says: C:\Eiffel_Software\EiffelStudio_16.05_GPL\tools\spec\win64\bin>espawn.exe -l Eiffel Environment Command Spawn Utility - Version: 16.05

According to release notes https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.05 support for Visual Studio 2017 has been added in EiffelStudio 17.05. It is not available in earlier versions. Alexander Kogtenkov Среда, 21 июня 2017, 16:45 +03:00 от

Hi Bertrand, Thanks for the message and while I'd love to, I unfortunately won't have the available time between work and now that my kids are keeping me that much busier. Good luck with the project and if anything changes I'll let you know. Hubert From: Bertran...@inf.ethz.ch Sent: June 16,

We are ready to start with an effort related to the goals listed below. Before I start putting together the project, I am checking that I am not missing anyone. Many people commented in the discussion that followed my message, but it was not always clear whether they actually wanted to be

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:er...@gobosoft.com] > Sent: Wednesday, June 14, 2017 23:23 > To: Emmanuel Stapf > Cc: Eiffel Users

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.

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

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

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

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

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

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

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

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 wrote: > Hi,

I've seen the terms entity, variable, and argument used to describe things about Eiffel, that look quite similar to me, and I wanted to understand what is the intention behind using either term instead of the other.

Arguments — Some routines require some data in order to run. Imagine a fictitious feature foo (x, y: INTEGER; z: BOOLEAN). This routine takes 3 arguments: x, y, and z. When you call the routine, you must give it three valid arguments, for instance foo(6, 92, False). These values we passed to the routine are called actual arguments, while the placeholders defined in the definition are called formal arguments.

I've read of object fields, which specify the place inside the object structure where values are stored (either references or expanded objects).

I think the only time I saw the term variables was for local variables, inside features.

And entity seems to be a generic term for denoting a data-container with a name, so local variables, arguments, and querys (features that return some data) are all examples of entities.

And in what category would Current and Result fall? Local variables?

Could someone help me with the terminology?

Dear Harald, According to the diagram tool documentation, it has a current context that is either a cluster or a class: https://www.eiffel.org/doc/eiffelstudio/Contexts For clusters there is only sub-cluster and super-cluster relationships. When you click on the button "Target to cluster or

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

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”

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/EiffelStu