tecomp-user Mailing List for tecomp: The Eiffel Compiler (Page 2)
Status: Beta
Brought to you by:
helmut_brandl
Menu
▾
▴
tecomp-user — Mailing list for "The Eiffel Compiler" tecomp
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...> - 2009-05-07 23:05:04
|
New features: - attributes can be initialized automatically (using the attribute keyword) - manifest arrays implemented ( e.g. <<1,2,3,4>> ) - notes added (using the "note" keyword) Some bugfixes. Details: http://tecomp.sourceforge.net -> The Eiffel Compiler -> History |
|
From: Helmut B. <hel...@gm...> - 2009-04-27 14:36:32
|
... with the following new features: - Underscore now allowed to improve the readability of integer constants (e.g. 2_100_095). Grouping of 3 is recommended but can be done arbitrarily. The integers have to start with a digit. The underscore is allowed in hex, octal and binary as well (e.g. 0x0fff_120a, 0c77_44, 0b1111_0000). - Free operators implemented. - Webpresence improved at [[http://tecomp.sourceforge.net]] and language description improved. - Exception objects implemented. To raise an exception create an object of type DEVELOPER_EXCEPTION and call the feature raise. The class which handles exception has to inherit from EXCEPTION_MANAGER. The feature {{exception}} returns the raised exception. Object test can be used to check the type of the exception (see example below). [[code format="eiffel"]] class MY_EXCEPTION inherit DEVELOPER_EXCEPTION end class HANDLER inherit EXCEPTION_MANAGER feature raise_my_exception do (create {MY_EXCEPTION}).raise end raise_precondition require False do end test_exceptions local i:INTEGER do if i = 0 then raise_my_exception else if i = 1 then raise_precondition end rescue check i <= 1 end check i = 0 implies {e1:MY_EXCEPTION} exception end check i = 1 implies {e2:PRECONDITION_VIOLATION} exception end check i = 1 implies {e: ASSERTION_VIOLATION} exception end i := i + 1 retry end end [[code]] Available exception classes in the kernel library - EXCEPTION, EXCEPTION_MANAGER, DEVELOPER_EXCEPTION, - ASSERTION_VIOLATION, CHECK_VIOLATION, PRECONDITION_VIOLATION, POSTCONDITION_VIOLATION, INVARIANT_VIOLATION, LOOP_INVARIANT_VIOLATION, VARIANT_VIOLATION - BAD_INSPECT_VALUE, IO_EXCEPTION |
|
From: Helmut B. <hel...@gm...> - 2009-04-20 14:08:31
|
The web presence of The Eiffel Compiler has been restructured. A language description has been started. The language description will follow the outline of the famous book "The C programming language" from Brian Kernighan and Denis Ritchie. It will start with an introductory tutorial (already there), a more complete introduction into the language with many complete code examples (still missing) and a concise reference manual with a description of the standard libraries (2 chapters already there). http://tecomp.sourceforge.net Have fun. Any feedback is welcome. |
|
From: Helmut B. <hel...@gm...> - 2009-04-10 03:10:59
|
Version 0.15 implements basic exception handling. Rescue clauses including retry are working properly. Exception classes are still missing. The performance of the virtual machine has been improved by 40%. |
|
From: Helmut B. <hel...@gm...> - 2009-03-30 05:52:58
|
== Features == - Conversion procedure allows formal generics as source. This can be used e.g. in containers to convert an element to a container which contains that element. - Conversion procedure allows conversion from generic types with involve anchored types. - All relative paths in an acefile are evaluated relative to the directory of the acefile, regardless of the directory, where tecomp has been launched. This allows to invoke tecomp with "tecomp path/to/ace/file". == Some bugfixes == - If the root class is not in the universe, the error is properly reported and no validation phase is entered. - Combination of labelled tuples and anchored types work well. - Some bugs in conjunction with generic types involving anchored types fixed. == Improvements == - Calculation of replicated invariants improved. - Calculation of called version for replicated features simplified. |
|
From: Helmut B. <hel...@gm...> - 2009-03-23 14:43:09
|
== Inline agents available ==
A call agent is an object which represents a call to an existing
feature. An inline agent defines the represented feature call inline. An
inline agent represents an anonymous feature of the current type. E.g.
incrementor: FUNCTION[like Current, TUPLE[INTEGER], INTEGER]
...
incrementor := agent (i:INTEGER): INTEGER do
Result := i + 1
end
check
incrementor.item([1]) = 2
incrementor.item([2]) = 3
end
== Some bugfixes ==
- a class name was sometimes displayed wrongly in the diagnostic
messages due to the return of a pointer to a temporary object.
- error report now clearer, if incompatible types are reported and the
source is a detachable formal generic which is attached to an attached
formal generic
- replicated inheritance produced a segfault if the calling feature had
no versions and the called feature had versions in the current class.
|
|
From: Helmut B. <hel...@gm...> - 2009-03-20 15:33:32
|
Website http://tecomp.sourceforge.net is up again. Helmut Brandl wrote: > Due to a problem at sourceforge the website of tecomp > (http://tecomp.sourceforge.net) is temporarily down. > > The download site http://www.sourceforge.net/projects/tecomp is still up > and functioning well. All documentation available at > http://tecomp.sourceforge.net is included in the download tarball. > > Sorry for the inconvenience. As soon as the website is up again, I will > notify. > > Kind regards > Helmut > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > https://lists.sourceforge.net/lists/listinfo/tecomp-user > |
|
From: Helmut B. <hel...@gm...> - 2009-03-20 02:12:11
|
Due to a problem at sourceforge the website of tecomp (http://tecomp.sourceforge.net) is temporarily down. The download site http://www.sourceforge.net/projects/tecomp is still up and functioning well. All documentation available at http://tecomp.sourceforge.net is included in the download tarball. Sorry for the inconvenience. As soon as the website is up again, I will notify. Kind regards Helmut |
|
From: Helmut B. <hel...@gm...> - 2009-03-18 05:34:03
|
New features: - Anchored types "like other_feature" now possible. - Call agent based on unqualified calls now possible |
|
From: Helmut B. <hel...@gm...> - 2009-03-09 05:02:13
|
A new version of tecomp is available at the sourceforge site.
Content:
- Call agents are implemented (e.g. agent {INTEGER}.plus(10) to define
an agent which adds 10 to each INTEGER).
- Syntax for parenthesized targets has been relaxed. You can now write
(1).plus(2) instead of the more strict syntax (|1|).plus(2).
|
|
From: Helmut B. <hel...@gm...> - 2009-02-25 23:24:19
|
The Eiffel Compiler/Interpreter tecomp version 0.10 has been released. The new version make multibranch statements (the analogon to the C switch/case) available. In addition to that the frozen feature default_out has been added to the class ANY. |
|
From: Helmut B. <hel...@gm...> - 2009-02-20 13:21:32
|
Great! Bruce M. Axtens wrote: > Helmut >> I have released today the version 0.9.2 which contains that >> fix/workaround. Maybe it is worthwhile to check if 0.9.2 resolves the >> mingw problem as well. >> > It did! Thanks very much. > > Bruce. > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > https://lists.sourceforge.net/lists/listinfo/tecomp-user > |
|
From: Bruce M. A. <bru...@gm...> - 2009-02-20 05:02:55
|
Helmut > I have released today the version 0.9.2 which contains that > fix/workaround. Maybe it is worthwhile to check if 0.9.2 resolves the > mingw problem as well. > It did! Thanks very much. Bruce. |
|
From: Helmut B. <hel...@gm...> - 2009-02-18 23:48:17
|
Version 0.9.2 of tecomp has been released. That version is functionally equivalent to 0.9.1 and 0.9. However it is now possible to generate tecomp binaries on windows which work without the cygwin.dll. I.e. in order to compile tecomp, cygwin is needed. But the compiled binaries gen_dir/bin/tecomp.exe and gen_dir/bin/atecomp.exe can be copied to any other Windows machine which does not have a cygwin installation. |
|
From: Helmut B. <hel...@gm...> - 2009-02-17 15:53:22
|
The version 0.9 did not include the generated parser/lexer. Therefore on systems without an installation of bison/flex tecomp could not be built. Version 0.9.1 includes the generated parser/lexer. Furthermore 0.9.1 should be able to be built on mingw. Just issue "make mingw" before any other make command (see README). |
|
From: Helmut B. <hel...@gm...> - 2009-02-15 17:42:08
|
Hello Bruce, did the fix work? Can you give some feedback. Helmut Helmut Brandl wrote: > Hi Bruce, > > I have seen your post on comp.lang.eiffel. Would you mind in continuing > the discussion on the mailing list of tecomp and subscribe to that > mailing list? > > I have analyzed your last post. After editing the file > cal/build/flags.mk the dependency run of the makeprocess did not yet use > that flags (an error on my side, needs another correction, see below). > It tried to read again a non existing sys/time.h file on your system. > The creation of the dependencies therefore failed. > > The makeprocess tried to create some dependant files newly. But this > failed, because you don't have flex/bison installed on your system > (which is usually not necessary to build tecomp, because the > distribution includes the sources which flex/bison generates). > > In order to make a fresh and consistent try I propose the following: > > - Delete the complete tecomp directory. > - Unpack the original tarball tecomp_0_9.tar.gz > - Replace the files cal/build/flags.mk and cal/build/rules.mk with the > attached ones before doing any other actions. > - Start the build process as described in the README > > Regards > Helmut > |
|
From: Helmut B. <hel...@gm...> - 2009-02-12 20:58:22
|
Hi Bruce, I have seen your post on comp.lang.eiffel. Would you mind in continuing the discussion on the mailing list of tecomp and subscribe to that mailing list? I have analyzed your last post. After editing the file cal/build/flags.mk the dependency run of the makeprocess did not yet use that flags (an error on my side, needs another correction, see below). It tried to read again a non existing sys/time.h file on your system. The creation of the dependencies therefore failed. The makeprocess tried to create some dependant files newly. But this failed, because you don't have flex/bison installed on your system (which is usually not necessary to build tecomp, because the distribution includes the sources which flex/bison generates). In order to make a fresh and consistent try I propose the following: - Delete the complete tecomp directory. - Unpack the original tarball tecomp_0_9.tar.gz - Replace the files cal/build/flags.mk and cal/build/rules.mk with the attached ones before doing any other actions. - Start the build process as described in the README Regards Helmut |
|
From: Helmut B. <hel...@gm...> - 2009-02-11 22:27:49
|
Since version 0.8 the source of tecomp is in the subversion repository of sourceforge. You can check it out with (if you have a subversion client installed on your machine). cd path_to_your_working_copy mkdir tecomp svn co https://tecomp.svn.sourceforge.net/svnroot/tecomp/trunk tecomp This checks out the most recent version of tecomp. The check-in will be done with the guideline that they happen only on versions which pass all the regression tests. Therefore you can be pretty sure, that you get a fully working copy. Regards Helmut |
|
From: Helmut B. <hel...@gm...> - 2009-02-06 05:52:36
|
The Eiffel Compiler/Interpreter tecomp version 0.9 has been released. In addition to the previous version it implements assigner commands, i.e. you can use the syntax a[index]:=value to assign to array elements without using the less readable syntax a.put(value,index). |
|
From: Helmut B. <hel...@gm...> - 2009-01-22 19:34:35
|
The Eiffel Compiler tecomp version 0.8 has been released. Version 0.8 has a correct garbage collector implemented. Between 0.7 and 0.8 tecomp has been verified for 32/64 bit x86 Linux, Windows, Mac OS X PPC, Opensolaris x86. Tecomp is designed to work on all platforms which have the gnu development tools (gcc/g++/make) installed. If you have any problems, report them on the tecomp mailing list and you will get support. For details (installation and feature content) read the README and the history file on the web or in the distribution. Have fun. http://tecomp.sourceforge.net http://www.sourceforge.net/projects/tecomp |
|
From: Helmut B. <hel...@gm...> - 2009-01-19 07:05:17
|
Hello Martin, at first sight I cannot figure out what the problem is. When exactly do you get the warnings? During building of the libraries or during linking the executable? In order to build the libraries I issue a command of the form ar cru libclass_n.a class_n.o feature_n.o .... If the warnings happen there, then the archiver on OpenSolaris might require different options (the option cru, i.e. create, replace or update has worked on all the systems I know). Maybe the man-pages of the archiver (man ar) on your system will give some information. It is strange that all tests perform well except the one you mentioned. Are you sure that all the other tests succeeded (i.e. make test_tecomp, make test_examples, ...)? Regards Helmut P.S. I plan to switch to the gnu build system with automake and autoconf in the future, because the gnu build system is known to work on a variety of operating systems. This can be a solution to the problem. But up to know I have only started to read the manuals. Therefore I don't know how long it will take to make the switch. sa...@gm... wrote: > Helmut, > > I don't know what I saw, when I reported tecomp does not compile on > OpenSolaris, it compiles! What I saw were a lot of warnings kind of > > ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ > libclass_n.a(class_collection_n.o): section .rel.eh_frame: > symbol .gnu.linkonce.t._ZN18class_collection_tD1Ev (section): > relocation against discarded COMDAT > section .gnu.linkonce.t._ZN18class_collection_tD1Ev: symbol not found, > relocation ignored > ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ > libclass_n.a(type_n.o): section .rel.eh_frame: > symbol .gnu.linkonce.t._ZNK6type_t9get_classEv (section): relocation > against discarded COMDAT > section .gnu.linkonce.t._ZNK6type_t9get_classEv: symbol not found, > relocation ignored > ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ > libclass_n.a(type_n.o): section .rel.eh_frame: > symbol .gnu.linkonce.t._ZN6type_tC1Ev (section): relocation against > discarded COMDAT section .gnu.linkonce.t._ZN6type_tC1Ev: symbol not > found, relocation ignored > ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ > libclass_n.a(type_n.o): section .rel.eh_frame: > symbol .gnu.linkonce.t._ZNK6type_t12substitutionEv (section): > relocation against discarded COMDAT > section .gnu.linkonce.t._ZNK6type_t12substitutionEv: symbol not found, > relocation ignored > ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ > libclass_n.a(type_n.o): section .rel.eh_frame: > symbol > .gnu.linkonce.t._ZN6type_tC1EPK7class_tRK22generic_substitution_t > (section): relocation against discarded COMDAT > section > .gnu.linkonce.t._ZN6type_tC1EPK7class_tRK22generic_substitution_t: > symbol not found, relocation ignored > ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ > libclass_n.a(validator_n.o): section .rel.eh_frame: > symbol .gnu.linkonce.t._ZNK6type_t11is_expandedEv (section): > relocation against discarded COMDAT > section .gnu.linkonce.t._ZNK6type_t11is_expandedEv: symbol not found, > relocation ignored > > that I misinterpreted. > > Almost all tests passed but the following test failed ... > > mschneid@opensolaris-edv:~/scratch/tecomp$ gen_dir/bin/rtest_parse > > test_parse.cpp:63: ---> failed TEST_CHECK(esys.is_ok()) <--- > stack frame 0: address 80a1c55 > stack frame 1: address 80a1b63 > stack frame 2: address 80a1a1d > stack frame 3: address 80a1961 > stack frame 4: address 80a17d0 > > > Abort (core dumped) > > Regards, > Martin > > On 15.01.2009, at 14:53, Helmut Brandl wrote: > >> A running version on OpenSolaris would be good. My intention is that >> tecomp runs on nearly all machines which have the standard gnu tools >> installed (i.e. gcc/g++/make/ar/tar). >> >> If you want to give it a try, you will get my full support. >> >> Helmut >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > https://lists.sourceforge.net/lists/listinfo/tecomp-user > |
|
From: Samuel B. <sam...@gm...> - 2009-01-17 20:44:42
|
Yes, it works on my system; every tests do fine! Helmut Brandl wrote: > Hi Samuel, > > I have fixed the 64 bit issue in the latest release (0.7). > > Could you please download the new version from > www.sourceforge.net/projects/tecomp > <http://www.sourceforge.net/projects/tecomp> and see if it works on > your system. > > Try it and give me some feedback. > > Regards > Helmut > > 2008/12/28 Helmut Brandl <hel...@gm... > <mailto:hel...@gm...>> > > That is interesting. > > I need a little bit of time to analyze it. You are obviously the > first one trying tecomp on a 64bit system. > > As soon as I have a solution I will come back to you. > > Regards > Helmut > > 2008/12/28, Samuel Becker <sam...@gm... > <mailto:sam...@gm...>>: > > make test: > > [...] > ../../cal/src/container/sequence_arrayed.h:676: ---> failed > CHECK(seq_arr_intern_t::aligned_size_for(sizeof(T)) == > sizeof(T)) <--- > stack frame 0: address 0x40f263 > stack frame 1: address 0x40bd9d > stack frame 2: address 0x4033ab > stack frame 3: address 0x4033d4 > stack frame 4: address 0x410386 > stack frame 5: address 0x4007cb > > > make[1]: *** [exec] Abgebrochen > make[1]: Leaving directory `/home/.../tecomp/test/tools' > make: *** [test_tools] Fehler 2 > > _______________________________________________________________ > > make test_tecomp: > > [...] > ../../cal/src/container/sequence_arrayed.h:676: ---> failed > CHECK(seq_arr_intern_t::aligned_size_for(sizeof(T)) == > sizeof(T)) <--- > stack frame 0: address 0x40fbd3 > stack frame 1: address 0x40a065 > stack frame 2: address 0x4396fa > stack frame 3: address 0x426c73 > stack frame 4: address 0x40317f > stack frame 5: address 0x402186 > stack frame 6: address 0x2b0d5bd9b546 > > > make[1]: *** [test] Abgebrochen > make[1]: Leaving directory `/home/.../tecomp/src/tecomp' > make: *** [test_tecomp] Fehler 2 > _________________________________________________________________ > make test_examples: > > [...] > ../../cal/src/container/sequence_arrayed.h:676: ---> failed > CHECK(seq_arr_intern_t::aligned_size_for(sizeof(T)) == > sizeof(T)) <--- > stack frame 0: address 0x40fbd3 > stack frame 1: address 0x40a065 > stack frame 2: address 0x4396fa > stack frame 3: address 0x426c73 > stack frame 4: address 0x40317f > stack frame 5: address 0x402186 > stack frame 6: address 0x2b8ffb55b546 > > > /bin/sh: line 1: 9249 Abgebrochen > ../gen_dir/bin/atecomp > copy.ace < copy.ace > make[1]: *** [run_copy] Fehler 134 > make[1]: Leaving directory `/home/.../tecomp/examples' > make: *** [test_examples] Fehler 2 > > __________________________________________________________________ > > > Helmut Brandl wrote: > > 2008/12/28, Samuel Becker <sam...@gm... > <mailto:sam...@gm...> > > > <mailto:sam...@gm... <mailto:sam...@gm...>>>: > > > > > Now it can be compiled. > > > > > > Great, and does it work now? I.e. can you perform the tests via > > > > make test > > make test_tecomp > > make test_examples > > > > successfully? > > > > > > > > Yours faithfully, > > Samuel > > > > > > > > Helmut Brandl wrote: > > > Hi Samuel, > > > > > > thank you for trying tecomp. > > > > > > Could you please replace the lines 93 and 94 of > src/vm/object.h by > > > > > > uint uival() const {return > caster_t<uint>::conv(ptr);} > > > int ival() const {return caster_t<int> > ::conv(ptr);} > > > > > > > > > and try again. > > > > > > > > > Regards > > > Helmut > > > > > > > > > 2008/12/28 Samuel Becker <sam...@gm... > <mailto:sam...@gm...> > > <mailto:sam...@gm... <mailto:sam...@gm...>> > > > > > > <mailto:sam...@gm... > <mailto:sam...@gm...> <mailto:sam...@gm... > <mailto:sam...@gm...>>>> > > > > > > > > > bricht beim compillieren mit einer Fehlermeldung > ab, hier > > die letzen > > > Zeilen der Ausgabe: > > > > > > ../../src/class/class_collection.h:150: Warnung: > Klammern um && > > > innerhalb von || empfohlen > > > In file included from ../../src/vm/vm_include.h:14, > > > from > ../../src/parser/eiffel_system.h:15, > > > from tecomp.cpp:11: > > > ../../src/vm/object.h: In member function »uint > > object_t::uival() > > > const«: > > > ../../src/vm/object.h:93: Fehler: Typumwandlung > von »uint8*« > > nach > > > »uint« > > > verliert Genauigkeit > > > ../../src/vm/object.h: In member function »uint > object_t::ival() > > > const«: > > > ../../src/vm/object.h:94: Fehler: Typumwandlung > von »uint8*« > > nach > > > »int« > > > verliert Genauigkeit > > > make[1]: *** [../../gen_dir/obj/tecomp_o.o] Fehler 1 > > > make[1]: Leaving directory > > > `/home/samuel/programme/tecomp/src/tecomp/src/tecomp' > > > make: *** [tecomp] Fehler 2 > > > ==> FEHLER: Build fehlgeschlagen. > > > Breche ab ... > > > > > > > > > ein grep 'Fehler' in der Compiler-Ausgabe: > > > > > > ../vm/object.h:93: Fehler: Typumwandlung von > »uint8*« nach > > »uint« > > > verliert Genauigkeit > > > ../vm/object.h:94: Fehler: Typumwandlung von > »uint8*« nach »int« > > > verliert Genauigkeit > > > make[2]: *** [../../gen_dir/obj/eiffel_system_o.o] > Fehler 1 > > > object.h:93: Fehler: Typumwandlung von »uint8*« > nach »uint« > > verliert > > > Genauigkeit > > > object.h:94: Fehler: Typumwandlung von »uint8*« > nach »int« > > verliert > > > Genauigkeit > > > make[2]: *** > [../../gen_dir/obj/virtual_machine_o.o] Fehler 1 > > > ../../src/vm/object.h:93: Fehler: Typumwandlung > von »uint8*« > > nach > > > »uint« > > > verliert Genauigkeit > > > ../../src/vm/object.h:94: Fehler: Typumwandlung > von »uint8*« > > nach > > > »int« > > > verliert Genauigkeit > > > make[1]: *** [../../gen_dir/obj/tecomp_o.o] Fehler 1 > > > make: *** [tecomp] Fehler 2 > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Tecomp-user mailing list > > > Tec...@li... > <mailto:Tec...@li...> > > <mailto:Tec...@li... > <mailto:Tec...@li...>> > > > > > <mailto:Tec...@li... > <mailto:Tec...@li...> > > <mailto:Tec...@li... > <mailto:Tec...@li...>>> > > > > > > https://lists.sourceforge.net/lists/listinfo/tecomp-user > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Tecomp-user mailing list > > > Tec...@li... > <mailto:Tec...@li...> > > <mailto:Tec...@li... > <mailto:Tec...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/tecomp-user > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Tecomp-user mailing list > > Tec...@li... > <mailto:Tec...@li...> > > <mailto:Tec...@li... > <mailto:Tec...@li...>> > > https://lists.sourceforge.net/lists/listinfo/tecomp-user > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Tecomp-user mailing list > > Tec...@li... > <mailto:Tec...@li...> > > https://lists.sourceforge.net/lists/listinfo/tecomp-user > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > <mailto:Tec...@li...> > https://lists.sourceforge.net/lists/listinfo/tecomp-user > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ------------------------------------------------------------------------ > > _______________________________________________ > Tecomp-user mailing list > Tec...@li... > https://lists.sourceforge.net/lists/listinfo/tecomp-user > |
|
From: <sa...@gm...> - 2009-01-17 13:08:49
|
Helmut, I don't know what I saw, when I reported tecomp does not compile on OpenSolaris, it compiles! What I saw were a lot of warnings kind of ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ libclass_n.a(class_collection_n.o): section .rel.eh_frame: symbol .gnu.linkonce.t._ZN18class_collection_tD1Ev (section): relocation against discarded COMDAT section .gnu.linkonce.t._ZN18class_collection_tD1Ev: symbol not found, relocation ignored ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ libclass_n.a(type_n.o): section .rel.eh_frame: symbol .gnu.linkonce.t._ZNK6type_t9get_classEv (section): relocation against discarded COMDAT section .gnu.linkonce.t._ZNK6type_t9get_classEv: symbol not found, relocation ignored ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ libclass_n.a(type_n.o): section .rel.eh_frame: symbol .gnu.linkonce.t._ZN6type_tC1Ev (section): relocation against discarded COMDAT section .gnu.linkonce.t._ZN6type_tC1Ev: symbol not found, relocation ignored ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ libclass_n.a(type_n.o): section .rel.eh_frame: symbol .gnu.linkonce.t._ZNK6type_t12substitutionEv (section): relocation against discarded COMDAT section .gnu.linkonce.t._ZNK6type_t12substitutionEv: symbol not found, relocation ignored ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ libclass_n.a(type_n.o): section .rel.eh_frame: symbol .gnu.linkonce.t._ZN6type_tC1EPK7class_tRK22generic_substitution_t (section): relocation against discarded COMDAT section .gnu.linkonce.t._ZN6type_tC1EPK7class_tRK22generic_substitution_t: symbol not found, relocation ignored ld: warning: relocation warning: R_386_32: file ../../gen_dir/obj/ libclass_n.a(validator_n.o): section .rel.eh_frame: symbol .gnu.linkonce.t._ZNK6type_t11is_expandedEv (section): relocation against discarded COMDAT section .gnu.linkonce.t._ZNK6type_t11is_expandedEv: symbol not found, relocation ignored that I misinterpreted. Almost all tests passed but the following test failed ... mschneid@opensolaris-edv:~/scratch/tecomp$ gen_dir/bin/rtest_parse test_parse.cpp:63: ---> failed TEST_CHECK(esys.is_ok()) <--- stack frame 0: address 80a1c55 stack frame 1: address 80a1b63 stack frame 2: address 80a1a1d stack frame 3: address 80a1961 stack frame 4: address 80a17d0 Abort (core dumped) Regards, Martin On 15.01.2009, at 14:53, Helmut Brandl wrote: > A running version on OpenSolaris would be good. My intention is that > tecomp runs on nearly all machines which have the standard gnu tools > installed (i.e. gcc/g++/make/ar/tar). > > If you want to give it a try, you will get my full support. > > Helmut > |
|
From: Helmut B. <hel...@gm...> - 2009-01-15 13:53:36
|
Great that it works now on your Mac OS X PPC. I have done the
corrections in my version as well. So for the next release we won't have
this problem anymore.
A running version on OpenSolaris would be good. My intention is that
tecomp runs on nearly all machines which have the standard gnu tools
installed (i.e. gcc/g++/make/ar/tar).
If you want to give it a try, you will get my full support.
Helmut
sa...@gm... wrote:
> Hello Helmut,
>
> congratulations, your suggested modification solved the problem. All
> tests execute successfully now on Mac OS X PPC.
>
> BTW: Yesterday I also tried to compile tecomp on OpenSolaris 11/08 x86
> but got lot of errors during compilation. I did not find the time to
> look at the errors in detail yet but it seems that either some
> libraries were missing or the compiler did not find the proper
> libraries. If you are interested I can try to figure out what's
> happening when I find some spare time.
>
> Regards,
> Martin
>
> On 15.01.2009, at 03:19, Helmut Brandl wrote:
>
>> Hello Martin,
>>
>> if I read your trace correctly, you made 2 runs.
>>
>> In the first run you set a breakpoint at rtest_class.cpp:14 and
>> started
>> the program. But the program did not even reach the breakpoint. The
>> segfault happened before, i.e. during initialization of global
>> variables.
>>
>> In the second run you set a breakpoint at feature_name.cpp:175 at the
>> entry point of the routine in which the segfault happened in the first
>> run. Then you stepped through until line 182 where the program
>> crashed.
>>
>> I am not 100% sure, but obviously I did not take enough care for the
>> initialization sequence of global variables.
>>
>> Could you please try the following:
>>
>> comment out line 14 of test/class/test_class.cpp
>>
>> // static class_collection_t cls_col;
>>
>> This global variable is a relict which is not used. I assume the
>> constructor of that variable causes the segfault, because it tries to
>> initialize a feature with name "make" and the class feature_name_t has
>> also some global variables (str_buf) which might not yet be
>> initialized
>> properly at this point in time.
>>
>> I am not 100% sure but pretty confident that this is the bug.
>>
>> Regards
>> Helmut
>>
>>
>> sa...@gm... wrote:
>>> Hello Helmut,
>>>
>>> below are the results from my debugging sessions. I hope you will
>>> find
>>> the information you asked for.
>>>
>>> Regards, Martin
>>>
>>> ____________
>>>
>>> (gdb) start
>>> Breakpoint 1 at 0x1a9c: file rtest_class.cpp, line 14.
>>> Starting program: /Volumes/Scratch/tecomp/gen_dir/bin/rtest_class
>>> Reading symbols for shared libraries +++. done
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0xfffffff4
>>> 0x92d7386c in std::string::assign ()
>>> (gdb) bt
>>> #0 0x92d7386c in std::string::assign ()
>>> #1 0x00035cc0 in feature_name_t::feature_name_t (this=0xfb7b8,
>>> cstr=0xc5024 "make", c=70 'F') at feature_name.cpp:182
>>> #2 0x00067e64 in class_collection_t::class_collection_t
>>> (this=0xfb724) at class_collection.cpp:124
>>> #3 0x000f1f84 in __static_initialization_and_destruction_0 ()
>>> #4 0x000f2c44 in global constructors keyed to
>>> _ZNK12test_class_t4nameEv ()
>>> #5 0x8fe1376c in
>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>> ()
>>> #6 0x8fe0f180 in
>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj
>>> ()
>>> #7 0x8fe0f2a4 in
>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
>>> #8 0x8fe03848 in __dyld__ZN4dyld24initializeMainExecutableEv ()
>>> #9 0x8fe0807c in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_
>>> ()
>>> #10 0x8fe01774 in
>>> __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
>>> #11 0x8fe01048 in __dyld__dyld_start ()
>>> (gdb)
>>>
>>> ________
>>>
>>> (gdb) break feature_name.cpp:175
>>> Breakpoint 1 at 0x35c80: file feature_name.cpp, line 175.
>>> Breakpoint 2 at 0x35df8: file feature_name.cpp, line 175.
>>> warning: Multiple breakpoints were set.
>>> Use the "delete" command to delete unwanted breakpoints.
>>> (gdb) start
>>> Breakpoint 3 at 0x1a9c: file rtest_class.cpp, line 14.
>>> Starting program: /Volumes/Scratch/tecomp/gen_dir/bin/rtest_class
>>> Reading symbols for shared libraries +++. done
>>>
>>> Breakpoint 1, feature_name_t::feature_name_t (this=0xfb7b8,
>>> cstr=0xc5024 "make", c=70 'F') at feature_name.cpp:178
>>> 178 if( !cstr || cstr[0] == '\0' ){
>>> (gdb) step
>>> 182 str_buf = cstr;
>>> (gdb) print str_buf
>>> $1 = {
>>> static npos = 4294967295,
>>> _M_dataplus = {
>>> <std::allocator<char>> = {
>>> <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
>>> fields>},
>>> members of
>>> std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>>> ::_Alloc_hider:
>>> _M_p = 0x0
>>> }
>>> }
>>> (gdb) print cstr
>>> $2 = 0xc5024 "make"
>>> (gdb) step
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0xfffffff4
>>> 0x92d7386c in std::string::assign ()
>>> (gdb)
>>>
>>> _____________
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> Tecomp-user mailing list
>>> Tec...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tecomp-user
>>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Tecomp-user mailing list
>> Tec...@li...
>> https://lists.sourceforge.net/lists/listinfo/tecomp-user
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Tecomp-user mailing list
> Tec...@li...
> https://lists.sourceforge.net/lists/listinfo/tecomp-user
>
|
|
From: <sa...@gm...> - 2009-01-15 07:05:38
|
Hello Helmut,
congratulations, your suggested modification solved the problem. All
tests execute successfully now on Mac OS X PPC.
BTW: Yesterday I also tried to compile tecomp on OpenSolaris 11/08 x86
but got lot of errors during compilation. I did not find the time to
look at the errors in detail yet but it seems that either some
libraries were missing or the compiler did not find the proper
libraries. If you are interested I can try to figure out what's
happening when I find some spare time.
Regards,
Martin
On 15.01.2009, at 03:19, Helmut Brandl wrote:
> Hello Martin,
>
> if I read your trace correctly, you made 2 runs.
>
> In the first run you set a breakpoint at rtest_class.cpp:14 and
> started
> the program. But the program did not even reach the breakpoint. The
> segfault happened before, i.e. during initialization of global
> variables.
>
> In the second run you set a breakpoint at feature_name.cpp:175 at the
> entry point of the routine in which the segfault happened in the first
> run. Then you stepped through until line 182 where the program
> crashed.
>
> I am not 100% sure, but obviously I did not take enough care for the
> initialization sequence of global variables.
>
> Could you please try the following:
>
> comment out line 14 of test/class/test_class.cpp
>
> // static class_collection_t cls_col;
>
> This global variable is a relict which is not used. I assume the
> constructor of that variable causes the segfault, because it tries to
> initialize a feature with name "make" and the class feature_name_t has
> also some global variables (str_buf) which might not yet be
> initialized
> properly at this point in time.
>
> I am not 100% sure but pretty confident that this is the bug.
>
> Regards
> Helmut
>
>
> sa...@gm... wrote:
>> Hello Helmut,
>>
>> below are the results from my debugging sessions. I hope you will
>> find
>> the information you asked for.
>>
>> Regards, Martin
>>
>> ____________
>>
>> (gdb) start
>> Breakpoint 1 at 0x1a9c: file rtest_class.cpp, line 14.
>> Starting program: /Volumes/Scratch/tecomp/gen_dir/bin/rtest_class
>> Reading symbols for shared libraries +++. done
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0xfffffff4
>> 0x92d7386c in std::string::assign ()
>> (gdb) bt
>> #0 0x92d7386c in std::string::assign ()
>> #1 0x00035cc0 in feature_name_t::feature_name_t (this=0xfb7b8,
>> cstr=0xc5024 "make", c=70 'F') at feature_name.cpp:182
>> #2 0x00067e64 in class_collection_t::class_collection_t
>> (this=0xfb724) at class_collection.cpp:124
>> #3 0x000f1f84 in __static_initialization_and_destruction_0 ()
>> #4 0x000f2c44 in global constructors keyed to
>> _ZNK12test_class_t4nameEv ()
>> #5 0x8fe1376c in
>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>> ()
>> #6 0x8fe0f180 in
>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj
>> ()
>> #7 0x8fe0f2a4 in
>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
>> #8 0x8fe03848 in __dyld__ZN4dyld24initializeMainExecutableEv ()
>> #9 0x8fe0807c in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_
>> ()
>> #10 0x8fe01774 in
>> __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
>> #11 0x8fe01048 in __dyld__dyld_start ()
>> (gdb)
>>
>> ________
>>
>> (gdb) break feature_name.cpp:175
>> Breakpoint 1 at 0x35c80: file feature_name.cpp, line 175.
>> Breakpoint 2 at 0x35df8: file feature_name.cpp, line 175.
>> warning: Multiple breakpoints were set.
>> Use the "delete" command to delete unwanted breakpoints.
>> (gdb) start
>> Breakpoint 3 at 0x1a9c: file rtest_class.cpp, line 14.
>> Starting program: /Volumes/Scratch/tecomp/gen_dir/bin/rtest_class
>> Reading symbols for shared libraries +++. done
>>
>> Breakpoint 1, feature_name_t::feature_name_t (this=0xfb7b8,
>> cstr=0xc5024 "make", c=70 'F') at feature_name.cpp:178
>> 178 if( !cstr || cstr[0] == '\0' ){
>> (gdb) step
>> 182 str_buf = cstr;
>> (gdb) print str_buf
>> $1 = {
>> static npos = 4294967295,
>> _M_dataplus = {
>> <std::allocator<char>> = {
>> <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
>> fields>},
>> members of
>> std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>> ::_Alloc_hider:
>> _M_p = 0x0
>> }
>> }
>> (gdb) print cstr
>> $2 = 0xc5024 "make"
>> (gdb) step
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0xfffffff4
>> 0x92d7386c in std::string::assign ()
>> (gdb)
>>
>> _____________
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Tecomp-user mailing list
>> Tec...@li...
>> https://lists.sourceforge.net/lists/listinfo/tecomp-user
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Tecomp-user mailing list
> Tec...@li...
> https://lists.sourceforge.net/lists/listinfo/tecomp-user
|