gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Can you send me the C code generated for T122f10? I don't
>     Eric> understand how we can have 35 seconds self and 7214 seconds
>     Eric> cumulative. Unless its thread is blocked when the GC is
>     Eric> doing something special on its own thread.
> 
> 
> /* DS_ARRAYED_LIST [INTEGER_32].item */
> T6 T122f10(T0* C, T6 a1)
> {
> 	T6 R = 0;
> 	R = (((T112*)(GE_void(((T122*)(C))->a2)))->z2[a1]);
> 	return R;
> }
> 

Hmmm, unless you have calls-on-void-target, GE_void is a macro
that does not call another function:

#define GE_void  (!(obj)?GE_check_void(obj):(obj))

So T122f10 does not call any other C function. So I would believe
that the values for self and cumulative should be the same.
The only explanation that I can think of is that the GC thread
is blocking the other thread while executing T12f10. I know
nothing about threads, and even less about how it works in the
Boehm GC, so what I just said might be completely stupid.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> Now my problem is what to do about it (incidentally T122f10 is
> {DS_ARRAYED_LIST}.item - nothing very surprising about that either, I
> guess.). Does anyone have any suggested approaches?

Can you send me the C code generated for T122f10? I don't understand
how we can have 35 seconds self and 7214 seconds cumulative. Unless
its thread is blocked when the GC is doing something special on its
own thread.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Emmanuel S. [ES] <ma...@ei...>]

> I used the profiler in EiffelStudio 6.1 (a run that normally 
> last 71 minutes when compiled with gec takes about 14 hours 
> when compiled with ISE 6.1 with the profiler on), and spent 

You should not enable profiler on all classes but just on yours. Then you
see much quickly where the bottleneck is on your code rather than trying to
profile STRING/ARRAY/ and other basic stuff which is not going to help you
much. Once you have identified the bottleneck you can try reduce the scope
of profiling to just the bottleneck.

Manu

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> So I edited $GOBO/tool/gec/config/c/gcc.cfg to write out profiling
> information for gprof (Eric, when can we have the setting of cflags
> and lflags in system.xace?).

It's already implemented as far as I know:

    <option name="c_compiler_options" value="..."/>
    <option name="link" value="..."/>

> Now my problem is what to do about it (incidentally T122f10 is
> {DS_ARRAYED_LIST}.item - nothing very surprising about that either, I
> guess.). Does anyone have any suggested approaches?

You can try reducing the amount of garbage generated, and hence
put less stress on the GC. I try to do that on all the Gobo tools,
even gec. This is one of my primary goals during the design phase.
The net advantage is that these tools can run even without the GC.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

I've spent the last three weekends making a serious attempt to get to
the bottom of the problem of quadratic performance in gexslt that has
been present ever since I first successfully ran an identity
transformation back in 2004.

I used the profiler in EiffelStudio 6.1 (a run that normally last 71
minutes when compiled with gec takes about 14 hours when compiled with
ISE 6.1 with the profiler on), and spent lots of time
following false leads (the report gives exact numbers for routine
calls, which is very useful, and nonsense for time spent e.g. 873.49%
for one routine, which is definitely not useful).

By this morning I had concluded there was nothing in my code that
could explain the results seen - or at least, if there was, I wasn't
going to be able to find it using the EiffelStudio profiler.

