Forum

Hi! I have no answer for this, but questions: Does the Eiffel runtime have provisions to measure where time was spent (a tool like gprof)? If so, is there a way to let the compiler explain where it spent its time? My only idea for the problem is (as Eiffel may be resource-hungry): Do you have

Sounds like global dataflow analysis cost when changing a class inherited by and/or used by a large number of other classes. Each dependency needs to be verified. R -------- Original Message -------- Subject: [eiffel-users] Some thing make pass 3 of the compiler very slow for class depending of

I just change the color value in a class which is a descendent of EV_WIDGET. Only one correction on one class ! mardi 23 février 2021, 19:15:39 (UTC+0100) Eiffel Compilation Manager Version 20.11.10.5048 - linux-x86-64 Degree 6: Examining System Degree 5: Parsing Classes Degree 4:

numbers, > a and b: > > loop > sum [i] := a [i] + b [i] + carry > if sum [i] < a [i] then -- NATURAL wraps around past zero if > too big > carry := 1 > else > carry := 0 > end > i := i + 1 > end > > The above

Does anyone know of an Eiffel-based shell program similar to JShell? See: tryjshell.org

Hey, thanks. Will look at that. But I'm still curious if about SCOOP jjj On Saturday, February 20, 2021 at 11:14:22 AM UTC-7 Finnian Reilly wrote: > > I have a class BIG_NUMBER implemented as an ARRAY [NATURAL_8] where each > array `item' represents a "digit" in base-256. To naively add two

Yes, NATURAL_8 was for illustration only. "a separate region for each digit is too costly." Sure, but I just wanted to know if it were possible and how to do it, so I could better understand SCOOP. I thought perhaps a look-ahead for a segment of digits, where a normal add within the segment.

I have a class BIG_NUMBER implemented as an ARRAY [NATURAL_8] where each array `item' represents a "digit" in base-256. To naively add two numbers, a and b: Maybe class INTEGER_X found in "$ISE_EIFFEL/contrib/library/math/eapml/eapml.ecf" already has what you need?

Unless the numbers have thousands/millions of digits making the addition using SCOOP would not make the program faster. It would be much more efficient to use NATURAL_64 instead of NATURAL_8 instead. Also, an optimized implementation for a specific number length could make the difference, e.g.

Hi Anders! Thank you for your kind response and feedback! Yes—it is interesting how far AI-based text-to-speech has come. I can still detect that it is a generated voice because I know what to watch out for while listening. BUT—that line is getting more and more blurry. To the unsuspecting, I

Question to the SCOOP experts out there: I have a class BIG_NUMBER implemented as an ARRAY [NATURAL_8] where each array `item' represents a "digit" in base-256. To naively add two numbers, a and b: loop sum [i] := a [i] + b [i] + carry if sum [i] < a [i] then -- NATURAL

Hi Larry Nice video. I did not understand that it was a computer generated voice when I listened to it. Vänligen Anders Persson BSharp AB Linked in profile +46 763 17 23 25 On Fri, 19 Feb 2021 at 11:48, Larry Rix wrote: > I am using an AI-generated voice for

I am using an AI-generated voice for the narration. I chose this particular voice because I love Australian accents and wanted a female voice rather than a male. In honesty—I chose a female voice for the same reason the US Air Force chose a female voice for their cockpit voice system because men

Nice! Completely understandable, and a great sales job IMHO. My narrator was a British-accented speaker, I'm guessing because my Region is New Zealand? Or is that just your preferred narrator? On Fri, Feb 19, 2021 at 4:24 AM Larry Rix wrote: > https://youtu.be/b5AS

LOL ... Oh my ... I totally love the "COVID-19 Negative" tag on your contact info!!! That is truly hilarious!!! On Monday, February 8, 2021 at 1:37:52 AM UTC-5 johns...@wolterworks.com wrote: > > Mr. Rix, 6:48 PM? What part of planet Earth R U located? > > > > Cheers, John S. Wolter > ---------

Savannah, GA USA On Monday, February 8, 2021 at 1:37:52 AM UTC-5 johns...@wolterworks.com wrote: > > Mr. Rix, 6:48 PM? What part of planet Earth R U located? > > > > Cheers, John S. Wolter > ------------------------------------------------------------ > Wolter Works, LLC > EMail: johns...@wolter

https://youtu.be/b5ASMYWrhSE

Hi all. Although REAL_32 etc. have a feature like product alias "*" alias "×" (other: REAL_32): REAL_32, the operator "×" (Unicode 00D7) is not present in the dialog "Insert symbols". I've been wondering... why? Was it overlooked? Some technical reason? Does any one know? Best

Dear Finnian! All of what you have stated is largely true. 15-plus years of coding effort is excellent and worthwhile. It really needs to be usable to 20.11 and beyond. Given all of this, there is a possible dove-tail. There is a consideration out there to make a pitch to possible clients where

Dear Larry I have spent another hour-plus this morning trying to isolate even a small part of Eiffel-loop to where I can get it to compile in a version of Eiffel Studio beyond 16.05. I have once again failed. Sorry you experienced this frustration. It might be easier with a tool such as I have

More thoughts Or the tool can even be made more granular and only copy one class at a time, between prompts. Or the tool can be easily made to create a tabular menu of all the classes in the current dependency layer, and lets you choose which one you want to work on next, perhaps by first

Dear Larry my apologies again for confusing with someone called "Irix". Silly me! I have spent another hour-plus this morning trying to isolate even a small part of Eiffel-loop to where I can get it to compile in a version of Eiffel Studio beyond 16.05. I have once again failed. I have an idea!

Hi Larry, All of this is really great. However, have you had any success at all in making Eiffel-loop Void-safe and SCOOP-friendly? Unfortunately not, but if enough people are interested to sponsor this gargantuan task here is my offer: I am willing to undertake the task for € 24.00 EUR/hour

I have spent another hour-plus this morning trying to isolate even a small part of Eiffel-loop to where I can get it to compile in a version of Eiffel Studio beyond 16.05. I have once again failed. I would love to use some of this lovely and well-crafted code you have created, but asking me (any

HI Finnian! All of this is really great. However, have you had any success at all in making Eiffel-loop Void-safe and SCOOP-friendly? Kindest regards, Larry