Forum

by Jocelyn Fiat (modified: 2017 May 24)

:: Welcome :: Forum

Eiffel related groups and forums:

Check the latest messages:

  • Jun 25
    Re: [eiffel-users] Width of POINTER
    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. > >
  • Jun 25
    Re: [eiffel-users] Width of POINTER
    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
  • Jun 24
    Re: [eiffel-users] EiffelStudio 17.05 is now available!
    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:
  • Jun 24
    Width of POINTER
    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
  • Jun 24
    Re: [eiffel-users] EiffelStudio 17.05 is now available!
    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
  • Jun 24
    Re: [eiffel-users] EiffelStudio 17.05 is now available!
    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
  • Jun 21
    set ISE_C_COMPILER=msc_vc140 and espawn.exe -l
    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
  • Jun 21
    Re: [eiffel-users] set ISE_C_COMPILER=msc_vc140 and espawn.exe -l
    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 от
  • Jun 19
    Re: Confirm if interested -- RE: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    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,
  • Jun 16
    Confirm if interested -- RE: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    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
  • Jun 15
    RE: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 15
    Re: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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.
  • Jun 14
    Re: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 14
    Re: Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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,
  • Jun 14
    In Eiffel, what is the difference between entities, variables, fields and arguments?

    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?

  • Jun 12
    Re: [eiffel-users] Diagram tool loses client-link
    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
  • Jun 09
    Re[2]: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • Jun 09
    Re: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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”
  • Jun 09
    Re: [eiffel-users] ES17.05 Capability Complete Void Safety?
    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
  • See more ...