So I edited $GOBO/tool/gec/config/c/gcc.cfg to write out profiling
information for gprof (Eric, when can we have the setting of cflags
and lflags in system.xace?). The resulting runtime was 118 minutes - a
much more acceptable overhead. And the resulting report from gprof is
highly illuminating. here follows the first few lines:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 36.58   2943.00  2943.00                             GC_mark_from
 16.32   4256.06  1313.06                             GC_header_cache_miss
 13.18   5316.64  1060.58                             GC_mark_local
 10.57   6166.79   850.15                             GC_steal_mark_stack
  4.32   6514.36   347.57                             GC_add_to_black_list_stack
  1.55   6639.04   124.68                             GC_push_marked
  1.26   6740.27   101.23                             GC_find_header
  1.22   6838.10    97.83                             GC_reclaim_clear
  1.10   6926.51    88.41                             GC_do_local_mark
  0.82   6992.39    65.88                             GC_generic_malloc_many
  0.64   7044.16    51.77                             GC_block_was_dirty
  0.63   7095.09    50.93                             GC_install_header
  0.58   7141.48    46.39                             GC_apply_to_all_blocks
  0.47   7179.41    37.93                             GC_build_fl
  0.44   7214.44    35.03 530952040     0.00     0.00  T122f10
  0.40   7246.41    31.97                             GC_allochblk_nth
  0.29   7269.71    23.30                             GC_enclosing_mapping
  0.26   7290.70    20.99 262713928     0.00     0.00  T506f27
  0.25   7311.07    20.37                             GC_malloc
  0.25   7331.32    20.25 127354522     0.00     0.00  T162x16589
  0.22   7348.82    17.50                             GC_free_block_ending_at
  0.22   7366.13    17.31                             GC_malloc_atomic
  0.20   7382.11    15.99 3529690218     0.00     0.00  T240f8
  0.19   7397.55    15.44                             GC_reclaim_block
  0.18   7412.41    14.86                             GC_reclaim_uninit
  0.18   7427.16    14.75 529087403     0.00     0.00  T57f9
  0.18   7441.84    14.68 529541505     0.00     0.00  T15f4
  0.13   7452.31    10.47 2030496041     0.00     0.00  T240c7
  0.11   7461.08     8.77 105048154     0.00     0.00  T27f8
  0.10   7469.40     8.32 2049701317     0.00     0.00  GE_new239
  0.10   7477.42     8.02 7679890135     0.00     0.00  GE_check_null
  0.10   7485.32     7.90 172970992     0.00     0.00  T772f27p1
  0.10   7493.20     7.88 2049636054     0.00     0.00  GE_new240

in short, almost all the run time is for memory management (this did
not surprise me as typically I see the program using 125-290% CPU - I
have a quad-core processor, so fully utilized = 400% - and I
configured the boehm-gc for parallel marking).

Now my problem is what to do about it (incidentally T122f10 is
{DS_ARRAYED_LIST}.item - nothing very surprising about that either, I
guess.). Does anyone have any suggested approaches?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Eric B. <er...@go...>]

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Well, in fact to iterate only on keys I guess we can do
>     Eric> `my_table.keys.do_all'... So, we might need only two kinds of
>     Eric> iterators after all. What about `do_all' and
>     Eric> `do_all_with_key', the latter being similar to
>     Eric> `do_all_with_index'?
> 
> Or for_each which gives both item and key, and for_each_item which only
> does the item?
> 
> What I try to come up with is the shortest name, the default, for the
> most common method. And a slightly longer for the other.
> 
> Or else, a name with both key and item is longer, so make it the default
> when nothing is in the feature name, as it is really hard to indicate
> you get both, so you can put that in the comments.
> 
> And iterating while receiving a single feature is then simply
> for_each_item/for-each_key.

I think that we are better off using the same names as in EiffelBase.
EiffelBase uses `do_all' and `do_all_with_index'. I think that
`do_all_with_key' follows this pattern.

Also, if in linear we had `for_each' which gets the items, I would
not want that name to be changed to `for_each_item' in tables
or in arrays (so that `for_each' could now, inconsistently, get
items and keys in tables or items and indexes in arrays).

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Berend de B. <be...@po...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Well, in fact to iterate only on keys I guess we can do
    Eric> `my_table.keys.do_all'... So, we might need only two kinds of
    Eric> iterators after all. What about `do_all' and
    Eric> `do_all_with_key', the latter being similar to
    Eric> `do_all_with_index'?

Or for_each which gives both item and key, and for_each_item which only
does the item?

What I try to come up with is the shortest name, the default, for the
most common method. And a slightly longer for the other.

Or else, a name with both key and item is longer, so make it the default
when nothing is in the feature name, as it is really hard to indicate
you get both, so you can put that in the comments.

And iterating while receiving a single feature is then simply
for_each_item/for-each_key.

