tecomp-user Mailing List for tecomp: The Eiffel Compiler
Status: Beta
Brought to you by:
helmut_brandl
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(12) |
Oct
|
Nov
(2) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(17) |
Feb
(9) |
Mar
(6) |
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(11) |
Dec
(1) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Helmut B. <hel...@gm...> - 2011-03-14 19:19:13
|
A draft description of Modern Eiffel is online now. The key features: - Integration of functional and imperative programming into one language (in a similar manner as scala) - Variable and routines with limited scope - Richer types (e.g. immutable types) and type inference - Completely type safe - Assertions can be statically verified - Powerful concurrency http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/modern_eiffel.txt |
From: Helmut B. <hel...@gm...> - 2010-10-10 22:18:25
|
= Version 0.24 (r464 10.10.2010) = == New features == === Simplified void safety syntax implemented === A simplified syntax for void safety has been implemented which replaces the more verbose old syntax exp: detachable E anc_exp: detachable E_ANCESTOR -- conformant -- old syntax check attached exp as x then x.some_feature end check attached {E} anc_exp as x then x.some_feature end -- new syntax exp.attached.some_feature anc_exp.attached{E}.some_feature If `exp' is not attached to an object or `anc_exp' is not attached to an object of type E, an exception is thrown, i.e. the semantics is the same as with the old syntax, the syntax is more concise. For more details see the white paper at [[http://tecomp.sourceforge.net]] -> white papers -> language discussion -> improved void safety. |
From: Helmut B. <hel...@gm...> - 2010-10-05 15:37:27
|
= Main features of Eiffel = The main features of Eiffel are: - clean object orientation with multiple inheritance - design by contract - elegant expressive syntax - automatic memory management - generics - uniform type system with type safety (exept catcalls) These features were unique at the time Eiffel was invented (some 25 years ago). Since that time a lot has happened in the world of programming languages. C++, java, C# and scala (just to mention the most prominent and successful ones) have entered the scene. The most recent one -- scala -- has nearly all key features of Eiffel except design by contract. But scala in its current form offers much more than Eiffel. It has type inference, strong support for functional programming, support for small scripts and large programs, complete type safety, concurrency etc. In short, Eiffel has lost the lead. Looking back the past 25 years since its invention, some improvements have been made: Syntax improvements, agents, non conforming inheritance, void safety etc. But even if one tries to see it in a positive manner, this is not that much. But Eiffel has still potential. In order to gain impact, an effort is needed to modernize Eiffel. The key feature design by contract is still unreached by other languages and opens the way for static verification. But the other key features supported by other languages must be introduced into Eiffel as well (a programmer using the advantages of type inference and functional programming of scala will never switch to Eiffel unless Eiffel offers at least the same and some other interesting features). = Vision for a modern Eiffel = - Much more support for functional programming (Assertions can use only the functional sublanguage of Eiffel. In order to make assertions more powerful, functional programming has to be supported significantly better). - Static verification of assertions - Static verification of void safety (i.e. real void safety) - Type safety: There shall be no possibility to generate type errors at runtime (catcalls). - Concurrency has to be integrated into the language. Scoop in its current form is not sufficient (too simplistic). Static verification needs to be able to prove that a program is free of deadlocks. - Block scoping of variables: If a variable is only needed within a certain block of a routine, it shall be declared, initialized and used only there. - support for immutable strings and immutable types - Type inference: Redundant type annotations shall not be necessary - Close the gap between scripting languages and compiled languages. - Community driven (i.e. free and open) |
From: Helmut B. <hel...@gm...> - 2010-09-17 20:12:18
|
== Incompatible changes == - The keyword `assertions' has been renamed to `assertion' in order to be compatible with the usual style (`feature' and not `features', `cluster' and not `clusters', etc.). == New features == === Gnu build system introduced === The Eiffel compiler is now built with the GNU build system in order to be more robust for different environments. Therefore the building and installing of tecomp is now different. Please read "doc/tecomp/installation.txt" to build tecomp. === Compilier binary and standard libraries are now installed === The Eiffel compiler will be installed by `make install'. The location can be chosen by `configure'. The default location is `/usr/local/bin'. The libraries which come with `tecomp' will be installed (default location `usr/local/lib/eiffel', but location can be configured with `configure --prefix=xxxx') and tecomp is preconfigured to search for the libraries at the proper location. The kernel library is now implicitely included. === New cluster concept implemented === The new cluster concept described in the white paper at [[http://tecomp.sourceforge.net]] -> white papers -> language discussion has been implemented. It restricts visibility of classes and allows resolution of class name clashes. An introduction to the new concept including the simplification of the ace files can be found on [[http://tecomp.sourceforge.net]] -> tecomp -> ace file as well. With the new cluster concept, libraries can have their own ace file describing all needed other libraries. The Eiffel classes uses by a library are not visible within the main program (unless explicitly mentioned there). Each library has an own view of the classes. Duplicate class names are possible as long as there is only one class with the same name in a view. A rename facility to avoid the remaining name clashes has been introduced. === Small Eiffel programs simplified significantly === Small Eiffel programs don't need an ace file any more. All classes needed by the program can be included in one main eiffel file. The root class is not necessary any more, only the root procedure. In the main Eiffel file a standard unix method of #! /usr/bin/env tecomp as first line can be added to make the file executable (don't forget the chmod!!). With that the smallest executable Eiffel program looks like #! /usr/bin/env tecomp do print("Hello world.%N") end The main eiffel file has the syntax Main_eiffel_file: [Ace_section] {Eiffel_class ... }+ Eiffel_class: Normal_eiffel_class | Implicit_root_class Normal_eiffel_class: "class" ... "end" Implicit_root_class: ["feature" ... "end"] ["local" ...] "do" Compound "end" Rule: Only one implicit root class is possible === Kernel library === - kernel library: added {FILE}.remove to delete a file == Bugfixes == - overriding of a deferred feature by an effective feature inherited from different parents now correct == Others == - reintroduced {SPECIAL}.make_empty for compatibility with EiffelStudio |
From: Helmut B. <hel...@gm...> - 2010-07-07 18:47:32
|
The following paper describes a proof engine for the Eiffel language. The proof engine allows the verification of the assertions of Eiffel code. Some language extensions are introduced to express proofs of assertions. Within the proofs the user can enter proof commands and the proof engine can verify the correct use of the proof commands. Modularization techniques are introduced to the keep the proofs small and expressive. The proof engine has some improved features to do the burdensome work for the user. It is expected that the developer enters the key assertions and proves them and the proof engine can verify the routines using the key assertions. - In the first chapter the basic concepts are explained. - The second chapter introduces the commands of the proof engine. - The third chapter shows how basic properties of boolean expression can be proved with the proof engine. - The forth chapter applies the proof engine to assertions within the class INTEGER - The fifth chapter shows how routines can be proved. Find the detailed paper at http://tecomp.sourceforge.net -> white papers -> verification -> proof engine |
From: Helmut B. <hel...@gm...> - 2010-04-27 00:56:59
|
== New features == - inherited contracts implemented (effective classes can inherit the pre- and postconditions from its abstract/deferred parent). - assertion monitoring can be set for specific classes individually - ABSTRACT_SEQUENCE introduced and used as an ancestor of SPECIAL - Precursor construct implemented - Monitoring of supplier preconditions possible: > This feature is important if well tested and proven libraries are used. In that case, assertion monitoring is normally switched off for the library. But if a class using that library is in a cluster with monitoring on (i.e. assertions(all)), then preconditions of called routines of the library are still checked. == Bugfixes == - Wrong line numbers were printed if unqualified calls are not unique because of replication. - Crash, if a replicated feature has been redeclared in the current class. |
From: Helmut B. <hel...@gm...> - 2009-12-22 00:50:58
|
http://tecomp.sourceforge.net -> tecomp -> history http://www.sourceforge.net/projects/tecomp -> download == New features == - HASHABLE available in library/kernel - all INTEGERs, NATURALs and STRINGs are HASHABLE - INTEGER_GENERAL available in library/kernel which is a common ancestor to all INTEGER_xx and NATURAL_xx classes - Constraint creators implemented, i.e. class CG[G->CONSTRAINT create cp1, cp2, ... end] now possible. A formal generic with "G -> CONSTRAINT create default_create end" is self initializing. - New syntax for object test available (replaces the old syntax {var:T} expr) - attached expr - attached {T} expr - attached expr as var - attached {T} expr as var - check attached expr as var then var.some_feature end - ARRAY and SPECIAL now completely void safe (features which are not void safe like make(lower, upper), force etc. removed). - ARRAY does automatic resize in extend_rear and extend_front == Bugfixes == - Tecomp did not work well on SPARC machines due to an alignment bug. - Formal arguments and local variables are not allowed to shadow attributes. This rule is valid in the defining class only. A descendant can introduce attributes with the same name as local variables and formal arguments of inherited features. The latter is not invalid. - Validity: creation procedure rule 8.20.3 now fully checked (no unqualified calls and no Current in the precondition of a creation procedure) - bugfix in validator/variable_tracker: empty else branch not handled correctly during checking the proper initialization of local variables. |
From: Helmut B. <hel...@gm...> - 2009-11-27 03:05:46
|
Wolfgang Jansen wrote: >> > Thanks, now tecomp works fine. Thank you very much for your assistance. Your problem report has been very good and straight to the point. Feel free to post anything related to Eiffel or tecomp or the documentation on the website in this mailing list or on the forums. Any feedback is welcome. Helmut |
From: Wolfgang J. <wj...@so...> - 2009-11-26 12:07:30
|
Helmut Brandl wrote: > Thanks for executing the test. So we have definitely a bug with > alignment in seq_arr_intern_t which causes fatal errors on a SPARC > machine and not on some other machines. > > I fixed the bug in the file cal/src/container/seq_arr_intern.h. Please > find attached the corrected file. > > To apply the fix just copy the file to its proper place and issue > > make tecomp # or make atecomp > > from the tecomp directory. > > Regards > Helmut > > > Thanks, now tecomp works fine. WJ -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Helmut B. <hel...@gm...> - 2009-11-26 02:41:07
|
Thanks for executing the test. So we have definitely a bug with alignment in seq_arr_intern_t which causes fatal errors on a SPARC machine and not on some other machines. I fixed the bug in the file cal/src/container/seq_arr_intern.h. Please find attached the corrected file. To apply the fix just copy the file to its proper place and issue make tecomp # or make atecomp from the tecomp directory. Regards Helmut Wolfgang Jansen wrote: >> > Well this was easily done. I obtained: > 1) should_crash_on_sparc.c: > sizeof(int) = 4, sizeof(long long) = 8 > array = 20a18, array+1 = 20a1c > Bus error > > 2) test_alignment.c: > sizeof(values_t) = 12 > sizeof(aligned_t) = 16 > (char*)(array+1) - (char*)array = 16 > > 3) test_sequence_arrayed.cpp: > test_seq_arr_intern 0 test(s) executed > gmake: *** [exec] Bus Error > > So, the programs failed as you expected. > > WJ > |
From: Helmut B. <hel...@gm...> - 2009-11-25 15:18:03
|
Thank you Wolfgang. I think I know what went wrong. The SPARC HW has pretty strong alignment requirements. I am quite sure that I have respected alignment quite well. But in the class seq_arr_t I have obviously not respected alignment. The array header is 12 bytes long and the elements start at base+12. And this is wrong, if the elements have wordsize (e.g. 64 bit integers). The bug is relatively easy to fix. But before providing a fix, I would prefer to verify my assumption about the bug. I have written a tiny test program "should_crash_on_sparc.c" which does not crash on my 64 and 32 bit machines, but it should crash on SPARC. It is in plain C to avoid any complications. The tests in cal/test/container pass, because the test cases do not use containers with 64 bit elements. If you replace "cal/test/container/test_sequence_arrayed.cpp" with the corresponding file in the attachment, "make test" should fail as well on your machine. In order to verify the fix I am planning to do, I have included the tiny C program "test_alignment.c". Could you please send me the output of that program? If I am right, I can provide a fix very fast. Regards Helmut Wolfgang Jansen wrote: > Helmut Brandl wrote: >> Thanks for the stacktrace. I am not yet sure what is going on here. >> Obviously the "count" method of seq_arr_inter_t returns a completely >> screwed up value. This is strange, because your stacktrace says, that >> the attribute "cnt" has the meaningful value "1", and the "count" method >> just calls then "count" method of seq_arr_intern_t which just returns >> the value of the attribute "cnt". >> >> If you run your compiled system in gdb, you could see, what count() and >> p->count() return at the location of the segfault. And you can see the >> pointer values of p and p->last(). The 2 pointers should be just a >> couple of bytes apart. >> >> > Here the values: > > count() = 1 > p->count() = 1 > *p->last() = 0 > > p = 0x275590 > &(p->cap) = 0x275598 > p->last() = 0x27559c > > The values sound meaningful. Many 0 bytes follow after p->last(). >> Some other remarks: >> >> There is no need to change the compiler flags. If you issue >> >> make atecomp >> >> you get a compiler named atecomp in gen_dir/bin which has all debugging >> facilities and all assertions in the compiler enabled. I don't know what >> you did exactly. But better use atecomp for debugging (then I know >> better what you have done and can compare it with the results on my >> machine). The advantage of atecomp is that it is heavily asserted and >> might throw an assertion which give us a better hint on what is going on >> there. >> >> If you edited some CFLAGS please restore the original values and use >> atecomp instead. And before any recompilation, delete all files in >> gen_dir/obj. >> >> > Done. >> There are some lower level tests. E.g. >> >> cd cal/test/container >> make test >> >> tests all the used containers in tecomp. If this test fails, debugging >> is easier. >> >> > I did so and obtained > > test_seq_arr_intern 0 test(s) executed > test_sequence_arrayed 1 test(s) executed > test_set_arrayed 2 test(s) executed > test_string 1 test(s) executed > test_packed_bits 1 test(s) executed > > without crash. > > WJ |
From: Helmut B. <hel...@gm...> - 2009-11-24 15:13:50
|
Wolfgang Jansen wrote: > Hello Helmut, > > thanks for the hint: adding a blank after all occurrences > of '-o' fixed the bug. > (BTW, for 20 years I have applied the '-o' option with a blank > running very different C compilers. To my knowledge, the blank > is forbidden only in case of the '-I' and '-L' options.) Ok, I have already changed the svn repository. So in the next release tecomp will have a blank between the -o option and the filename. > > To the bigendian question: > yes, I'm working an a bigendian Sun/sparc platform > and, yes, the compiler does immediately crash. > (sorry, for the bad news). > To see what happens, I re-compiled the stuff with > '-g' and '-O0' options and run the compiler under 'gdb'. Thanks for the stacktrace. I am not yet sure what is going on here. Obviously the "count" method of seq_arr_inter_t returns a completely screwed up value. This is strange, because your stacktrace says, that the attribute "cnt" has the meaningful value "1", and the "count" method just calls then "count" method of seq_arr_intern_t which just returns the value of the attribute "cnt". If you run your compiled system in gdb, you could see, what count() and p->count() return at the location of the segfault. And you can see the pointer values of p and p->last(). The 2 pointers should be just a couple of bytes apart. Some other remarks: There is no need to change the compiler flags. If you issue make atecomp you get a compiler named atecomp in gen_dir/bin which has all debugging facilities and all assertions in the compiler enabled. I don't know what you did exactly. But better use atecomp for debugging (then I know better what you have done and can compare it with the results on my machine). The advantage of atecomp is that it is heavily asserted and might throw an assertion which give us a better hint on what is going on there. If you edited some CFLAGS please restore the original values and use atecomp instead. And before any recompilation, delete all files in gen_dir/obj. There are some lower level tests. E.g. cd cal/test/container make test tests all the used containers in tecomp. If this test fails, debugging is easier. Regards Helmut > The crash message, the stack trace, and the values > of some variables are: > > Program received signal SIGSEGV, Segmentation fault. > 0x000aa684 in eiffel_parse () at sequence_arrayed.h:748 > 748 new (p->last()) T(e); > > #0 0x00173bc8 in sequence_arrayed_t<unsigned long long>::extend_rear ( > this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:748 > #1 0x001789bc in sequence_arrayed_t<unsigned long long>::force_rear ( > this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:760 > #2 0x0019c9a4 in numeric_constants_t::force_rear (this=0x256d6c, val=0) > at class.h:265 > #3 0x000dc438 in eiffel_parse () at eiffel.y:3716 > #4 0x000de330 in parse_eiffel_file (f=0x254e68, cls_to_parse=0x256d40, > f_name=0x25d434 "./fahr_celsius.e", col=0x254810) at eiffel.y:4275 > #5 0x000cdea0 in eiffel_system_t::parse_system (this=0x254810) > at eiffel_system.cpp:239 > #6 0x0009be54 in main (argc=2, argv=0xffbfdf4c) at tecomp.cpp:188 > > p = {el_sz = 8, el_sz_al = 8, cnt = 1, cap = 10} > e = 0 > c0 = 1068848469 = 0x3fb55555 > *(float*)&c0 = 1.41666663 > *(double*)&c0 = 0.083333333333333329 > > I'm sure that assigning of 'c0' did work correctly, > but I don't have any idea where the first error is. > > WJ > |
From: Wolfgang J. <wj...@so...> - 2009-11-24 11:34:06
|
tec...@li... wrote: > Message: 4 > Date: Mon, 23 Nov 2009 18:21:57 +0100 > From: Wolfgang Jansen <wj...@so...> > Subject: [Tecomp-user] Installation problem > To: tec...@li... > Message-ID: <4B0...@so...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > today I downloaded Tecomp (version 0.20) for the first time > and tried to instal it at a Sun/Solaris platform. > 'gmake' issues soon the message > > g++ -O3 -Wall -DCY_ASSERTIONLEVEL_NO -I../tools > -I../../cal/src/general -I../../cal/src/container \ > -c -o../../gen_dir/obj/feature_name_o.o feature_name.cpp > /usr/ccs/bin/as: error: no input filename given > usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] > [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] > [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] > [-m [-Ym,path]] [-n] [-ul] [-xF] > [-m32] [-m64] > > [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis, > sparcvis2,sparcfmaf,sparcima}] > [-xcode={pic13,pic32}] file.s... > gmake[2]: *** [../../gen_dir/obj/feature_name_o.o] Error 1 > > As I understand the message, the bug is with the "-o" option not > separated by white space from its parameter. > I did not find any related command in the various 'makefile's . > So, what can I do? > > With regards > Wolfgang Jansen > > Hello Helmut, thanks for the hint: adding a blank after all occurrences of '-o' fixed the bug. (BTW, for 20 years I have applied the '-o' option with a blank running very different C compilers. To my knowledge, the blank is forbidden only in case of the '-I' and '-L' options.) To the bigendian question: yes, I'm working an a bigendian Sun/sparc platform and, yes, the compiler does immediately crash. (sorry, for the bad news). To see what happens, I re-compiled the stuff with '-g' and '-O0' options and run the compiler under 'gdb'. The crash message, the stack trace, and the values of some variables are: Program received signal SIGSEGV, Segmentation fault. 0x000aa684 in eiffel_parse () at sequence_arrayed.h:748 748 new (p->last()) T(e); #0 0x00173bc8 in sequence_arrayed_t<unsigned long long>::extend_rear ( this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:748 #1 0x001789bc in sequence_arrayed_t<unsigned long long>::force_rear ( this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:760 #2 0x0019c9a4 in numeric_constants_t::force_rear (this=0x256d6c, val=0) at class.h:265 #3 0x000dc438 in eiffel_parse () at eiffel.y:3716 #4 0x000de330 in parse_eiffel_file (f=0x254e68, cls_to_parse=0x256d40, f_name=0x25d434 "./fahr_celsius.e", col=0x254810) at eiffel.y:4275 #5 0x000cdea0 in eiffel_system_t::parse_system (this=0x254810) at eiffel_system.cpp:239 #6 0x0009be54 in main (argc=2, argv=0xffbfdf4c) at tecomp.cpp:188 p = {el_sz = 8, el_sz_al = 8, cnt = 1, cap = 10} e = 0 c0 = 1068848469 = 0x3fb55555 *(float*)&c0 = 1.41666663 *(double*)&c0 = 0.083333333333333329 I'm sure that assigning of 'c0' did work correctly, but I don't have any idea where the first error is. WJ -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Helmut B. <hel...@gm...> - 2009-11-23 17:58:15
|
Wolfgang, if the mailing list allows attachments, you can find an updated file rules.mk as an attachment. If not, I could send you the file directly. It seems that gcc accepts a blank between the -o option and the filename. Helmut Helmut Brandl wrote: > Hello Wolfgang, > > there is a directory cal/build which contains some common includes to > the makefiles. The used include file which causes the problem is > probably rules.mk. > > You could try to insert a blank between the -o and the filename in the > corresponding rules (there is more than one rule). In the meantime, I > will try to check, if my unix will accept the blank (I was thinking that > a blank is *not* allowed here). > > If the blank is accepted, I will include an updated version in the next > release. > > Please give feedback, if the insertion of blanks resolves the problem. > > By the way: Does your Sun/Solaris have a SPARC processor (i.e. a big > endian processor). Up to now I have only been able to test tecomp on > little endian machines like the Intel with various OSes. Tecomp is > designed to work on big endian machines as well. However an explicit > test would be very valuable. > > Kind regards > Helmut > > > Wolfgang Jansen wrote: >> Hello, >> >> today I downloaded Tecomp (version 0.20) for the first time >> and tried to instal it at a Sun/Solaris platform. >> 'gmake' issues soon the message >> >> g++ -O3 -Wall -DCY_ASSERTIONLEVEL_NO -I../tools >> -I../../cal/src/general -I../../cal/src/container \ >> -c -o../../gen_dir/obj/feature_name_o.o feature_name.cpp >> /usr/ccs/bin/as: error: no input filename given >> usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] >> [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] >> [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] >> [-m [-Ym,path]] [-n] [-ul] [-xF] >> [-m32] [-m64] >> >> [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis, >> sparcvis2,sparcfmaf,sparcima}] >> [-xcode={pic13,pic32}] file.s... >> gmake[2]: *** [../../gen_dir/obj/feature_name_o.o] Error 1 >> >> As I understand the message, the bug is with the "-o" option not >> separated by white space from its parameter. >> I did not find any related command in the various 'makefile's . >> So, what can I do? >> >> With regards >> Wolfgang Jansen >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > https://lists.sourceforge.net/lists/listinfo/tecomp-user > |
From: Wolfgang J. <wj...@so...> - 2009-11-23 17:52:12
|
Hello, maybe you get the message a second time (I apologize if so). Today I downloaded Tecomp (version 0.20) for the first time and tried to instal it at a Sun/Solaris platform. 'gmake' issues soon the message: g++ -O3 -Wall -DCY_ASSERTIONLEVEL_NO -I../tools -I../../cal/src/general -I../../cal/src/container \ -c -o../../gen_dir/obj/feature_name_o.o feature_name.cpp /usr/ccs/bin/as: error: no input filename given usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] [-m [-Ym,path]] [-n] [-ul] [-xF] [-m32] [-m64] [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis, sparcvis2,sparcfmaf,sparcima}] [-xcode={pic13,pic32}] file.s... gmake[2]: *** [../../gen_dir/obj/feature_name_o.o] Error 1 As I understand the message, the bug is the "-o" option not separated by white space from its parameter. I did not find any related command in the various 'makefile's . So, what can I do? With regards Wolfgang Jansen -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Helmut B. <hel...@gm...> - 2009-11-23 17:49:44
|
Hello Wolfgang, there is a directory cal/build which contains some common includes to the makefiles. The used include file which causes the problem is probably rules.mk. You could try to insert a blank between the -o and the filename in the corresponding rules (there is more than one rule). In the meantime, I will try to check, if my unix will accept the blank (I was thinking that a blank is *not* allowed here). If the blank is accepted, I will include an updated version in the next release. Please give feedback, if the insertion of blanks resolves the problem. By the way: Does your Sun/Solaris have a SPARC processor (i.e. a big endian processor). Up to now I have only been able to test tecomp on little endian machines like the Intel with various OSes. Tecomp is designed to work on big endian machines as well. However an explicit test would be very valuable. Kind regards Helmut Wolfgang Jansen wrote: > Hello, > > today I downloaded Tecomp (version 0.20) for the first time > and tried to instal it at a Sun/Solaris platform. > 'gmake' issues soon the message > > g++ -O3 -Wall -DCY_ASSERTIONLEVEL_NO -I../tools > -I../../cal/src/general -I../../cal/src/container \ > -c -o../../gen_dir/obj/feature_name_o.o feature_name.cpp > /usr/ccs/bin/as: error: no input filename given > usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] > [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] > [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] > [-m [-Ym,path]] [-n] [-ul] [-xF] > [-m32] [-m64] > > [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis, > sparcvis2,sparcfmaf,sparcima}] > [-xcode={pic13,pic32}] file.s... > gmake[2]: *** [../../gen_dir/obj/feature_name_o.o] Error 1 > > As I understand the message, the bug is with the "-o" option not > separated by white space from its parameter. > I did not find any related command in the various 'makefile's . > So, what can I do? > > With regards > Wolfgang Jansen > |
From: Wolfgang J. <wj...@so...> - 2009-11-23 17:22:10
|
Hello, today I downloaded Tecomp (version 0.20) for the first time and tried to instal it at a Sun/Solaris platform. 'gmake' issues soon the message g++ -O3 -Wall -DCY_ASSERTIONLEVEL_NO -I../tools -I../../cal/src/general -I../../cal/src/container \ -c -o../../gen_dir/obj/feature_name_o.o feature_name.cpp /usr/ccs/bin/as: error: no input filename given usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] [-m [-Ym,path]] [-n] [-ul] [-xF] [-m32] [-m64] [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis, sparcvis2,sparcfmaf,sparcima}] [-xcode={pic13,pic32}] file.s... gmake[2]: *** [../../gen_dir/obj/feature_name_o.o] Error 1 As I understand the message, the bug is with the "-o" option not separated by white space from its parameter. I did not find any related command in the various 'makefile's . So, what can I do? With regards Wolfgang Jansen -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Helmut B. <hel...@gm...> - 2009-11-06 17:19:26
|
http://tecomp.sourceforge.net http://www.sourceforge.net/projects/tecomp == Bugfixes and improvements == - All type combinations in equality test ("=" and "~") shall now work properly. - Deep features now work for all types without any exceptions. - The garbage collector has been reworked completely. Before, expandeds which contained references could create memory leaks. Now all temporaries which are references or contain references into the heap are registered. Therefore no live object (i.e. reachable directly or indirectly) can be reclaimed by the garbage collector. - Bug: In some cases a conversion procedure did not work properly. All cases with reference types went well. However conversion from or to expanded types where the entity size of the source type is different from that of the target type did not work well. - Bug: Nested exceptions (raised exception within exception handling) created problems, if the exception handler is the direct receiver of the original exception and the second exception. - Virtual machine on big endian and little endian machines: Some operations had not been designed properly to work on big and little endian machines. The virtual machine has been reworked to be insensitive to the endianness of the machine. |
From: Helmut B. <hel...@gm...> - 2009-09-10 16:18:20
|
== New features == - added feature {ANY}.generator which returns a string representation of the generating type of the current object. == Bugfixes == - target conversion was not working well within nested expression - non existing but used feature could result in a segfault, if used in binary expressions - a failed object test could overwrite temporary variables on the stack - infinite recursion within assertions has not been broken in all circumstances - profiling under windows/mingw was not possible - TUPLEs were treated erroneously as self-initializing |
From: Helmut B. <hel...@gm...> - 2009-09-10 15:12:09
|
Hello Jörgen, I have fixed the problem in the svn repository. The fix will be included in the next release. If you want to get the fix fast, just checkout the latest svn snapshot (>= r223). Regards Helmut Helmut Brandl wrote: > > -------- Original Message -------- > Subject: Re: tecomp, MATRIX class > Date: Tue, 08 Sep 2009 16:33:23 -0500 > From: Helmut Brandl <hel...@gm...> > To: Jörgen Tegnér <jor...@te...> > References: <125...@bu...> > <4AA...@gm...> > <125...@bu...> > > Thanks for the detailed report. > > I have reproduced the problem. There is definitely a problem in the out > feature and in the internal calculation. > > I hope I can provide a fix soon. > > By the way. I have recently restructured the web presentation of tecomp. > In that process the hint to the mailing list has been lost. I have > invited you to the mailing list and will put the hint to the mailing > list back to the web pages in order to make it easier to give feedback > and report bugs. > > Helmut > > Jörgen Tegnér wrote: >> On Tue, 2009-09-08 at 08:27 -0500, Helmut Brandl wrote: >>> Hello Jörgen, >>> >>> could you give me more details: >>> >>> - which version of tecomp did you use (tecomp -v outputs the version)? >>> >>> - what irregularity did you see exactly? >>> >>> - are you on a 32bit or 64bit system? >>> >>> The best would be to include some code into examples/test_complex.e and >>> examples/complex.e which reproduces the error via a failed assertion in >>> test_complex.e. >>> >> Hi, apologies for the unclear report. >> >> tecomp/examples$ ../gen_dir/bin/tecomp -v >> tecomp version: 0.18.1 >> >> Running on a 32 bit computer. >> >> tecomp/examples$ ../gen_dir/bin/tecomp test_complex2.ace >> a = [1,0] >> b = [0,1] >> c = [0,-1] >> d=a+b = [1,1] >> e=-d = [-1,-1] >> f=e.conj = [-1,1.08213e+09] >> >> The imaginary part of f should be 1, but is garbled. Depending on how >> the negation is done in COMPLEX.conj the result is either correct (1) or >> garbled as above. >> >> The files test_complex2.ace, test_complex2.e and complex.e are attached. >> >> /Jörgen >> >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > https://lists.sourceforge.net/lists/listinfo/tecomp-user > |
From: Helmut B. <hel...@gm...> - 2009-09-10 15:09:35
|
-------- Original Message -------- Subject: Re: tecomp, MATRIX class Date: Tue, 08 Sep 2009 16:33:23 -0500 From: Helmut Brandl <hel...@gm...> To: Jörgen Tegnér <jor...@te...> References: <125...@bu...> <4AA...@gm...> <125...@bu...> Thanks for the detailed report. I have reproduced the problem. There is definitely a problem in the out feature and in the internal calculation. I hope I can provide a fix soon. By the way. I have recently restructured the web presentation of tecomp. In that process the hint to the mailing list has been lost. I have invited you to the mailing list and will put the hint to the mailing list back to the web pages in order to make it easier to give feedback and report bugs. Helmut Jörgen Tegnér wrote: > On Tue, 2009-09-08 at 08:27 -0500, Helmut Brandl wrote: >> Hello Jörgen, >> >> could you give me more details: >> >> - which version of tecomp did you use (tecomp -v outputs the version)? >> >> - what irregularity did you see exactly? >> >> - are you on a 32bit or 64bit system? >> >> The best would be to include some code into examples/test_complex.e and >> examples/complex.e which reproduces the error via a failed assertion in >> test_complex.e. >> > > Hi, apologies for the unclear report. > > tecomp/examples$ ../gen_dir/bin/tecomp -v > tecomp version: 0.18.1 > > Running on a 32 bit computer. > > tecomp/examples$ ../gen_dir/bin/tecomp test_complex2.ace > a = [1,0] > b = [0,1] > c = [0,-1] > d=a+b = [1,1] > e=-d = [-1,-1] > f=e.conj = [-1,1.08213e+09] > > The imaginary part of f should be 1, but is garbled. Depending on how > the negation is done in COMPLEX.conj the result is either correct (1) or > garbled as above. > > The files test_complex2.ace, test_complex2.e and complex.e are attached. > > /Jörgen > > > |
From: Helmut B. <hel...@gm...> - 2009-09-10 15:08:19
|
-------- Original Message -------- Subject: Re: tecomp, MATRIX class Date: Tue, 08 Sep 2009 17:11:13 +0200 From: Jörgen Tegnér <jor...@te...> To: Helmut Brandl <hel...@gm...> References: <125...@bu...> <4AA...@gm...> On Tue, 2009-09-08 at 08:27 -0500, Helmut Brandl wrote: > Hello Jörgen, > > could you give me more details: > > - which version of tecomp did you use (tecomp -v outputs the version)? > > - what irregularity did you see exactly? > > - are you on a 32bit or 64bit system? > > The best would be to include some code into examples/test_complex.e and > examples/complex.e which reproduces the error via a failed assertion in > test_complex.e. > Hi, apologies for the unclear report. tecomp/examples$ ../gen_dir/bin/tecomp -v tecomp version: 0.18.1 Running on a 32 bit computer. tecomp/examples$ ../gen_dir/bin/tecomp test_complex2.ace a = [1,0] b = [0,1] c = [0,-1] d=a+b = [1,1] e=-d = [-1,-1] f=e.conj = [-1,1.08213e+09] The imaginary part of f should be 1, but is garbled. Depending on how the negation is done in COMPLEX.conj the result is either correct (1) or garbled as above. The files test_complex2.ace, test_complex2.e and complex.e are attached. /Jörgen |
From: Helmut B. <hel...@gm...> - 2009-09-10 15:07:43
|
-------- Original Message -------- Subject: tecomp, MATRIX class Date: Sat, 05 Sep 2009 11:11:43 +0200 From: Jörgen Tegnér <jor...@te...> To: hel...@gm... Hi, yesterday I downloaded and tinkered with tecomp again. Nice job! A short example with COMPLEX shows an error though, either in my code or in the interpreter, regarding conversion of basic types. /Jörgen (I got your adress from a posting on comp.lang.eiffel as I couldn't find any contact info on the tecomp site.) Example: conjugate,conj:like Current local r,i: REAL do r := Current.real -- i := -Current.imag --The following line doesn't give the same results as the first --or last i := -1*Current.imag --Change to -1.0 and all's well -- i := Current.imag.negated create Result.make(r,i) end |
From: Helmut B. <hel...@gm...> - 2009-06-08 04:50:37
|
Version 0.18.1 fixes a bug of version 0.18. Version 0.18 introduced target conversion and with that a bug which bypassed validity checks with binary operators. Therefore invalid code could enter the runtime and crash it. |
From: Helmut B. <hel...@gm...> - 2009-06-03 03:11:22
|
The new release includes - target conversion - self initializing types - some new features in the kernel library classes ARRAY, SPECIAL and STRING |