19.12 was a beta version, accordingly you can find it in the beta folder: https://sourceforge.net/projects/eiffelstudio/files/beta/ -- Vivien Moreau (jmiven)

And it seems as of now (April 11/21), the 19.12 gpl edition is no longer available from Sourceforge. I could only download 19.05. On Friday, March 12, 2021 at 3:16:23 AM UTC-5 Ulrich W. wrote: > >>> Richard schrieb am 11.03.2021 um 17:34 in > Nachricht <3bd4afdf-ecb7-4

What a wonderful link — I could not imagine how many things were thought of so a long time ago. Moreover, many things have been implemented partially, completely or even with a better outcome than initially expected. But you are right, the document does not include all potential improvements,

To Alexander Kogtenkov : About the possible additional simplifications of currying that you mentioned, are they included in the working paper "Eiffel as a functional programming language" (created in 2012, last updated in 2014) ? To Bertrand Meyer : The evolution of Eiffel has been ongoing

Thanks to all -- My current problem resolved, and looking forward to further currying simplifications ... Regards, Howard On Thursday, 8 April 2021 at 11:16:53 UTC+1 kwa...@mail.ru wrote: > Eiffel is constantly evolving in the direction of simplification. For > example, the presented code uses

Hi Jocelyn It's a bit late to check the times on the rc files in question (I should have done that before). My guess is that, yet, the file in question is a leftover, BUT, all this trouble began when my old system's motherboard went South and I had to build a new system from the rubble. I

Hi, I have just tried again to use mingw, and for me the generated file .rc contains something like "This Program was made using EiffelStudio using GCC" in fact, the .rc is generated using the %ISE_EIFFEL%\studio\config\win64\mingw\eiffel.rc Then I guess, the .rc file you have is from a previous

Eiffel is constantly evolving in the direction of simplification. For example, the presented code uses much more readable PROCEDURE [STRING, STRING] instead of the old PROCEDURE [ANY, TUPLE [STRING, STRING]]. Similarly, at some point it should be possible to replace the boilerplate code

<161786898...@f301.i.mail.ru>: > You are talking about "currying". Routine classes are using tuples to pass > arguments to feature calls. As a result, direct currying is impossible (as, I > guess, you figured out by trial and error). A wrapper (as pointed out in > another reply) can be used

You are talking about "currying". Routine classes are using tuples to pass arguments to feature calls. As a result, direct currying is impossible (as, I guess, you figured out by trial and error). A wrapper (as pointed out in another reply) can be used instead. Let’s look at an example.

Hi, take a look at stackoverflow -> eiffel agent. I remember I had a similar question.... https://stackoverflow.com/questions/55406410/eiffel-passing-argument-to-agent-received-as-argument Maybe this one answers your question. The idea is to encapsulate your call into another with only one

Hi, I am familiar with the syntax for an agent with one open and one closed operand, as directly useable in: expose_actions.extend (agent draw_date (?, l_grid_item)) which works in the original [single] context in which I wrote it. Can I pass an agent to a routine with two open operands, and then

Hi, I am familiar with the syntax for an agent with one open and one closed operand, as directly useable in: expose_actions.extend (agent draw_date (?, l_grid_item)) which works in the original [single] context in which I wrote it. Can I pass an agent to a routine with two open operands, and then

Nachricht <537cde1b-9892-467b-9792-2b426a046b85n@googlegroups.com>: > At least for the last couple of years an online PDF version of Touch of > Class has been freely downloadable from this address > http://se.ethz.ch/~meyer/down/touch/TOUCH.pdf Having bought the book, I missed to get the

Thanks Bertrand! Best, Enrico Il 06/04/2021 17:44, Bertrand Meyer ha scritto: > Dear Enrico, > > I think it was more of a glitch; a version that I made temporarily available and forgot to remove (until sometime ago (forgot when). > > Please contact Springer. They have formulas available

Dear Enrico, I think it was more of a glitch; a version that I made temporarily available and forgot to remove (until sometime ago (forgot when). Please contact Springer. They have formulas available for universities using textbooks, including electronically. Thanks, -- BM

At least for the last couple of years an online PDF version of Touch of Class has been freely downloadable from this address http://se.ethz.ch/~meyer/down/touch/TOUCH.pdf I think this happened after the release of the 2nd edition of the book and I used to point my students there. I'm not

The ability to address a single byte of memory is in the days of yore. For a long time, the minimum addressable memory unit is not a single byte, but 8-16-32-64 bytes instead. The CPU cache lines have similar addressable storage capacity. The CPUs still support reading and writing single bytes.

Hi Alexander It turns out that the inlining factor plays an essential role to get the best results. My version (it differs from the C++ version by very efficient bit counting algorithm, but this affects only the final step, not the main loop) with the factor set to 15 outperforms the C++

<161721501...@f496.i.mail.ru>: > Hi Finnian, > > I’ll send my version (or, more precisely, fragments of it) to you privately > because I did not use EL_* classes. > > It turns out that the inlining factor plays an essential role to get the > best results. My version (it differs from

<161713138...@f302.i.mail.ru>: > Both C++ and C# use a specialized version of a bit vector, not an array of > Boolean values. A more realistic comparison would be to replace "BitArray" in > the C# implementation with "bool []". > > The reverse could also be modelled by packing BOOLEANs

'tis I again I just ran into a new issue trying to test some existing classes using 19.05. I don't know how this could happen, because everything seems to be correct. I get a precondition violation from the 'copy' routine in a data structure class of mine. The 'copy' routine comes from ANY,

OK, I'll offer one of my own. Looking around for anything "resource" related, I discovered that the ds_test.rc file in the project directory was empty. I then compared it to another (newer) project's .rc file and found that the newer project's file actually had some content. So, I copied that

Any hints? Nearly at the end of C compilation (but not _at_ the end, there is this error. v 19.05 "C:\Program Files\Eiffel Software\EiffelStudio 19.05 GPL/gcc/win64/mingw/bin/ld" -r -o Cobj9.o big_file_C9_c.o c:\Program Files\Eiffel Software\EiffelStudio 19.05 GPL\gcc\win64\mingw\bin\windres.e

Hi Irix. I hope I'm not getting wrong your question, but I have managed to get the type of a generic via querying {TYPE}.generic_parameter_type feature. Below is the code of a function I've written where I use such a facility. Hope this helps. Best regards, Rosivaldo. result_typ