-- 
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Eric B. <er...@go...>]

Colin Adams wrote:
> On 20/03/2008, Eric Bezault <er...@go...> wrote:
> 
>> These feature names suggest that only the key is passed to the
>>  agent. I think that we need the three kinds of iterators:
>>  over the items, over the keys, and over both. The most difficult
>>  part is to find names. What about `do_all', `do_all_key' and
>>  `do_all_keyed'? Any better suggestion?
>>
>>  Well, in fact to iterate only on keys I guess we can do
>>  `my_table.keys.do_all'... So, we might need only two kinds of
>>  iterators after all. What about `do_all' and `do_all_with_key',
>>  the latter being similar to `do_all_with_index'?
> 
> Yes, that sounds the best compromise.
> 
>>  Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
>>  I don't remember why DS_TABLE is not linear, but I'm not
>>  currently in a mood to change that to make it linear.
> 
> There is nothing linear about for_all_with_keys and there_exists_with_keys.
> Do_all_with_index/do_if_with_index imply a linear ordering, so we
> won't want them in DS_TABLE.

I should have said that DS_TABLE is not a descendant of
DS_TRAVERSABLE (rather than a descendant of DS_LINEAR).

I would say that `do_all_with_index' belongs to DS_INDEXABLE.
It has been added to DS_LINEAR for convenience (perhaps
DS_LINEAR should have been a descendant of DS_INDEXABLE).

> I see no implied linearity with
> do_all_with_keys, do_if_with_keys (or for that matter do_all and
> do_if, just from the names). It all depends upon what the header
> comment says. So for do_all_with_keys we can just word the header
> comment to state that no particular order may be relied upon. Likewise
> for do_if_with_keys. 

If we follow the same reasoning, that `do_all', `there_exists',
etc. should be moved to DS_CONTAINER.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Colin A. <col...@go...>]

On 20/03/2008, Eric Bezault <er...@go...> wrote:

