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?

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]`

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

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

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

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

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

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

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

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

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

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

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

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

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,

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.

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

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

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

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

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

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.

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

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

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.