Forum

by Jocelyn-Fiat (modified: 2018 Sep 05)

:: Welcome :: Forum

Eiffel related groups and forums:

Check the latest messages:

  • Nov 20
    Eiffel: how do I get the type of a particular operand of a procedure

    As I can see into the debugger it's possible to get the operands, and name of procedure, is there a way to get it?

    • PROCEDURE=>operands returns a detachable that seems return the operands only when they have been setted into the agen
    • Do I have pass through any REFLECTOR class because the PROCEDURE class doesn't have this function and in this case why?

    enter image description here

  • Nov 20
    Eiffel: are the convert methods working in case of agen call arguments?

    I'm calling a procedure with an argument which is an integer_64. I implemented a WATT class which can create it from an INTEGER_64 and it seems the execution stops when reached this point, where am I wrong?

    Catcall detected for argument#1args': expected TUPLE [!WATT] but got TUPLE [INTEGER_64]`

    enter image description here

  • Nov 19
    Re: [eiffel-users] Re: re-attaching arguments to features
    Surely my "naive" implementation of this program in C# would not look the same as the "naive" implementation made by someone who uses C# every day! Also, the "naive" implementation in Eiffel would use loop, not recursion. So what is asked (naive + recursion) does not exist in Eiffel. If
  • Nov 19
    Re: [eiffel-users] Re: re-attaching arguments to features
    Peter If “Java and similar languages” are slower, then maybe it’s garbage > collection that’s slowing them down. The other languages don’t have GC as > far as I know. Have you had the opportunity to try switching GC off in your > Eiffel version? > I realized later that that statement might burn
  • Nov 19
    Re: [eiffel-users] Re: re-attaching arguments to features
    Hi John, > You mentioned the gobo eiffel compiler. I've seen it before, and I know > it's your work. Are you saying that it is likely to be more efficient on > certain things than Eiffel.com's compiler achieves with finalized code? > > Also, its webpage indicates that a lot of Eiffel's
  • Nov 19
    Re: [eiffel-users] Re: re-attaching arguments to features
    Hi John, If “Java and similar languages” are slower, then maybe it’s garbage collection that’s slowing them down. The other languages don’t have GC as far as I know. Have you had the opportunity to try switching GC off in your Eiffel version? Peter On 19 Nov 2018, at 19:39, John Perry
  • Nov 19
    Re: [eiffel-users] Re: re-attaching arguments to features
    Oops. I should qualify something. it cut the running time by ~33% on my machine -- finally something > significant! That's still quite a bit slower than most other compiled > languages... > I mean, it's "quite a bit slower than most other compiled languages I've actually tried from that
  • Nov 19
    Re: [eiffel-users] Re: re-attaching arguments to features
    Eric It turns out that this idea helped a lot. It required a bit more detail than this -- I really had to study the algorithm -- but it cut the running time by ~33% on my machine -- finally something significant! That's still quite a bit slower than most other compiled languages, but at this
  • Nov 17
    Re: [eiffel-users] Re: re-attaching arguments to features
    Hi John, > I did try rewriting one procedure (not the ones given here) as a loop, > instead of recursive. The difference was huge: a 33% reduction in time, > with the output still correct this time :-) > > I'll talk to the organizer about using loops instead of recursion. If recursivity is
  • Nov 17
    Re: [eiffel-users] Re: re-attaching arguments to features
    Hi R I tried to disable it via collection_off, and also tried using free(), all without significant effect. I did try rewriting one procedure (not the ones given here) as a loop, instead of recursive. The difference was huge: a 33% reduction in time, with the output still correct this time :-)
  • Nov 17
    RE: [eiffel-users] Re: re-attaching arguments to features
    Hi John It does have an impact, and you can control it. You might recall that the MEMORY class provides features to control GC. For this kind of exercise, disabling collection certainly won't hurt things, and will eliminate its effect. R -------- Original Message -------- Subject: Re: [eiffel-u
  • Nov 17
    Re: [eiffel-users] Re: re-attaching arguments to features
    While reviewing the issue, I noticed that in some languages used to implement this algorithm (e.g., Haskell) tinkering with garbage collector parameters led to a huge speedup in timing. Similarly, the Modula-3 implementation's time decreases by 50% when one switches from traced references to
  • Nov 17
    Re: [eiffel-users] Re: re-attaching arguments to features
    For those who want to know, the overall project builds a tree using recursive merge, then searches for elements, or erases them, by recursive split, followed by recursive merge. The task is actually a challenge to implement this algorithm/approach as efficiently as possible in different
  • Nov 17
    RE: [eiffel-users] Re: re-attaching arguments to features
    Hi John With all the good suggestions from everyone, we seem to have lost sight of a fundamental principle of design - query/command separation. We're looking to create a deliberate side-effect and that is not good thing. It strikes me that a better approach is to create a function (not a
  • Nov 17
    Re: [eiffel-users] Re: re-attaching arguments to features
    Hi John, I think that MEMO was the equivalent of CELL in SmartEiffel. > Everyone's tried to be helpful but the more I try to use CELL and TUPLE > the more I don't see how they're actually helpful in my case -- > efficiency being a prime concern. So I thought I'd show comparable Ada > code,
  • Nov 17
    Re: re-attaching arguments to features
    Everyone's tried to be helpful but the more I try to use CELL and TUPLE the more I don't see how they're actually helpful in my case -- efficiency being a prime concern. So I thought I'd show comparable Ada code, along with my current Eiffel code, & see if anyone can lift the fog from my mind.
  • Nov 17
    Re: [eiffel-users] Re: re-attaching arguments to features
    I find that it is best to use a "named TUPLE" when passing a TUPLE. You can just pass a plain TUPLE and then access the items like an array, but (to me) the code is difficult to read and there are no real semantics because one does not have names. The thing to know about CELL is—first—it is a
  • Nov 16
    Re: [eiffel-users] Re: re-attaching arguments to features
    On Friday, November 16, 2018 at 5:18:22 PM UTC-6, Peter Gummer wrote: > John Perry wrote: > > > I've not heard of the CELL thing; that looks new, but maybe I was unaware > of it before. > > > > I remember CELL from more than 15 years ago, John, and I think it was > being used
  • Nov 16
    Re: [eiffel-users] Re: re-attaching arguments to features
    John Perry wrote: I've not heard of the CELL thing; that looks new, but maybe I was unaware of it before. I remember CELL from more than 15 years ago, John, and I think it was being used in code that was already quite old back then. It was common to see it used as the
  • Nov 16
    Re: re-attaching arguments to features
    I've not heard of the CELL thing; that looks new, but maybe I was unaware of it before. The big question for me is, is it *efficient*? I will try it later. I think Larry Rix's idea is essentially what I ended up doing, though I didn't use a TUPLE. I will probably try that, too. I had tried
  • Nov 16
    Re: [eiffel-users] re-attaching arguments to features
    Yep-- that is another way. The idea is that while the object reference itself cannot be changed, a reference within it can. Be it CELL or TUPLE or some other object you create and pass, the setup is the same. CELL is a great way to do it. On Fri, Nov 16, 2018, 11:20 AM
  • Nov 16
    Re: re-attaching arguments to features
    For string arguments you can use the `share' routine to change the value of the string. For numeric arguments you can use the X_REF form where X is a numeric type, INTEGER_REF for example. Use routine `set_item' to change the value.
  • Nov 16
    RE: [eiffel-users] re-attaching arguments to features
    If the argument is to be replaced in the procedure, then you can change the argument from type X to a CELL of type X. replace_something_with_another_thing (tc: CELL [THING]) do tc.put (some_other_thing) end R -------- Original Message -------- Subject: Re: [eiffel-users] re-attachin
  • Nov 16
    Re: [eiffel-users] re-attaching arguments to features
    Hi john, Consider implementing a - function with keyword result xor - procedure p that sets a class attribute a Have fun Gerrit Am Fr., 16. Nov. 2018, 17:55 hat Colin Adams geschrieben: > Your understanding is correct. > > On Fri, 16 Nov 2018 at 16:33, John Perry
  • Nov 16
    Re: [eiffel-users] re-attaching arguments to features
    Hi John, You can also pass an object as an argument where the object has features and the features of that object can be attached or reattached. One simple way to do this without using an object is to pass a named Tuple and and then attach or reattach or a sign too the element of the Tuple.
  • See more ...