> These feature names suggest that only the key is passed to the
>  agent. I think that we need the three kinds of iterators:
>  over the items, over the keys, and over both. The most difficult
>  part is to find names. What about `do_all', `do_all_key' and
>  `do_all_keyed'? Any better suggestion?
>
>  Well, in fact to iterate only on keys I guess we can do
>  `my_table.keys.do_all'... So, we might need only two kinds of
>  iterators after all. What about `do_all' and `do_all_with_key',
>  the latter being similar to `do_all_with_index'?

Yes, that sounds the best compromise.

>  Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
>  I don't remember why DS_TABLE is not linear, but I'm not
>  currently in a mood to change that to make it linear.

There is nothing linear about for_all_with_keys and there_exists_with_keys.
Do_all_with_index/do_if_with_index imply a linear ordering, so we
won't want them in DS_TABLE. I see no implied linearity with
do_all_with_keys, do_if_with_keys (or for that matter do_all and
do_if, just from the names). It all depends upon what the header
comment says. So for do_all_with_keys we can just word the header
comment to state that no particular order may be relied upon. Likewise
for do_if_with_keys. Note that this will allow for concurrent
implementations using SCOOP or other concurrent technologies.

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Eric B. <er...@go...>]

Colin Adams wrote:
> Quite often I have a need to iterate over a DS_HASH_TABLE and inspect
> both the item and the key. Currently I have no choice but to use a
> cursor, as the features in the Iteration feature clause do not pass
> the key to the agent.

I sometimes have the same need.

> It would be nice to have do_all_key, do_if_key etc. where the agent
> receives both the item and the key. Ideally, these would be declared
> for DS_TABLE.

These feature names suggest that only the key is passed to the
agent. I think that we need the three kinds of iterators:
over the items, over the keys, and over both. The most difficult
part is to find names. What about `do_all', `do_all_key' and
`do_all_keyed'? Any better suggestion?

Well, in fact to iterate only on keys I guess we can do
`my_table.keys.do_all'... So, we might need only two kinds of
iterators after all. What about `do_all' and `do_all_with_key',
the latter being similar to `do_all_with_index'?

Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
I don't remember why DS_TABLE is not linear, but I'm not
currently in a mood to change that to make it linear.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Iterators for DS_TABLE?

[Colin A. <col...@go...>]

Quite often I have a need to iterate over a DS_HASH_TABLE and inspect
both the item and the key. Currently I have no choice but to use a
cursor, as the features in the Iteration feature clause do not pass
the key to the agent.

It would be nice to have do_all_key, do_if_key etc. where the agent
receives both the item and the key. Ideally, these would be declared
for DS_TABLE.

[gobo-eiffel-develop] Calculating Checksum in Eiffel

[Andreas L. <ale...@ra...>]

Hi all,

we need to calculate the checksum of a stream of characters. Basically
we would like to a quick way to check if two streams of characters are
he same. False positives are not a big deal, since we can always fall
back and compare the streams character for character (as long as it does
not happen too often).

Does anybody know if such an algorithm is already implemented somewhere
in Eiffel that we could use?

I only found Franck's library
(http://eiffelzone.com/esd/crc/index.html), but it is written against
TowerEiffel using BIT, both of which are no longer supported.

many thanks in advance,
Andreas

Re: [gobo-eiffel-develop] geant does not compile with ISE 5.7

[Jocelyn <li...@dj...>]

Hi sorry,

I have been quite inactive on Gobo those days.
I think this solution to have task being factory for themselves would be 
good.
If no one is against this, I'll try to find time to change that soon.

-- Jocelyn
ps: sorry for the trouble, I am not -yet- familiar with all the rules 
for Gobo's code.

On 3/2/2008 07:32 AM, Eric Bezault wrote:
> Eric Bezault wrote:
>   
>> Hi Jocelyn,
>>
>> Some of the modifications you made in geant don't compile with
>> ISE 5.7:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Error code: VTCG
>> Error: actual generic parameter does not conform to constraint.
>> What to do: make sure that actual parameter is a type conforming to the
>>   constraint (the type appearing after `->' for the corresponding formal).
>>
>> Class: GEANT_GROUP
>> Feature: invariant
>> In declaration: GEANT_TASK_BUILDER [GEANT_TASK]
>>
>> For type: GEANT_TASK_BUILDER [GEANT_TASK]
>> Argument number: 1:
>> Actual generic parameter: GEANT_TASK
>> Type to which it should conform: GEANT_TASK
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Can you implement it in some other way than using generic
>> constraint creation? I know that adding `make' as creation
>> procedure of GEANT_TASK would work, but I do believe that
>> GEANT_TASK should be declared as deferred anyway.
>>
>> As a matter of fact, I prefer the old way with the inspect
>> rather than relying on generic constraint creation to
>> implement a pseudo factory which is used in a single place
>> in a non-polymorphic way.
>>     
>
> One solution if you don't like inspect is to let GEANT_TASKs
> be factories of temselves. They could then be used in place
> of GEANT_TASK_BUILDER, and hence avoiding the problematic
> generic creation. It would work like `twin'. I'm not sure
> we can use `twin' directly because we expect `twin' to
> duplicate the data, whereas here we want them to be reset.
> But in that case there will be nothing to be reset if we
> use them properly (keep this set of task objects to create
> other task objects, but not to execute themselves as tasks).
>
>   

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> The difference between when it works and when it does not
>     Eric> work is not the fact that you use ePosix or not, but the
>     Eric> fact that you compile with the option "exception_trace" or
>     Eric> not. If you remove the option "exception_trace" from your
>     Eric> Xace file, gestalt should work without crashing.
> 
> It does. Well done.

It's now fixed in the new version of gec in SVN.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] status of agents

[Sven E. <sve...@we...>]

Eric Bezault wrote:
> Yes, we can now use Agents in Gobo. The restrictions depend
> on whether we will continue to support SE 1.2 or not.
> Colin's and my messages on SE 1.2 mailing list have received
> no answer for the past month.
> 
> If we still support SE 1.2, then the restrictions are that
> you need to pass manifest tuples when calling an Agent.
> And we should consider Agents as being novariant on the
> Tuple part (ECMA considers them covariantly and SE contravariantly).
> 

