Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 23 2019 15:21

    manuseiffel on master

    Updated Interaction email code … (compare)

  • Dec 23 2019 11:21

    manuseiffel on master

    Moved the gobo eof at expected … (compare)

  • Dec 20 2019 21:21

    manuseiffel on master

    Updated scripts for library wiz… (compare)

  • Dec 20 2019 17:22

    manuseiffel on master

    Updated email interaction, adde… (compare)

  • Dec 20 2019 13:21

    manuseiffel on master

    Supported processing of a symbo… Updated code to handle Unicode … Added features for symbols used… and 5 more (compare)

  • Dec 20 2019 11:21

    manuseiffel on master

    Improved the insert symbol dial… Protected import operation from… Fixed to support extended ascii… (compare)

  • Dec 19 2019 13:21

    manuseiffel on master

    Taken type marks into account w… Cosmetics. git-svn-id: https:/… Fixed test#term218 by taking in… and 7 more (compare)

  • Dec 19 2019 11:21

    manuseiffel on master

    Improved the test to verify tha… Removed a redefinition that vio… Corrected test names that were … and 5 more (compare)

  • Dec 18 2019 21:21

    manuseiffel on master

    Changed expected result of test… Replaced "manifest array" with … (compare)

  • Dec 18 2019 17:21

    manuseiffel on master

    Renamed library wizard system n… (compare)

  • Dec 18 2019 13:01

    manuseiffel on master

    Updated to version 19.12 git-s… (compare)

  • Dec 17 2019 17:21

    manuseiffel on master

    Use either smtp or sendmail sol… (compare)

  • Dec 17 2019 11:21

    manuseiffel on master

    Updated to the most recent vers… (compare)

  • Dec 16 2019 18:21

    manuseiffel on master

    Removed tag "used_to_pass" from… (compare)

  • Dec 16 2019 10:21

    manuseiffel on master

    Fixed the hidden item dialog po… (compare)

  • Dec 13 2019 21:32

    manuseiffel on master

    Do not use the -safe.ecf direct… Added a new validity rule for d… Do not use the -safe.ecf direct… and 3 more (compare)

  • Dec 13 2019 20:21

    manuseiffel on master

    Improved handling of cloud serv… Do not use the -safe.ecf direct… (compare)

  • Dec 13 2019 16:21

    manuseiffel on master

    Now include cache date in block… For cloud API communication, us… (compare)

  • Dec 12 2019 18:21

    manuseiffel on master

    Added EIFFELORG variable to lin… Removed useless uuid in the red… Fixed typo git-svn-id: https:… (compare)

  • Dec 12 2019 12:21

    manuseiffel on master

    Added a command to set a prefer… Added a pretty-printer keyword … Supplied pretty-printer prefere… (compare)

Saša Janiška
@gour
just wonder if my inquiry on mailing list about Ada vs Eiffel is too strange..so that I haven't received any reply (I got a few on Ada group)...
Larry Rix
@ljr1981
I don't know Ada, so I don't know enough to reply. It may well be that this is the case for others in the community as well. Don't be discouraged. My guess is that the Ada folks are happy to provide all sorts of feedback even though they don't know Eiffel. It's a human thing to "defend" programming languages like a religion. :-)
Saša Janiška
@gour
@ljr1981 ok, let's hope we'll get some reply from the Eiffel side of the story :-)
still, some points do apply...this chat and mailing lists are very quiet...
kwaxer
@kwaxer
@gour From my personal view, Ada looks more heavy-weight and verbose. This is reasonable for thoroughly written and reviewed embedded code, but, maybe, not quite justified for everyday projects. The following language aspects may be used to make a decision:
  • object-oriented programming - is it needed or not? Ada object-oriented facilities are built on top of procedural programming, Eiffel is almost pure OOP.
  • garbage collection - do you plan to deal with memory management yourself or not? I could be wrong, but originally Ada was based on manual rather than automatic memory management, Eiffel relies on GC from the beginning.
  • concurrency - do you plan to use it? Both languages have built-in support, but the models are quire different.
  • derived types - are they essential? Ada provides means to build types by specifying ranges, etc. Eiffel is less capable in this area.
  • libraries - this might be important if you are looking for a specific functionality.
  • syntactic sugar - do you want it? Eiffel already has some syntactical simplifications, and in the coming versions there would be more (e.g., in the nearest future one could write ∀ x: list ¦ x > 0 to specify that all elements in the list are positive). Would it improve your code?
  • multiple inheritance - would you like to use it? As far as I understand, Ada has limited support for it, similar to Java interfaces, whereas in Eiffel there are no restrictions.
