https://sourceforge.net/p/gobo-eiffel/bugs/Recent changes to bugsenFri, 13 Apr 2012 16:25:36 -0000https://sourceforge.net/p/gobo-eiffel/bugs/46/The GEC generated code for \`deep\_copy' of SPECIAL objects does either crash or does not work correctly. The file added describes the bug causing C code and proposes two possible bug fixes. With regards WolfgangWolfgang JansenFri, 13 Apr 2012 16:25:36 -0000https://sourceforge.net26dfdfee8968bcff0f4e6b3fc9b498f3e34f5a8chttps://sourceforge.net/p/gobo-eiffel/bugs/45/The new GEC version \(GIT version 6857a16098ba22ce158627abfe2d5348b617378d from 7-July 2011\) does not compile an old project that has been compiled successfully by previous compiler versions, For example, features of a class are not found while the class text clearly says that they are there. The error messages sound as if during analysis of one class knowledge of another class is needed but not ready and the other class is not analyzed on the flight. The failure occurs for a rather large project, smaller sub-projects are compiled successfully, so I add the sources of the large project. To test it, unpack the TAR file in some directory, switch to that directory and the enter the commands \(in UNIX notation\): setenv WJ \`pwd\` \# WJ is referred to in the XACE file cd candys gec --cc=no --catcall=no ca.xace With regards WJ PS: The TAR file is too large to be added to this report. You may find it at http://www.cs.uni-potsdam.de/~wjansen/tar/wj.tgz Wolfgang JansenMon, 11 Jul 2011 10:27:53 -0000https://sourceforge.net7fc23864abd1fd878a7b58c956d6fe077d62df9bhttps://sourceforge.net/p/gobo-eiffel/bugs/44/Hi, I would like to report a spurious bug of GEC. A local variable declared as REAL\_64 is considered by the compiler as an INTEGER\_32 variable: instead of \`T13 l3;' the C code reads \`T6 l6;'. This has several consequences. First, additions like \`x+x1' are rejected where \`x' is a correctly treated REAL\_64 but \`x1' is the variable of question. Compilation works if those additions are commented out but then the algorithm is wrong. Second, routine calls like \`call\(x1\)' get in C code a catcall check which at run time fires: the call expects REAL\_64 while the actual argument is the erroneous INTEGER\_32. The attachment contains the slightly reduced project. Running "geant compile" should work. The critical feature is \`DIAGRAM\_IMPL.callback', the critical local variable is \`x1' \(line 538\). Lines 555 and 559 are commented out additions, erroneous catcall checks are inserted in the calls of lines 552, 568, 580. With regards WJ Wolfgang JansenWed, 23 Mar 2011 17:13:24 -0000https://sourceforge.net987377778b93a53db3ec1fd2b60d662f984a42fchttps://sourceforge.net/p/gobo-eiffel/bugs/43/$ ./bootstrap.sh gcc ge In file included from gec15.c:1: gec.h:71885:22: eif\_plug.h: No such file or directory In file included from gec14.c:1: gec.h:71885:22: eif\_plug.h: No such file or directory In file included from gec13.c:1: gec.h:71885:22: eif\_plug.h: No such file or directory In file included from gec12.c:1: AnonymousThu, 27 May 2010 13:42:52 -0000https://sourceforge.net684a3c3564629ad13776bb1ebd6ee41579d03f8fhttps://sourceforge.net/p/gobo-eiffel/bugs/42/\# bmake install => Bootstrap dependency digest>=20010302: found digest-20080510 ===> Skipping vulnerability checks. WARNING: No /var/db/pkg/pkg-vulnerabilities file found. WARNING: To fix run: \`/usr/pkg/sbin/pkg\_admin -K /var/db/pkg fetch-pkg-vulnerabilities'. => Checksum SHA1 OK for gobo39-src.tar.gz => Checksum RMD160 OK for gobo39-src.tar.gz ===> Installing dependencies for gobo-eiffel-3.9 ===> Overriding tools for gobo-eiffel-3.9 ===> Extracting for gobo-eiffel-3.9 ===> Patching for gobo-eiffel-3.9 ===> Creating toolchain wrappers for gobo-eiffel-3.9 ===> Configuring for gobo-eiffel-3.9 ===> Building for gobo-eiffel-3.9 => Unwrapping files-to-be-installed. ===> Installing for gobo-eiffel-3.9 cd /usr/pkgsrc/wip/gobo-eiffel/work/gobo && /usr/bin/env GOBO=/usr/pkgsrc/wip/gobo-eiffel/work/gobo ./install.sh gcc strip: 'geant\}': No such fileothyroThu, 20 May 2010 03:24:55 -0000https://sourceforge.net8ca0c7a5cb00e0ed88094eb144e4de9db4bf96f0https://sourceforge.net/p/gobo-eiffel/bugs/41/In the implementation of class IDENTIFIED\_ROUTINES, object addresses are casted to INTEGER\_32. This causes loss of information when compiled on a 64-bit computer.Eric BezaultMon, 10 May 2010 07:41:56 -0000https://sourceforge.nete5f783febfec7730ca766292a11d0f1d530223cahttps://sourceforge.net/p/gobo-eiffel/bugs/40/When compiling the following program: ~~~~~~~~~~~~~~~~~ class BUG create make feature make do print \(bar.item \(\[\]\)\) end foo: FUNCTION \[ANY, TUPLE, STRING\] do if 1 = 2 then Result := agent \("gobo"\).out elseif 2 = 3 then Result := agent out else Result := agent \(2\).out end end bar: FUNCTION \[ANY, TUPLE, STRING\] do Result := agent foo.item \(\[\]\) end end ~~~~~~~~~~~~~~~~~ the C compilers complains about unresolved functions: ~~~~~~~~~~~~~~~~~ bang2create1.obj : error LNK2019: unresolved external symbol \_T23x1759T0 referenced in function \_T21f1af1 ~~~~~~~~~~~~~~~~~Eric BezaultWed, 05 May 2010 12:53:26 -0000https://sourceforge.netca4b132971a7e2fb116bc0cd846b3db5fc4fac15https://sourceforge.net/p/gobo-eiffel/bugs/39/For instance take this path a+path := "/tmp/bug/a\\\\\\\\\!@\#$%^&\*\(\)-\_=+|\`~\[\]\{\} ;:,.<>%"'z'/src" inherit KL\_SHARED\_FILE\_SYSTEM code: file\_system.pathname\_from\_file\_system \(directory \(a\_path\), windows\_file\_system\) it won't handle the \\\\\\\ as what it is, it resolves it as a simple directory separator "/" Jocelyn FIATMon, 07 Sep 2009 16:16:55 -0000https://sourceforge.net6a65cc34c481345bade74f6549e3448a22226930https://sourceforge.net/p/gobo-eiffel/bugs/38/The code below causes a precondition violation in feature move\_all\_cursors: make local l\_set: DS\_HASH\_SET\[INTEGER\] do create l\_set.make\_default l\_set.force \(5\) l\_set.force \(6\) l\_set.force \(10\) l\_set.remove \(6\) l\_set.compress endJann RöderMon, 03 Aug 2009 12:02:25 -0000https://sourceforge.net7630c3d6793cf9d841f38b7385c5756f3a858e47https://sourceforge.net/p/gobo-eiffel/bugs/37/The gobo\_kernel.ecf project distributed with ES 6.4.7.9263 GPL Windows doesn't compile. It has a configuration error: Error code: VD71 Configuration error Directory open error: c:\program files\eiffel software\eiffelstudio 6.4 gpl\library\gobo\override\library\kernel override\library\kernel\ Configuration: c:\program files\eiffel software\eiffelstudio 6.4 gpl\library\gobo\gobo\_kernel.ecf If I remove the \`override' cluster the project compiles successfully.Tue, 07 Jul 2009 19:57:04 -0000https://sourceforge.net63145772880f3d5576b1607803a32575525b1c9e