Thanks a lot for your answer.

- Sven

Re: [gobo-eiffel-develop] status of agents

[Eric B. <er...@go...>]

Sven Ehrke wrote:
> Hi Eric,
> 
> in the last two weeks I have been trying to simplify
> the way commands and tasks work together and have to be
> written in geant.
> 
> I think I found a quite nice solution but it makes
> use of agents.
> Having seen that KL_DIRECTORY uses them gives me some
> hope that geant could use them as well but I am still
> unsure if I can use them within gobo as this was not
> possible in the past.
> 
> I know that VE did not have support for agents but since
> gobo is not supporting it anymore I am not sure
> if SE is it which has not the full support for agents.
> 
> Could you tell me if it is possible to use agents within
> gobo and if, what the restrictions are?

Yes, we can now use Agents in Gobo. The restrictions depend
on whether we will continue to support SE 1.2 or not.
Colin's and my messages on SE 1.2 mailing list have received
no answer for the past month.

If we still support SE 1.2, then the restrictions are that
you need to pass manifest tuples when calling an Agent.
And we should consider Agents as being novariant on the
Tuple part (ECMA considers them covariantly and SE contravariantly).

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] status of agents

[Sven E. <sve...@we...>]

Hi Eric,

in the last two weeks I have been trying to simplify
the way commands and tasks work together and have to be
written in geant.

I think I found a quite nice solution but it makes
use of agents.
Having seen that KL_DIRECTORY uses them gives me some
hope that geant could use them as well but I am still
unsure if I can use them within gobo as this was not
possible in the past.

I know that VE did not have support for agents but since
gobo is not supporting it anymore I am not sure
if SE is it which has not the full support for agents.

Could you tell me if it is possible to use agents within
gobo and if, what the restrictions are?

Thank  you.

- Sven

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Colin P. A. <co...@co...>]

>>>>> "Emmanuel" == Emmanuel Stapf [ES] <ma...@ei...> writes:

    Emmanuel> Only when a lot of small functions are called where the
    Emmanuel> cost of recording outweight the computation. For
    Emmanuel> example, for the EiffelStudio compiler the slowdown is
    Emmanuel> between 5 to 25% depending on the platform

To be fair to Jann, he only said it was a high overhead. It was my
measurements on Gestalt on Linux 64-bit that indicated roughly double
elapsed time.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Emmanuel S. [ES] <ma...@ei...>]

> It's rather fortuitous that this came to light. Jann Roeder 
> pointed out to me that ISE-compiled programs run nearly twice 
> as slow with exception trace turned on. So I turned it off, 

Only when a lot of small functions are called where the cost of recording
outweight the computation. For example, for the EiffelStudio compiler the
slowdown is between 5 to 25% depending on the platform, strangely the
platform as a lot to do with this figure as one would expect the same
percentage on all the platforms since this is the same C code involved.

Manu

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> The difference between when it works and when it does not
    Eric> work is not the fact that you use ePosix or not, but the
    Eric> fact that you compile with the option "exception_trace" or
    Eric> not. If you remove the option "exception_trace" from your
    Eric> Xace file, gestalt should work without crashing.

It does. Well done.

It's rather fortuitous that this came to light. Jann Roeder pointed
out to me that ISE-compiled programs run nearly twice as slow with
exception trace turned on. So I turned it off, but I must have failed
to commit the change, or turned it back on again.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] geant does not compile with ISE 5.7

[Eric B. <er...@go...>]