Saša Janiška
@gour
@kwaxer in regard complexity - yes, Ada looks as much more heavy-weight - something i really like with Eiffel...in regard to other items, i could do with procedural, oop and even somewhat fp. no, i don't like to do manual memory mgmt - one reason i eliminated C(++) from the very beginning. as far as concurrency is considered, i'm still too ignorant about it to be able to understand which one is advantageous. types in Ada is certainly great features. for libs, i believe that both cover basic needs. yes, that sugar would be nice, looks like list comprehensions in haskell :-) usually multiple-inheritance is considered problematic, but it looks that Eiffel does achieve a lot when it comes to re-use
Larry Rix
@ljr1981
image.png
@kwaxer @gour ... re: range types such as ...
(see above)
If that is a "typical" use of "ranges" in Ada, I am inclined to say that the structure of Eiffel across loops coupled with INTEGER_INTERVAL is preferable ...
Larry Rix
@ljr1981
image.png
The Eiffel code is simple and elegant IMNSHO :-)
re: OOP — I am not sure where Eiffel is not OOP and I love to see examples of it not being OO. I am unsure why one would opt for procedural code over OO designs, especially with the facilities of Generics and Multiple Inheritance so well oiled in Eiffel.
Larry Rix
@ljr1981
re: GC — having Eiffel handle memory management is a big deal. I suppose if you have something you want better control over you can write it in in-line C and handle the memory management yourself. In Eiffel you have choices. About 99.9% of the time, I have never found a need to live outside of the Eiffel GC box. About the only time we have mucked with it is to turn off garbage collection so it does not interfere with a particular routine, but then we turn it back on and force the GC cycle when we're ready.
re: Concurrency — if we were just talking multi-threading, I'd say one might have a toss-up between Eiffel and other languages. Once one brings SCOOP into the mix, Eiffel is superior.
re: Syntactical sugar — @kwaxer I agree that Eiffel is already really light weight. I do like that capacity for routine aliasing. The ones you mention that are coming in the next release of Eiffel Studio are more than interesting! I have found myself already wanting to use the new SET aliased features because they will clearly simplify the code and make it more readable. Having the appropriately aliased math symbols to lean on will make code much more readable and understandable. Yes, there will be the lazy gits that want the feature names with passed arguments, but it won't take long to get used to reading the more simplified SET alias calls. :-)
Larry Rix
@ljr1981
re: Multiple Inheritance — I find the reliance on this language and compiler facility to be indispensable! Once one gets used to having a powerful tool that is easy to use, one groans to go backwards into interfaces and templates.
Larry Rix
@ljr1981
re: Libraries — I saved this for last because it is the largest and most glaring downfall of Eiffel as a whole. The libraries available are not nearly as broad and rich as competitor language systems. It is immediately glaring to users of other languages who see Eiffel for the first time. When they realize how much work they have to do and how little is shared in the community in open source, it's a reasonable and glaring objection to using Eiffel. Many in the community have made outstanding contributions over the years, but as a community, we have not kept up nor held the required pace needed to stay competitive in the area. We need to do better. This is why I made a whole-heart attempt on the Eiffel Loop library to bring it into 19.05, Void-safety, and SCOOP compliance, but found it was just too far in the past with a huge amount of effort to bring forward. GOBO has done an excellent job of keeping pace with each new release of Eiffel Studio. Many of us are just "one-man-bands" with little time and money. The folks at Eiffel Software have been very kind and generous in this effort and I am praying for the day that I can let my AirBnB properties "self-care" (pay for their own labor) so I can focus a large portion of my days to writing libraries and documentation.
DISCLAIMER: Because of my experience with Eiffel, I have stopped shopping other language systems. My mind is fully made up. Call me a "convert" if you must and I suppose I wear that evangelical clothe. For me, there is nothing left to debate except for the matter of libraries. I know the folks at Eiffel Software are doing an outstanding job of keeping Eiffel Studio and its common libraries marching forward. I also know they are doing an outstanding job with the Eiffel Web Framework, which is moving along nicely as well. I just really wish we had a more concerted effort to band-together as a community and really address the gaping library holes.
Larry Rix
@ljr1981
FINALLY—looking over more of the Ada WikiBook with an eye on typing and "subtyping" (inheritance), I am seeing a mess. I won't bother reading very much of it because I see a lot of what I have come to call "juvenile notions"—that is—people with language compiler skills who have an "inspiration", who then code something up in their language thinking it is a "good idea" and never really consider the consequences of doing so. This is precisely where C went of the rails with its "Billion Dollar Mistake" that led to the need for so much research in Eiffel to create a compiler with Void Safety.
While undefined has been in existence since the creation of coding, null is the misguided invention of British computer scientist Tony Hoare (most famous for his Quicksort algorithm) in 1964, who coined his invention of null references as his “billion dollar mistake”.
Just because one can write a parser and compiler that can do something does not mean that it is ultimately a good idea. Eiffel is carefully thought out over many years by many people. It is one of the things I have come to trust about the brains behind. They are seasoned adults who consider the consequences of what they do and do not put in the Eiffel compiler.
Saša Janiška
@gour
@ljr1981 thanks a lot for that range example ;)
Saša Janiška
@gour
@ljr1981 very, very helpful input, indeed. thanks a million!! I must say that from the day one of my encounter with Eiffel i was very much attracted with its elegance, iow. being simple and powerful, something which i admire in my life always...that's why i believe that if i do my project it certainly won't be done in Ada, but most probably in Eiffel
in regard to libraries, i believe that for my project there is enough - sqlite3 bindings and 3rd party C library for which i need to write higher-level bindings. the rest should be custom libs written and for general GUI, let's hope that we can do it without Eifffel Loop since it is probably advisable to be able to use latest version of Studio...
kwaxer
@kwaxer
@gour I would really recommend using the latest version of EiffelStudio with void safety turned on from the beginning (this is the default when you create a project from scratch). It would require some efforts from your side -- all users experience some initial friction. However, it greatly pays off later because you never get "access on void target" exception (the famous Null pointer dereferencing). Together with automatic memory management this removes large portion of software bugs. You would still have to care about accesses to indexed structures like arrays or strings, but these are usually easy to catch by enabling assertion monitoring during the development phase.
Saša Janiška
@gour
@kwaxer i'm of the same opinion...if i wanted to fiddle with pointer/malloc/free, then i could stay with C(++) and look no further, but i want to have fun with this hobby project and not spent most of the time doing low-level debugging :-D
Larry Rix
@ljr1981
@gour ... re: range example — you are quite welcome! That Ada range code looks distressingly complex.
Saša Janiška
@gour
Do you consider Bertrand Meyer's Touch of Class a good to be used for learning/mastering Eiffel?
Javier Velilla
@jvelilla
@gour you can also check the EDX courses https://bit.ly/35MIEO5 and https://bit.ly/32uijmb
Javier Velilla
@jvelilla
@gour I forgot to mention the EiffelTutorial (https://bit.ly/35Qhwh9) and a list of videos based on it https://www.youtube.com/playlist?list=PLZpa6hoOqvrGOyPusA42dUzTQZ_WGMlPv done by @ljr1981
Larry Rix
@ljr1981
@gour ... Yes, ToC is an excellent book, but rather lengthy. There are plenty of quick resources as @jvelilla has pointed out that will get you going much faster.
Saša Janiška
@gour
@jvelilla that courses seems to be not available now?
i'll check the other two tutorials...
Larry Rix
@ljr1981
@gour , did the tutorials help you?
Saša Janiška
@gour
@ljr1981 i only skimmed those (lack of time), but i like them...your one is nice!
Larry Rix
@ljr1981
none of the www.eiffel.org pages are being returned ...
image.png
FYI
Howard Thomson
@howardthomson
Hi. I have just unpacked EiffelStudio 19.05 and attempted to compile a current project, which resulted in a mismatched UUID error VD00. Is moving to 19.09 likely to fix this, otherwise what needs to change ?
Eiffel-19.05-error-Screenshot at 2019-12-11 23-57-33.png
Jocelyn Fiat
@jocelyn
To fix on your machine, remove the UUID in the redirection.
This issue was fixed, I don't remember in which beta release.
You can also include the target directly.
Howard Thomson
@howardthomson
How is it possible [EiffelStudio 19.10] for a class KL_BINARY_INPUT_FILE [and others] to appear in the 'Groups' pane, but still get VTCT errors about the class being 'Unknown' ? I have removed EIFGENs and recompiled, with the same result. It looks as if I will have to review the Project file manually ...
kwaxer
@kwaxer
Does corresponding Gobo library appear in the target where the class with VTCT is located?
Howard Thomson
@howardthomson
Well, I added gobo [gobo_all.ecf] as a dependency to the Group to which the VTCT class belonged. No difference.
Jocelyn Fiat
@jocelyn
gobo_all.ecf includes all gobo lib (as sub lib og gobo_all) , but it is not included directly in the project (i.e visible to app clusters).
I would suggest to include directly the gobo_kernel.ecf in your app (or in the lib you want your classes to have access to KL_BINARY_INPUT_FILE )
(note if you use gelex and geyacc, now you need to include in addition to usual lib, the new gobo_lexical_skl.ecf
Gobo Eiffel splitted the gelex lib)
Saša Janiška
@gour
i've installed 19.12-GPL, but after launching estudio cmd, I only see a splash for a short time and then it quits. any idea?