Menu
▾
▴
gobo-eiffel-develop — Development discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(80) |
Jun
(71) |
Jul
(34) |
Aug
(58) |
Sep
|
Oct
(220) |
Nov
(146) |
Dec
(36) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(28) |
Feb
(152) |
Mar
(293) |
Apr
(213) |
May
(158) |
Jun
(96) |
Jul
(78) |
Aug
(39) |
Sep
(169) |
Oct
(128) |
Nov
(83) |
Dec
(149) |
| 2003 |
Jan
(155) |
Feb
(14) |
Mar
(60) |
Apr
(86) |
May
(92) |
Jun
(109) |
Jul
(25) |
Aug
(44) |
Sep
(10) |
Oct
(39) |
Nov
(37) |
Dec
(128) |
| 2004 |
Jan
(71) |
Feb
(199) |
Mar
(192) |
Apr
(360) |
May
(93) |
Jun
(75) |
Jul
(51) |
Aug
(195) |
Sep
(390) |
Oct
(186) |
Nov
(173) |
Dec
(331) |
| 2005 |
Jan
(102) |
Feb
(154) |
Mar
(160) |
Apr
(88) |
May
(79) |
Jun
(78) |
Jul
(126) |
Aug
(94) |
Sep
(110) |
Oct
(187) |
Nov
(188) |
Dec
(31) |
| 2006 |
Jan
(12) |
Feb
(40) |
Mar
(123) |
Apr
(102) |
May
(62) |
Jun
(36) |
Jul
(19) |
Aug
(31) |
Sep
(59) |
Oct
(67) |
Nov
(57) |
Dec
(35) |
| 2007 |
Jan
(153) |
Feb
(53) |
Mar
(27) |
Apr
(11) |
May
(49) |
Jun
(3) |
Jul
(56) |
Aug
(58) |
Sep
(30) |
Oct
(57) |
Nov
(47) |
Dec
(155) |
| 2008 |
Jan
(71) |
Feb
(68) |
Mar
(79) |
Apr
(72) |
May
(82) |
Jun
(10) |
Jul
(19) |
Aug
(25) |
Sep
(17) |
Oct
(10) |
Nov
(32) |
Dec
(9) |
| 2009 |
Jan
(26) |
Feb
(1) |
Mar
(1) |
Apr
(12) |
May
(16) |
Jun
(7) |
Jul
(12) |
Aug
(22) |
Sep
(21) |
Oct
|
Nov
(7) |
Dec
|
| 2010 |
Jan
(3) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(5) |
Jun
(5) |
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
|
Dec
(6) |
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(11) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2016 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2017 |
Jan
(3) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2022 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Berend de B. <be...@po...> - 2014-10-22 20:29:54
|
Hi All, Would it be useful to have a gobo tool to make creating Eiffel applications from the command-line easier? Example: gobo generate app "next-great-thing" Which would simply write a default system.xace and build.eant. Saves time, and makes writing "how to create an eiffel app" easier. Now I always copy these files from an existing project, and edit them. Tools like this have become quite common (I modelled the above example on sencha cmd). After we have step one working we can expand this with: gobo generate app --description "Build it and they will come" "next-great-thing" It could perhaps start geant etc too (not sure why you want too): gobo geant compile_ge i..e can become single entry point to run Gobo command-line tools. -- All the best, Berend de Boer |
|
From: Berend de B. <be...@po...> - 2014-04-07 23:12:16
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> I don't think that it's a good idea to declare
Eric> `project_path' as a constant and then alter its value. Why
Eric> not make it an attribute?
It's just an initialised feature. Not really a constant.
You rather have me initialise it in make?
Eric> Also, it looks like you messed up the indentation when
Eric> editing non-Eiffel files.
Yo mean History.txt? Hopefully fixed.
--
All the best,
Berend de Boer
|
|
From: Eric B. <er...@go...> - 2014-04-07 08:36:47
|
On 4/7/2014 1:36 AM, Berend de Boer wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > >> Can I introduce a variable like: GOBO_BUILD_PREFIX which will > >> cause compilation to not presume EIFGENs is in the current > >> directory, but will prepend GOBO_BUILD_PREFIX if this is > >> defined? > > Eric> Fine with me. > > This has now been pushed to git. > > Only works for the ISE compiler at the moment, and because of the > rewrite I dropped support for the EIFGEN directory as I don't think > Gobo currently compiles with any ISE compiler that still uses that. I looked at: http://sourceforge.net/p/gobo-eiffel/gobo/ci/3058edfe81d35788b636ec6e7e4bf019b023f465/ I don't think that it's a good idea to declare `project_path' as a constant and then alter its value. Why not make it an attribute? Also, it looks like you messed up the indentation when editing non-Eiffel files. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2014-04-06 23:36:57
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>> Can I introduce a variable like: GOBO_BUILD_PREFIX which will
>> cause compilation to not presume EIFGENs is in the current
>> directory, but will prepend GOBO_BUILD_PREFIX if this is
>> defined?
Eric> Fine with me.
This has now been pushed to git.
Only works for the ISE compiler at the moment, and because of the
rewrite I dropped support for the EIFGEN directory as I don't think
Gobo currently compiles with any ISE compiler that still uses that.
--
All the best,
Berend de Boer
|
|
From: Jocelyn F. <jf...@ei...> - 2014-01-21 14:42:03
|
Just in case this may help, you can also use the ISE_EC_FLAGS environment variable to pass extra argument to ISE Eiffel compiler. -- Jocelyn On Mon, Jan 20, 2014 at 9:51 PM, Berend de Boer <be...@po...> wrote: > >>>>> "LIGOT" == LIGOT Olivier <Oli...@gr...> writes: > > LIGOT> According to the EiffelStudio compiler documentation[1], > LIGOT> you can also use the option -project_path to specify the > LIGOT> compilation directory (default is current directory). > > Yep, but I invoice the ES compiler through geant, so that's where this > request comes from. > > -- > All the best, > > Berend de Boer > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop > > -- Jocelyn ------------------------------------------------------------------------ Eiffel Software 805-685-1006 http://www.eiffel.com Customer support: http://support.eiffel.com User group: http://groups.eiffel.com/join ------------------------------------------------------------------------ |
|
From: Berend de B. <be...@po...> - 2014-01-20 20:51:54
|
>>>>> "LIGOT" == LIGOT Olivier <Oli...@gr...> writes:
LIGOT> According to the EiffelStudio compiler documentation[1],
LIGOT> you can also use the option -project_path to specify the
LIGOT> compilation directory (default is current directory).
Yep, but I invoice the ES compiler through geant, so that's where this
request comes from.
--
All the best,
Berend de Boer
|
|
From: LIGOT O. <Oli...@gr...> - 2014-01-20 09:57:03
|
According to the EiffelStudio compiler documentation[1], you can also use the option -project_path to specify the compilation directory (default is current directory). [1] http://docs.eiffel.com/book/eiffelstudio/eiffelstudio-using-command-line-options Olivier Ligot ________________________________________ De : Berend de Boer [be...@po...] Date d'envoi : vendredi 17 janvier 2014 22:59 À : Gobo Developers Mailing List Objet : [gobo-eiffel-develop] Prefix for EIFGENs to compile to architecture dependent directory Hi All, It would be useful for me to be able to compile to: /build/ubuntu-x86/EIFGENs/foo /build/debian-amd64/EIFGENs/foo etc. geant does not support this. Can I introduce a variable like: GOBO_BUILD_PREFIX which will cause compilation to not presume EIFGENs is in the current directory, but will prepend GOBO_BUILD_PREFIX if this is defined? -- All the best, Berend de Boer ***** Group S disclaimer ***** http://www.groups.be/1_mail-disclaimer.htm |
|
From: Eric B. <er...@go...> - 2014-01-17 23:10:15
|
On 1/17/2014 10:59 PM, Berend de Boer wrote: > It would be useful for me to be able to compile to: > > /build/ubuntu-x86/EIFGENs/foo > /build/debian-amd64/EIFGENs/foo > > etc. > > geant does not support this. > > Can I introduce a variable like: GOBO_BUILD_PREFIX which will cause > compilation to not presume EIFGENs is in the current directory, but > will prepend GOBO_BUILD_PREFIX if this is defined? Fine with me. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2014-01-17 21:59:33
|
Hi All, It would be useful for me to be able to compile to: /build/ubuntu-x86/EIFGENs/foo /build/debian-amd64/EIFGENs/foo etc. geant does not support this. Can I introduce a variable like: GOBO_BUILD_PREFIX which will cause compilation to not presume EIFGENs is in the current directory, but will prepend GOBO_BUILD_PREFIX if this is defined? -- All the best, Berend de Boer |
|
From: Eric B. <er...@go...> - 2013-08-09 01:06:08
|
On 8/8/2013 1:23 AM, Howard Thomson wrote: > Just browsing source code again, and noted that in the class ET_GROUP > [$GOBO/library/tools/eiffel/ast/group/et_group.e], there is a query > 'reset_absolute_pathname' which would seem to be more likely candidate > as a command: Good catch. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Howard T. <ha...@th...> - 2013-08-07 23:23:44
|
Hi Eric, Just browsing source code again, and noted that in the class ET_GROUP [$GOBO/library/tools/eiffel/ast/group/et_group.e], there is a query 'reset_absolute_pathname' which would seem to be more likely candidate as a command: feature -- Initialization reset_absolute_pathname: STRING -- Force the computation of `absolute_pathname' next time -- it will be called. This is useful when the values of the -- environment variables have changed or when the cluster -- hierarchy has changed. Otherwise the result of -- `absolute_pathname' is cached to avoid having to -- compute its value at each call (like a once-per-object). do cached_absolute_pathname := Void ensure absolute_pathname_reset: cached_absolute_pathname = Void end Would you agree ? I did a 'find ... | xargs grep ...' and found no other instance of the identifier reset_absolute_pathname, so presume this has yet to be used. Regards, Howard |
|
From: Eric B. <er...@go...> - 2013-07-11 02:01:13
|
On 7/9/2013 9:01 PM, Howard Thomson wrote: > I have just been browsing the classes for the Gobo compiler and note in > the class ET_CLASS_CODES [library/tools/eiffel/ast/misc] that the query > 'is_numeric' is probably erroneous ... > > is_basic (a_code: NATURAL_8): BOOLEAN > -- Does `a_code' correspond to a basic class? > -- > -- Note: a basic class is one of "BOOLEAN", "CHARACTER_8", > -- "CHARACTER_32", "INTEGER_8", "INTEGER_16", "INTEGER_32", > -- "INTEGER_64", "NATURAL_8", "NATURAL_16", "NATURAL_32", > -- "NATURAL_64", "POINTER", "REAL_32", "REAL_64". > do > Result := boolean_class_code <= a_code and a_code <= pointer_class_code > end > > is_numeric (a_code: NATURAL_8): BOOLEAN > -- Does `a_code' correspond to a numeric class? > -- > -- Note: a basic class is one of "INTEGER_8", "INTEGER_16", > -- "INTEGER_32", "INTEGER_64", "NATURAL_8", "NATURAL_16", > -- "NATURAL_32", "NATURAL_64", "REAL_32", "REAL_64". > do > -- Result := boolean_class_code <= a_code and a_code <= pointer_class_code -- Current > Result := integer_8_class_code <= a_code and a_code <= real_64_class_code -- Suggested > end Indeed. Thank you for pointed that out. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Howard T. <ha...@th...> - 2013-07-09 19:29:23
|
Hi, I have just been browsing the classes for the Gobo compiler and note in the class ET_CLASS_CODES [library/tools/eiffel/ast/misc] that the query 'is_numeric' is probably erroneous ... is_basic (a_code: NATURAL_8): BOOLEAN -- Does `a_code' correspond to a basic class? -- -- Note: a basic class is one of "BOOLEAN", "CHARACTER_8", -- "CHARACTER_32", "INTEGER_8", "INTEGER_16", "INTEGER_32", -- "INTEGER_64", "NATURAL_8", "NATURAL_16", "NATURAL_32", -- "NATURAL_64", "POINTER", "REAL_32", "REAL_64". do Result := boolean_class_code <= a_code and a_code <= pointer_class_code end is_numeric (a_code: NATURAL_8): BOOLEAN -- Does `a_code' correspond to a numeric class? -- -- Note: a basic class is one of "INTEGER_8", "INTEGER_16", -- "INTEGER_32", "INTEGER_64", "NATURAL_8", "NATURAL_16", -- "NATURAL_32", "NATURAL_64", "REAL_32", "REAL_64". do -- Result := boolean_class_code <= a_code and a_code <= pointer_class_code -- Current Result := integer_8_class_code <= a_code and a_code <= real_64_class_code -- Suggested end Regards, Howard |
|
From: Eric B. <er...@go...> - 2013-04-03 15:17:35
|
On 4/3/2013 11:45 AM, Wolfgang Jansen wrote: > Compiling file $GOBO/work/bootstrap/gec2.c issues the warnings > gec2.c:206:32: warning: character constant too long for its type > [enabled by default] > (and a handful more lines). There is the char literal '\177775'. It looks like you don't have the latest version of this file. There is no literal '\177775' at lit 206 anymore. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Wolfgang J. <wo....@ka...> - 2013-04-03 10:14:40
|
On 04/03/2013 12:23 AM, Eric Bezault wrote: > Hi Wolfgang, > > On 3/8/2013 8:43 PM, Wolfgang Jansen wrote: >> today I downloaded the newest GEC version from GIT and tried to install >> it from scratch, >> i.e. by running $GOBO/work/bootstrap/bootstrap.sh. It was, and still is, >> really terrible. > > I'm sorry to hear about your bad experience. > The problem is that I don't have access to a system other than Windows. > So I was not aware of these problems. I tried to fix them the best that > I could based on your report. Please let me know if it's working better > for you. > Addition to the previous reply. Sorry, I was confused when I recompiled the stuff. Now I see that after modification of STRING_32 mentioned before C and Eiffel compilation work very well. -- Dr. Wolfgang Jansen Lauenburger Straße 40 D-12169 Berlin Tel: 0172 4086916 |
|
From: Wolfgang J. <wo....@ka...> - 2013-04-03 09:45:54
|
On 04/03/2013 12:23 AM, Eric Bezault wrote:
> Hi Wolfgang,
>
> On 3/8/2013 8:43 PM, Wolfgang Jansen wrote:
>> today I downloaded the newest GEC version from GIT and tried to install
>> it from scratch,
>> i.e. by running $GOBO/work/bootstrap/bootstrap.sh. It was, and still is,
>> really terrible.
>
> I'm sorry to hear about your bad experience.
> The problem is that I don't have access to a system other than Windows.
> So I was not aware of these problems. I tried to fix them the best that
> I could based on your report. Please let me know if it's working better
> for you.
>
Yes, it works better but not good.
Compiling file $GOBO/work/bootstrap/gec2.c issues the warnings
gec2.c:206:32: warning: character constant too long for its type
[enabled by default]
(and a handful more lines). There is the char literal '\177775'.
I guess that the gcc turns it into a 8bit literal by removing extra bits,
i.e. the warnings become semantic errors. I changed the occurrences
of '\177775' into the int literal 0177775.
Then the same warnings (and semantic errors) occur when the generated
gec compiles itself, now lines gec2.c:10203:13 etc., first in routine
UTF_CONVERTER.escaped_utf_32_substring_into_utf_8_0_pointer
where line 312
c := s.code (i)
(with `s: READABLE_STRING_GENERAL') is compiled into
t4 = (T3)('\177775');
t5 = ((T10)(t4));
I think that routines STRING_32.code or CHARACTER_32.code are to be
modified.
Nevertheless, compilation continues (because we have warnings, not errors)
and ends again with errors of Eiffel compilation:
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GIAAA] internal error.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVKNL1] missing kernel class *UNKNOWN*.
----
[GVSRC4] unknown root class *UNKNOWN*.
----
BUILD FAILED!
BUILD FAILED!
Then I replaced line 194 of STRING_32
Result := area.item (i - 1).code.to_natural_32
by
Result := area.item (i - 1).natural_32_code
and tried it again: the warnings and errors remain.
Here, I gave up.
--
Dr. Wolfgang Jansen
Lauenburger Straße 40
D-12169 Berlin
Tel: 0172 4086916
|
|
From: Eric B. <er...@go...> - 2013-04-02 23:43:21
|
Hi Wolfgang, On 3/8/2013 8:43 PM, Wolfgang Jansen wrote: > today I downloaded the newest GEC version from GIT and tried to install > it from scratch, > i.e. by running $GOBO/work/bootstrap/bootstrap.sh. It was, and still is, > really terrible. I'm sorry to hear about your bad experience. The problem is that I don't have access to a system other than Windows. So I was not aware of these problems. I tried to fix them the best that I could based on your report. Please let me know if it's working better for you. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Wolfgang J. <wo....@ka...> - 2013-03-08 19:44:05
|
Hi all, today I downloaded the newest GEC version from GIT and tried to install it from scratch, i.e. by running $GOBO/work/bootstrap/bootstrap.sh. It was, and still is, really terrible. There are syntax errors in files gec2.c, gec17.c, then syntax errors in files $GOBO/tool/gec/runtime/c/eif_file.c and eif_dir.c (probably causing the errors in the first files), finally in the external C code of $GOBO/library/free_elks/kernel/file_info.e. After fixing the syntax errors and adding option <option name="link" value="-pthread"/> to the "gc" option in file $GOBO/src/gec/system.xace (probably Unix/Linux specific) compilation works to some extend but issuing many warnings and finally does crash definitively because of "missing kernel class *UNKOWN*". The attachment contains the compilation messages. Best regards WJ PS: Installation platform: - Linux 3.5.0-25-generic x86_64 - gcc version 4.7.2 - git commit d9f61c2e8ecf183634641470cc3ccfe39577b632 -- Dr. Wolfgang Jansen Lauenburger Straße 40 D-12169 Berlin Tel: 0172 4086916 |
|
From: Eric B. <er...@go...> - 2013-02-20 12:19:36
|
On 2/18/2013 6:21 PM, Colin Adams wrote: > Having temporarily switched off invariant checking for the et_tools > cluster, I now get a precondition violation: > > The value of an_int is 74440, which way exceeds the platform maximum of 255. > The last_literal concerned is 0xFFFD. > > an_int_small_enough: PRECONDITION_VIOLATION raised (PRECONDITION_VIOLATION) > ------------------------------------------------------------------------------- > Class / Object Routine Nature of exception > Effect > ------------------------------------------------------------------------------- > KL_INTEGER_ROUTINES to_character @2 an_int_small_enough: > <00007F97C57775B8> Precondition violated. > Fail > ------------------------------------------------------------------------------- > ET_EIFFEL_PARSER last_c3_character_constant @8 > <00007F97C5A877B8> (From ET_EIFFEL_SCANNER_SKELETON) > Routine failure. > Fail > ------------------------------------------------------------------------------- Fixed. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2013-02-20 07:31:40
|
On 2/17/2013 7:15 PM, Colin Adams wrote: > I've bootstrapped gobo from git, and re-compiled from scratch. But my > program now suffers from an invariant violation when parsing the ECF. > Stack trace follows: > > secondary_settings_not_void: INVARIANT_VIOLATION raised > (INVARIANT_VIOLATION) > ------------------------------------------------------------------------------- > Class / Object Routine Nature of exception > Effect > ------------------------------------------------------------------------------- > ET_ECF_SETTINGS _invariant secondary_settings_not_void: > <00007F4B99A15D78> Class invariant violated. > Fail > ------------------------------------------------------------------------------- Fixed. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin A. <col...@gm...> - 2013-02-19 09:36:43
|
On 18 February 2013 17:21, Colin Adams <col...@gm...> wrote: > Having temporarily switched off invariant checking for the et_tools > cluster, I now get a precondition violation: > > The value of an_int is 74440, which way exceeds the platform maximum of > 255. > The last_literal concerned is 0xFFFD. > > an_int_small_enough: PRECONDITION_VIOLATION raised (PRECONDITION_VIOLATION) > > And if I bypass the precondition check, then the postcondition fails. |
|
From: Colin A. <col...@gm...> - 2013-02-18 17:21:56
|
On 17 February 2013 18:37, Eric Bezault <er...@go...> wrote:
> On 2/17/2013 7:15 PM, Colin Adams wrote:
>
>> I've bootstrapped gobo from git, and re-compiled from scratch. But my
>
> program now suffers from an invariant violation when parsing the ECF.
>> Stack trace follows:
>>
>
> I'll have a look at it.
>
> Having temporarily switched off invariant checking for the et_tools
cluster, I now get a precondition violation:
The value of an_int is 74440, which way exceeds the platform maximum of 255.
The last_literal concerned is 0xFFFD.
an_int_small_enough: PRECONDITION_VIOLATION raised (PRECONDITION_VIOLATION)
-------------------------------------------------------------------------------
Class / Object Routine Nature of exception
Effect
-------------------------------------------------------------------------------
KL_INTEGER_ROUTINES to_character @2 an_int_small_enough:
<00007F97C57775B8> Precondition violated.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER last_c3_character_constant @8
<00007F97C5A877B8> (From ET_EIFFEL_SCANNER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_DECORATED_AST_FACTORY
new_c3_character_constant @2
<00007F97C5DD4D78> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER process_break @6
<00007F97C5A877B8> (From ET_EIFFEL_SCANNER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER yy_execute_action @1098
<00007F97C5A877B8> (From ET_EIFFEL_SCANNER)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER read_token @134
<00007F97C5A877B8> (From ET_EIFFEL_SCANNER)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER yyparse @45
<00007F97C5A877B8> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER parse_file @16
<00007F97C5A877B8> (From ET_EIFFEL_PARSER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_EIFFEL_PARSER process_class @23
<00007F97C5A877B8> (From ET_EIFFEL_PARSER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_CLASS process @2
<00007F97C5A5BD18> Routine failure.
Fail
-------------------------------------------------------------------------------
PROCEDURE fast_call
<00007F97C5776F68> Routine failure.
Fail
-------------------------------------------------------------------------------
PROCEDURE call @5
<00007F97C5776F68> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_LIBRARY classes_do_if @11
<00007F97C5A46AB8> (From ET_UNIVERSE) Routine failure.
Fail
-------------------------------------------------------------------------------
PROCEDURE fast_call
<00007F97C5777228> Routine failure.
Fail
-------------------------------------------------------------------------------
PROCEDURE call @5
<00007F97C5777228> Routine failure.
Fail
-------------------------------------------------------------------------------
DS_HASH_SET do_all @5
<00007F97C57772E8> (From DS_SPARSE_CONTAINER)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM universes_do_recursive @4
<00007F97C5A4FEE8> (From ET_UNIVERSE) Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM classes_do_if_recursive_until @4
<00007F97C5A4FEE8> (From ET_UNIVERSE) Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM parse_system @15
<00007F97C5A4FEE8> (From ET_SYSTEM) Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM compile_system @9
<00007F97C5A4FEE8> (From ET_SYSTEM) Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM compile @7
<00007F97C5A4FEE8> (From ET_SYSTEM) Routine failure.
Fail
-------------------------------------------------------------------------------
CQS_CHECKER process_system @15
<00007F97C5A5BF88> Routine failure.
Fail
-------------------------------------------------------------------------------
CQS_CHECKER make @12
<00007F97C5A5BF88> Routine failure.
Fail
-------------------------------------------------------------------------------
CQS_CHECKER root's creation
<00007F97C5A5BF88> Routine failure.
Exit
-------------------------------------------------------------------------------
|
|
From: Eric B. <er...@go...> - 2013-02-17 20:34:22
|
On 2/17/2013 3:33 PM, Colin Adams wrote: > The errors that it finds are: > > 1 Syntax error: > Syntax error: > line 40 column 39 in > /home/colin/Eiffel72/library/base/elks/kernel/utf_converter.e > > escape_character: CHARACTER_32 = '%/0xFFFD/' > ^ > -- Unicode replacement character to escape > invalid UTF-8 or UTF-16 encoding. I think that this one is fixed in the Git repository of Gobo. > quite a lot of GVKBU-1 errors. E.g. > > > [GVKBU-1] class REAL_64_REF (78,2): unknown built-in routine > `positive_infinity' in class REAL_64_REF. Are you using gec? If so you need to use the version of FreeELKS that is in the Git repository of Gobo. If you are using gelint, then it should make no difference which version of FreeELKS you are using. You're better of using the version of Gobo from git, especially if you want to benefit from bug fixes that occurred after the official releases of EiffelStudio. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2013-02-17 18:55:06
|
On 2/17/2013 7:15 PM, Colin Adams wrote: > I am using ISE 7.2, not gec. I was not referring about the compiler you used to compile your program, but rather on which code your application is based. Never mind. > I've bootstrapped gobo from git, and re-compiled from scratch. But my > program now suffers from an invariant violation when parsing the ECF. > Stack trace follows: I'll have a look at it. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin A. <col...@gm...> - 2013-02-17 18:15:22
|
I am using ISE 7.2, not gec.
I've bootstrapped gobo from git, and re-compiled from scratch. But my
program now suffers from an invariant violation when parsing the ECF. Stack
trace follows:
secondary_settings_not_void: INVARIANT_VIOLATION raised
(INVARIANT_VIOLATION)
-------------------------------------------------------------------------------
Class / Object Routine Nature of exception
Effect
-------------------------------------------------------------------------------
ET_ECF_SETTINGS _invariant secondary_settings_not_void:
<00007F4B99A15D78> Class invariant violated.
Fail
-------------------------------------------------------------------------------
ET_ECF_SETTINGS _invariant
<00007F4B99A15D78> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SETTINGS make @4
<00007F4B99A15D78> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_TARGET make @5
<00007F4B99A15458> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_AST_FACTORY new_target @2
<00007F4B99147738> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM_PARSER
new_target @10
<00007F4B991476D8> (From ET_ECF_PARSER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM_PARSER
fill_system_config @19
<00007F4B991476D8> (From ET_ECF_PARSER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM_PARSER
new_system @13
<00007F4B991476D8> (From ET_ECF_PARSER_SKELETON)
Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM_PARSER
build_system_config @5
<00007F4B991476D8> Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM_PARSER
parse_file @15
<00007F4B991476D8> (From ET_ECF_PARSER) Routine failure.
Fail
-------------------------------------------------------------------------------
ET_ECF_SYSTEM_PARSER
parse_file @4
<00007F4B991476D8> Routine failure.
Fail
-------------------------------------------------------------------------------
CQS_CHECKER parse_ecf_file @10
<00007F4B99145F88> Routine failure.
Fail
-------------------------------------------------------------------------------
CQS_CHECKER make @8
<00007F4B99145F88> Routine failure.
Fail
-------------------------------------------------------------------------------
CQS_CHECKER root's creation
<00007F4B99145F88> Routine failure.
Exit
-------------------------------------------------------------------------------
On 17 February 2013 16:55, Eric Bezault <er...@go...> wrote:
> On 2/17/2013 3:33 PM, Colin Adams wrote:
>
>> The errors that it finds are:
>>
>> 1 Syntax error:
>> Syntax error:
>> line 40 column 39 in
>> /home/colin/Eiffel72/library/**base/elks/kernel/utf_**converter.e
>>
>> escape_character: CHARACTER_32 = '%/0xFFFD/'
>> ^
>> -- Unicode replacement character to escape
>> invalid UTF-8 or UTF-16 encoding.
>>
>
> I think that this one is fixed in the Git repository of Gobo.
>
>
> quite a lot of GVKBU-1 errors. E.g.
>>
>>
>> [GVKBU-1] class REAL_64_REF (78,2): unknown built-in routine
>> `positive_infinity' in class REAL_64_REF.
>>
>
> Are you using gec? If so you need to use the version of FreeELKS
> that is in the Git repository of Gobo.
> If you are using gelint, then it should make no difference which
> version of FreeELKS you are using.
>
> You're better of using the version of Gobo from git, especially if
> you want to benefit from bug fixes that occurred after the official
> releases of EiffelStudio.
>
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
|
36 messages has been excluded from this view by a project administrator.