Eric Bezault wrote:
> Hi Jocelyn,
> 
> Some of the modifications you made in geant don't compile with
> ISE 5.7:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Error code: VTCG
> Error: actual generic parameter does not conform to constraint.
> What to do: make sure that actual parameter is a type conforming to the
>   constraint (the type appearing after `->' for the corresponding formal).
> 
> Class: GEANT_GROUP
> Feature: invariant
> In declaration: GEANT_TASK_BUILDER [GEANT_TASK]
> 
> For type: GEANT_TASK_BUILDER [GEANT_TASK]
> Argument number: 1:
> Actual generic parameter: GEANT_TASK
> Type to which it should conform: GEANT_TASK
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Can you implement it in some other way than using generic
> constraint creation? I know that adding `make' as creation
> procedure of GEANT_TASK would work, but I do believe that
> GEANT_TASK should be declared as deferred anyway.
> 
> As a matter of fact, I prefer the old way with the inspect
> rather than relying on generic constraint creation to
> implement a pseudo factory which is used in a single place
> in a non-polymorphic way.

One solution if you don't like inspect is to let GEANT_TASKs
be factories of temselves. They could then be used in place
of GEANT_TASK_BUILDER, and hence avoiding the problematic
generic creation. It would work like `twin'. I'm not sure
we can use `twin' directly because we expect `twin' to
duplicate the data, whereas here we want them to be reset.
But in that case there will be nothing to be reset if we
use them properly (keep this set of task objects to create
other task objects, but not to execute themselves as tasks).

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Eric B. <er...@go...>]

Eric Bezault wrote:
> Colin Paul Adams wrote:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>       Eric>  Can you put some debug printing, as shown above, and
>>
>> Current = 1CDB9E0
>> Class ID = 350
>> Dispose = 7BE320
>>
>> Line 1
>> Segmentation fault
> 
> YEEEEEEEESSSSSSSSSS! Got it!
> 
> The difference between when it works and when it does not work
> is not the fact that you use ePosix or not, but the fact that
> you compile with the option "exception_trace" or not. If you remove
> the option "exception_trace" from your Xace file, gestalt should
> work without crashing. The signature of a function in exception
> trace mode is:
> 
> void T350f12(GE_call* ac, T0* C)
> 
> In non-trace mode it is:
> 
> void T350f12(T0* C)
> 
> Gec's mistake is to alway call the dispose routine with only
> one argument (the Current object being disposed), even in
> exception_trace mode.

I have to give up for tonight. I will fix gec tomorrow so that
it takes into account the fact that the exception_trace option
has been specified when calling the dispose feature.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>       Eric>  Can you put some debug printing, as shown above, and
> 
> Current = 1CDB9E0
> Class ID = 350
> Dispose = 7BE320
> 
> Line 1
> Segmentation fault

YEEEEEEEESSSSSSSSSS! Got it!

The difference between when it works and when it does not work
is not the fact that you use ePosix or not, but the fact that
you compile with the option "exception_trace" or not. If you remove
the option "exception_trace" from your Xace file, gestalt should
work without crashing. The signature of a function in exception
trace mode is:

void T350f12(GE_call* ac, T0* C)

In non-trace mode it is:

void T350f12(T0* C)

Gec's mistake is to alway call the dispose routine with only
one argument (the Current object being disposed), even in
exception_trace mode.

(FYI, exception_trace is only partially implement in gec, and
does not work yet.)

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> /* MANAGED_POINTER.dispose */
> void T350f12(GE_call* ac, T0* C)
> {
> 	GE_call tc = {0,0,ac};
> 	T1 t1;
> 	T14 l1 = 0;
fprintf(stderr, "Line 1\n");
> 	t1 = ((T1)(!(((T350*)(C))->a3)));
fprintf(stderr, "Line 2\n");
> 	if (t1) {
fprintf(stderr, "Line 3\n");
fprintf(stderr, "Item = %lX\n", ((T350*)(C))->a1);
> 		T14f8(&tc, &(((T350*)(C))->a1));
fprintf(stderr, "Line 4\n");
> 	}
fprintf(stderr, "Line 5\n");
> 	((T350*)(C))->a1 = l1;
fprintf(stderr, "Line 6\n");
> 	((T350*)(C))->a3 = EIF_FALSE;
fprintf(stderr, "Line 7\n");
> }

Can you put some debug printing, as shown above, and
recompile the C code (by running gestalt.sh for example)?
I want to see where it crashes. My guess is that it's
in T14f8.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

      Eric>  Can you put some debug printing, as shown above, and

Current = 1CDB9E0
Class ID = 350
Dispose = 7BE320

Line 1
Segmentation fault

-- 
Colin Adams
Preston Lancashire