gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

[Mark A. B. <mbo...@ar...>]

Let me just state that my note should have said: "I believe that this 
was introduced ...".

I really can't provide a definitive answer if it was in an earlier 
version. Is there a reason you can't simply use an external C routine to 
do the conversion, or does the 1.x series not have 64-bit types? (FWIW, 
the 1.x didn't have features I needed, so I used the early 2.x series. I 
eventually dropped SE support altogether after the split in the compiler 
camps over ECMA. Shame too, 'cause the SE generated code was 
significantly faster in my application).

Mark

Colin Adams wrote:
>> From: "Mark A. Bolstad" <mbo...@ar...>
>
>>> This appears to be a problem - ISE has truncated_to_integer64,
>>>     >> but SE doesn't. Is there a way round this?
>>>
>>>     Eric> I don't know. Does SE provide some other means to achieve
>>>     Eric> that?
>>>
>>> I can't find one. Does anyone else know?
>>>
>> There is a "force_to_integer_64" feature in REAL_64. This was 
>> introduced in the early 2 series.
>
> Then I guess that is evidence that there is no such feature in 1.1, 
> and therefore 1.2 also.
> So I have a major problem.
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>
>
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
> _________________________________________________________________
> The next generation of Hotmail is here!  http://www.newhotmail.co.uk
>

Re: [gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

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

>From: "Mark A. Bolstad" <mbo...@ar...>

>>This appears to be a problem - ISE has truncated_to_integer64,
>>     >> but SE doesn't. Is there a way round this?
>>
>>     Eric> I don't know. Does SE provide some other means to achieve
>>     Eric> that?
>>
>>I can't find one. Does anyone else know?
>>
>There is a "force_to_integer_64" feature in REAL_64. This was introduced in 
>the early 2 series.

Then I guess that is evidence that there is no such feature in 1.1, and 
therefore 1.2 also.
So I have a major problem.
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/


>_______________________________________________
>gobo-eiffel-develop mailing list
>gob...@li...
>https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

_________________________________________________________________
The next generation of Hotmail is here!  http://www.newhotmail.co.uk

Re: [gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

[Mark A. B. <mbo...@ar...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>>>>>             
>
>     Eric> Colin Paul Adams wrote:
>     >> This appears to be a problem - ISE has truncated_to_integer64,
>     >> but SE doesn't. Is there a way round this?
>
>     Eric> I don't know. Does SE provide some other means to achieve
>     Eric> that?
>
> I can't find one. Does anyone else know?
>   
There is a "force_to_integer_64" feature in REAL_64. This was introduced 
in the early 2 series.

[gobo-eiffel-develop] Manifest types

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

Hello,

Manifest types are now implemented in the Gobo compiler. Unfortunately
they  don't seem to be supported in SE 1.2, so we cannot use them in
the Gobo library classes.

I also changed the signature of ANY.generating_type to return
"TYPE [like Current]". There is an "automatic" conversion from
TYPE to STRING to allow a smooth transition.

Finally, I tried to make sure that at any given time, there is
no more than one instance of TYPE representing a given Eiffel type.
That way we can easily compare types using '='. Although this
decision  was the result of a discussion about FreeELKS with ISE,
be aware that this is not yet implemented in EiffelStudio. For
example:  {FOO} = {FOO}  will return False whereas it already
returns True when compiled with gec.

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

Re: [gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

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

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

    Eric> Colin Paul Adams wrote:
    >> This appears to be a problem - ISE has truncated_to_integer64,
    >> but SE doesn't. Is there a way round this?

    Eric> I don't know. Does SE provide some other means to achieve
    Eric> that?

I can't find one. Does anyone else know?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

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

Colin Paul Adams wrote:
> This appears to be a problem - ISE has truncated_to_integer64, but SE
> doesn't. Is there a way round this?

I don't know. Does SE provide some other means to achieve that?

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

Re: [gobo-eiffel-develop] Export status and cluster dependencies

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

Colin Paul Adams wrote:
>>>>>> "Paul-Georges" == CRISMER Paul-Georges <Pau...@gr...> writes:
> 
>     Paul-Georges> Hello Colin,
> 
>     Paul-Georges> In cluster math/decimal there is a class
>     Paul-Georges> MA_DECIMAL_HANDLER whose purpose is to allow
>     Paul-Georges> descendants to have access to MA_DECIMAL internals.
> 
>     Paul-Georges> You could make XM_XPATH_DECIMAL_VALUE inherit from
>     Paul-Georges> MA_DECIMAL_HANDLER.
> 
>     Paul-Georges> {MA_DECIMAL}.coefficient sould be exported to
>     Paul-Georges> MA_DECIMAL_HANDLER.
> 
> Actually, it is exported to:
> 
> {MA_DECIMAL, MA_DECIMAL_PARSER} 
> 
> and neither of these inherits from MA_DECIMAL_HANDLER.
> 
> Should I add MA_DECIMAL_HANDLER to the export list?

Yes.

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

[gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

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

This appears to be a problem - ISE has truncated_to_integer64, but SE
doesn't. Is there a way round this?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Export status and cluster dependencies

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

>>>>> "Paul-Georges" == CRISMER Paul-Georges <Pau...@gr...> writes:

    Paul-Georges> Hello Colin,

    Paul-Georges> In cluster math/decimal there is a class
    Paul-Georges> MA_DECIMAL_HANDLER whose purpose is to allow
    Paul-Georges> descendants to have access to MA_DECIMAL internals.

    Paul-Georges> You could make XM_XPATH_DECIMAL_VALUE inherit from
    Paul-Georges> MA_DECIMAL_HANDLER.

    Paul-Georges> {MA_DECIMAL}.coefficient sould be exported to
    Paul-Georges> MA_DECIMAL_HANDLER.

Actually, it is exported to:

{MA_DECIMAL, MA_DECIMAL_PARSER} 

and neither of these inherits from MA_DECIMAL_HANDLER.

Should I add MA_DECIMAL_HANDLER to the export list?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Extension to geyacc

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

Simon Hudon wrote:
> Dear M. Bezault,
> 
> I am currently considering the development of a compiler generator 
> toolkit for Eiffel a little like Cocktail 
> (http://www.cocolab.com/en/cocktail.html 
> <http://www.cocolab.com/en/cocktail.html>) and thought it may be 
> interesting to integrate it in the gobo package. 
> 
> I would use geyacc as a basis for lalr(1) parsers (which may be the only 
> kind I'd cover) and I plan to cover abstract grammars and attribute 
> grammars.  I may include some type system description utilities also.  
> The main interest in such a tool would be to exclude any target language 
> code in the specifications to allow the creation of different back ends 
> for different target languages.  I think this exclusion may also allow 
> more modular descriptions.
> 
> I plan to use this project as a basis for some research on compiler 
> synthesis.
> 
> In short, I was wondering if there is any interest on your part to 
> include such a toolkit in your gobo package and if there was any work in 
> that direction done on gobo or any plan to do any.
> 
> 
> Regards,
> 
> -- 
> Simon Hudon

This could be interesting indeed to extend geyacc in such a way.
As far as I know there is no work in that direction in Gobo.

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

Re: [gobo-eiffel-develop] GEC debugger requirements

[Paul C. <pac...@gm...>]

On 8/10/07, Wolfgang Jansen <wj...@so...> wrote:
> Paul Cohen wrote:
> > Ok. Couldn't batch mode (and reading commands from a file/stdin)
> > execution be implemented with not to much effort?
> >
> The debugger is CLI-based. Thus, interactive mode and batch mode
> by reading commands from stdin (and then from an arbitrary file)
> is not very different. The necessary changes/additions include
> - suppressing command prompts
> - redirecting debugger output to a file
> - stop after command error
> There is no problem to make the changes/additions.
>
> But is batch mode really of interest? To my experience,
> debugging will be done if the program does not what was expected,
> i.e. if there is a somewhat surprising outcome.
> Interactive mode is needed to react to unexpected behavior.

Debugging Eiffel wrappings of C code or problems with using C API:s
can be quite tricky at times. I have had cases where it would have
been nice to be able to quickly rerun a debugging session to see if I
get the same behaviour or not, without having to add debug trace
statements to the program. But you are right that having a CLI allows
you to give the debugger commands from stdin. Which is one of the many
benefits of having a CLI-based debugger!

> >
> >> - 3.1 to 3.14, 3.17, 3.18, 3.21,3.22 are available;
> >> - 3.15, 3.16 are not hard to implement. Whether
> >> to implement 3.19, 3.20 is a question of philosophy.
> >>
> >
> > I don't quite understand what you mean by philosophy. Are you saying
> > that editing program data during debugging can be seen as violating
> > some debugging principle or? I see them rather as power debugging
> > features.
> >
> Yes, philosophy means here that some people do not like to change
> program data during debugging.

Ok. I think I'm more pragmatic in this case.

> A viable approach in case of Eiffel
> may be as follows: changing an attribute value is allowed if the class
> of the enclosing object has been compiled with invariant checking on
> and if the invariant is still satisfied after the change.

Yes. That seems reasonable.

> There will be no restriction to change local variables.
> But what about routine arguments? The program must not change them,
> will the debugger be allowed to do so? (This is a secondary problem
> and may be discussed later.)
>

Ok. Obviously there are some issues that need to be resolved/decided
regarding the requirements on data editing. That is to say, if data
editing commands are to be added to the debugger at all. That is the
reason I listed those requirements as lower priority for now.

> I hope that you didn't misunderstand the role that the debugger
> plays in SE: it is not part of the official SE distribution.
> I made the offer to SE1.2 developers to add it to this
> compiler version, but I didn't get any answer so far.

I see. As I said before, I would welcome your debugger contribution to
Gobo very much!

/Paul

Re: [gobo-eiffel-develop] GEC debugger requirements

[Wolfgang J. <wj...@so...>]

Paul Cohen wrote:
> On 8/9/07, Howard Thomson <how...@di...> wrote:
>   
>> That is, the Eiffel system will be built with at least two threads, the
>> initial program entry point and first thread being a (possibly gui front
>> ended) debug and monitor thread which creates a second thread which starts in
>> the debugged system's root class and creation routine.
>>     
>
> I am strongly in favour of a CLI-based debugger. GUI frontends can
> later be added. Actually I would write a debugger API (.dll/.so) to
> ensure that any type of UI can be added later.
>
>   
>> Are you doing any development work yourself ?
>>     
>
> Not in Gobo. Due to my personal situation I just don't have that much
> time for spare time projects.
>
> On 8/9/07, Wolfgang Jansen <wj...@so...> wrote:
>   
>> Two or three weeks ago I offered to add (mutatis mutandis)
>> to GEC the debugger I developed for SE.
>>     
>
> Yes that would indeed be a great addition!
>
>   
>> The debugger is one of three possible additions.
>> The others are introspection and persistence closure.
>> Debugger and persistence closure depend on introspection,
>> and currently I'm still trying to add introspection.
>> In other words, adding the debugger will be not done
>> today or tomorrow.
>>     
>
> Ok.
>
>   
>> Which of your requirements are already satisfied?
>> - Not 1.* and 2.* since the debugger is not separate from
>> the debuggee (a situation like the SE debugger).
>> To satisfy the requirements needs much more
>> development and, as I think, has not the highest priority.
>>     
>
> Ok. Couldn't batch mode (and reading commands from a file/stdin)
> execution be implemented with not to much effort?
>   
The debugger is CLI-based. Thus, interactive mode and batch mode
by reading commands from stdin (and then from an arbitrary file)
is not very different. The necessary changes/additions include
- suppressing command prompts
- redirecting debugger output to a file
- stop after command error
There is no problem to make the changes/additions.

But is batch mode really of interest? To my experience, 
debugging will be done if the program does not what was expected,
i.e. if there is a somewhat surprising outcome.
Interactive mode is needed to react to unexpected behavior.
>   
>> - 3.1 to 3.14, 3.17, 3.18, 3.21,3.22 are available;
>> - 3.15, 3.16 are not hard to implement. Whether
>> to implement 3.19, 3.20 is a question of philosophy.
>>     
>
> I don't quite understand what you mean by philosophy. Are you saying
> that editing program data during debugging can be seen as violating
> some debugging principle or? I see them rather as power debugging
> features.
>   
Yes, philosophy means here that some people do not like to change
program data during debugging. A viable approach in case of Eiffel
may be as follows: changing an attribute value is allowed if the class
of the enclosing object has been compiled with invariant checking on
and if the invariant is still satisfied after the change.
There will be no restriction to change local variables.
But what about routine arguments? The program must not change them,
will the debugger be allowed to do so? (This is a secondary problem
and may be discussed later.)

In any case, the necessary actions (obtaining the new value as evaluation
of an expression, obtaining the variable's address, evaluating the class 
invariant)
have already been implemented as by-products of other commands.
>   
>> While not all of your requirements are satisfied,
>> some of the already implemented debugger commands
>> go far beyond, e.g. evaluation of not merely object values
>> but arbitrary expressions (which may include function calls)
>> and accompanying breakpoints with more sophisticated
>> conditions than just "class.feature name and line no".
>>     
>
> Excellent.
>
>   
>> PS:
>> The user's guide of the SE debugger.
>>     
>
> Thanks for the (obvoius) tip1 :-) I haven't used SmartEiffel for some years now.
>   
I hope that you didn't misunderstand the role that the debugger
plays in SE: it is not part of the official SE distribution.
I made the offer to SE1.2 developers to add it to this
compiler version, but I didn't get any answer so far.
> I would like to underline that my initial posting was intended to
> serve as input for you and others, like Howard who are interested in
> and have time and competence to develop a Gobo debugger.
>
> I would very much like to participate, but I don't have any experience
> in writing either compilers or debuggers and more importantly I don't
> have the spare time to learn or invest in this now. I will however
> really try to find time to test the debugger and discuss requirements
> from the perspective of a user.
>
> /Paul
>
>
>   


-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Bug in GEC ?

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

Wolfgang Jansen wrote:
> Hmm, besides the definition of `$' there is another
> argument in favour of the address of the entity.
> If `$' yields the entity address then
> the object address can be obtained via C code
>    *(void**)addr

Not if the attribute is expanded.

> The other way around, obtaining the entity address
> from the object address is not possible.
> Thus, the entity address carries more information.

I think that we need both forms.

> The unreferencing might be done by a feature of TYPE,
> but how can the reverse operation be accomplished?
> I do not know ISE's INTERNAL class very well
> but I doubt that there is a function that yields
> the entity address of a given reference object:

I want the entity address of the attribute "foo"
in object `x':

    $x + internal.field_offset (i, x)

where `i' is the index of the attribute `foo' in `x'
(`i' can be computed by other means in INTERNAL).
I agree that it ought to be easier to get this information
(with less computation), but it is possible to get it.

Anyway, as Howard mentioned, the goal of Gobo is not to make
things better but to be compatible with ISE.

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

Re: [gobo-eiffel-develop] Bug in GEC ?

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Howard Thomson wrote:
>   
>> Hi Wolfgang and Eric,
>>
>> According to ETL, the '$' operator applied to a non-constant feature should 
>> provide its POINTER address, such that when the pointer is passed to an 
>> external routine, that routine can modify the feature, probably returning a 
>> previously supplied value.
>>
>> Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
>> reference feature, the '$' operator as an equivalent of SmartEiffel's 
>> to_external concept to return the POINTER equivalent of the address of the 
>> referred-to object, which is what Eric has implemented to be compatible with 
>> ES 
>>     
>
> Yes. I think that the idea is that $ does not return the
> address of the attribute entity in the enclosing object,
> but the address of the attribute object. So if the attribute
> is expanded, the address of the object is indeed the same
> as the address of the attribute entity in the enclosing
> object. But for reference attributes, the address of the
> object is what is stored in the attribute entity. So, in
> a sense it is consistent between expanded and reference.
> It's just that it is returning the address of the attribute
> object and not the address of the attribute entity.
>
> I think that ISE gives access to the attribute entity
> address through its class INTERNAL. Because I want to
> implement features of INTERNAL in terms of features of
> class TYPE, I think that I will make this functionality
> available in class TYPE.
>
>   
Hmm, besides the definition of `$' there is another
argument in favour of the address of the entity.
If `$' yields the entity address then
the object address can be obtained via C code
    *(void**)addr
The other way around, obtaining the entity address
from the object address is not possible.
Thus, the entity address carries more information.

The unreferencing might be done by a feature of TYPE,
but how can the reverse operation be accomplished?
I do not know ISE's INTERNAL class very well
but I doubt that there is a function that yields
the entity address of a given reference object:
the best what the function can do is to return
the address of the object (as function argument) on stack.
This is quite meaningless after returning from
the function.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] GEC debugger requirements

[Paul C. <pac...@gm...>]

On 8/9/07, Howard Thomson <how...@di...> wrote:
> That is, the Eiffel system will be built with at least two threads, the
> initial program entry point and first thread being a (possibly gui front
> ended) debug and monitor thread which creates a second thread which starts in
> the debugged system's root class and creation routine.

I am strongly in favour of a CLI-based debugger. GUI frontends can
later be added. Actually I would write a debugger API (.dll/.so) to
ensure that any type of UI can be added later.

> Are you doing any development work yourself ?

Not in Gobo. Due to my personal situation I just don't have that much
time for spare time projects.

On 8/9/07, Wolfgang Jansen <wj...@so...> wrote:
> Two or three weeks ago I offered to add (mutatis mutandis)
> to GEC the debugger I developed for SE.

Yes that would indeed be a great addition!

> The debugger is one of three possible additions.
> The others are introspection and persistence closure.
> Debugger and persistence closure depend on introspection,
> and currently I'm still trying to add introspection.
> In other words, adding the debugger will be not done
> today or tomorrow.

Ok.

> Which of your requirements are already satisfied?
> - Not 1.* and 2.* since the debugger is not separate from
> the debuggee (a situation like the SE debugger).
> To satisfy the requirements needs much more
> development and, as I think, has not the highest priority.

Ok. Couldn't batch mode (and reading commands from a file/stdin)
execution be implemented with not to much effort?

> - 3.1 to 3.14, 3.17, 3.18, 3.21,3.22 are available;
> - 3.15, 3.16 are not hard to implement. Whether
> to implement 3.19, 3.20 is a question of philosophy.

I don't quite understand what you mean by philosophy. Are you saying
that editing program data during debugging can be seen as violating
some debugging principle or? I see them rather as power debugging
features.

> While not all of your requirements are satisfied,
> some of the already implemented debugger commands
> go far beyond, e.g. evaluation of not merely object values
> but arbitrary expressions (which may include function calls)
> and accompanying breakpoints with more sophisticated
> conditions than just "class.feature name and line no".

Excellent.

> PS:
> The user's guide of the SE debugger.

Thanks for the (obvoius) tip1 :-) I haven't used SmartEiffel for some years now.

I would like to underline that my initial posting was intended to
serve as input for you and others, like Howard who are interested in
and have time and competence to develop a Gobo debugger.

I would very much like to participate, but I don't have any experience
in writing either compilers or debuggers and more importantly I don't
have the spare time to learn or invest in this now. I will however
really try to find time to test the debugger and discuss requirements
from the perspective of a user.

/Paul

Re: [gobo-eiffel-develop] Bug in GEC ?

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

Howard Thomson wrote:
> Hi Wolfgang and Eric,
> 
> According to ETL, the '$' operator applied to a non-constant feature should 
> provide its POINTER address, such that when the pointer is passed to an 
> external routine, that routine can modify the feature, probably returning a 
> previously supplied value.
> 
> Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
> reference feature, the '$' operator as an equivalent of SmartEiffel's 
> to_external concept to return the POINTER equivalent of the address of the 
> referred-to object, which is what Eric has implemented to be compatible with 
> ES 

Yes. I think that the idea is that $ does not return the
address of the attribute entity in the enclosing object,
but the address of the attribute object. So if the attribute
is expanded, the address of the object is indeed the same
as the address of the attribute entity in the enclosing
object. But for reference attributes, the address of the
object is what is stored in the attribute entity. So, in
a sense it is consistent between expanded and reference.
It's just that it is returning the address of the attribute
object and not the address of the attribute entity.

I think that ISE gives access to the attribute entity
address through its class INTERNAL. Because I want to
implement features of INTERNAL in terms of features of
class TYPE, I think that I will make this functionality
available in class TYPE.

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

Re: [gobo-eiffel-develop] Bug in GEC ?

[Wolfgang J. <wj...@so...>]

Howard Thomson wrote:
> Hi Wolfgang and Eric,
>
> According to ETL, the '$' operator applied to a non-constant feature should 
> provide its POINTER address, such that when the pointer is passed to an 
> external routine, that routine can modify the feature, probably returning a 
> previously supplied value.
>
> Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
> reference feature, the '$' operator as an equivalent of SmartEiffel's 
> to_external concept to return the POINTER equivalent of the address of the 
> referred-to object, which is what Eric has implemented to be compatible with 
> ES -- which in my opionion is a pain for both implementations.
>
> Eric will no doubt expound on it.
>
> Just my .0.2c ...
>
> Howard
>
> On Thursday 09 August 2007 15:40, Wolfgang Jansen wrote:
>   
>> Hi Eric,
>>
>> lets consider the program splitter
>>
>>    p1 := $ref_attr
>>    p2 := $int_attr
>>
>> where `p1',`p2' are POINTERS, `ref_attr' is
>> an attribute of a reference type,
>> and `int_attr' is an INTEGER attribute.
>>
>> The effect is that `p2' is set with the address
>> of `int_attr' within `Current'. But `p1' is not
>> set with the address of `ref_attr', instead `p1'
>> is set with the value of `ref_attr' itself.
>>
>> Is this a bug, or did I misunderstand the
>> definition of the `$' operator ?
>>
>> WJ
>>     
>
>   
Thanks for clarifying the point.
So, I will have to live with it.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Bug in GEC ?

[Howard T. <how...@di...>]

Hi Wolfgang and Eric,

According to ETL, the '$' operator applied to a non-constant feature should 
provide its POINTER address, such that when the pointer is passed to an 
external routine, that routine can modify the feature, probably returning a 
previously supplied value.

Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
reference feature, the '$' operator as an equivalent of SmartEiffel's 
to_external concept to return the POINTER equivalent of the address of the 
referred-to object, which is what Eric has implemented to be compatible with 
ES -- which in my opionion is a pain for both implementations.

Eric will no doubt expound on it.

Just my .0.2c ...

Howard

On Thursday 09 August 2007 15:40, Wolfgang Jansen wrote:
> Hi Eric,
>
> lets consider the program splitter
>
>    p1 := $ref_attr
>    p2 := $int_attr
>
> where `p1',`p2' are POINTERS, `ref_attr' is
> an attribute of a reference type,
> and `int_attr' is an INTEGER attribute.
>
> The effect is that `p2' is set with the address
> of `int_attr' within `Current'. But `p1' is not
> set with the address of `ref_attr', instead `p1'
> is set with the value of `ref_attr' itself.
>
> Is this a bug, or did I misunderstand the
> definition of the `$' operator ?
>
> WJ

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

[gobo-eiffel-develop] Bug in GEC ?

[Wolfgang J. <wj...@so...>]

Hi Eric,

lets consider the program splitter

   p1 := $ref_attr
   p2 := $int_attr

where `p1',`p2' are POINTERS, `ref_attr' is
an attribute of a reference type,
and `int_attr' is an INTEGER attribute.

The effect is that `p2' is set with the address
of `int_attr' within `Current'. But `p1' is not
set with the address of `ref_attr', instead `p1'
is set with the value of `ref_attr' itself.

Is this a bug, or did I misunderstand the
definition of the `$' operator ?

WJ

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] GEC debugger requirements

[Wolfgang J. <wj...@so...>]

Howard Thomson wrote:
> Hi Paul,
>
> I am working on EDP, an IDE based on the Gobo tools and the infrastructure 
> used to build GEC, and have also been thinking about how to debug, trace, 
> probe, etc an executing Eiffel system.
>
> As the intricacies of inter-process debugging are so arcane and (in my 
> opinion) poorly documented, and of course totally incompatible between Linux 
> and Win32, I am intending that debugging be done in-process.
>
> That is, the Eiffel system will be built with at least two threads, the 
> initial program entry point and first thread being a (possibly gui front 
> ended) debug and monitor thread which creates a second thread which starts in 
> the debugged system's root class and creation routine.
>
> The primary difficulty with such a system is the interaction with the C 
> runtime library and the aspects of a process that are process-wide rather 
> than thread specific, such as file handles (!).
>
> As in SE, debug generated code will have code that updates the current stack 
> frame with the POSITION of the about-to-be-executed INSTRUCTION, and code to 
> test for thread-suspension etc.
>
> A posting was recently made about some code to do something similar, 
> previously implemented for SE, which may be adaptable.
>   
Yes, see below.
> But first, I need some thread building blocks to work on.
>
> I am currently working towards making EDP compilable by EiffelStudio at which 
> point I can refer to it from EiffelRoom and start to get other people 
> interested (possibly !).
>
> Are you doing any development work yourself ?
>
> Regards,
>
> Howard
>
> On Wednesday 08 August 2007 22:20, Paul Cohen wrote:
>   
>> Hi all,
>>
>> I am not an expert in writing compilers or debuggers but I would like
>> to propose a list of requirements for the GEC debugger.
>>
>> I have rated the requirements with a two graded priority scale
>> indicated by the presence of a '*'. Any requirement marked with a '*'
>> I consider lower priority. Of course, eventually I would like all
>> requirements to be implemented! ;-)
>>
>> 1. Assumptions
>> ------------------------
>>
>> 1.1 GEC can be run with some debug flag enabling the compiled program
>> to be run by the GEC debugger,
>> 1.2 The GEC debugger has a nice name or acronym like "gedb" so that I
>> don't have to write "GEC debugger" all the time!
>>
>> 2. General requirements
>> --------------------------------------
>>
>> 2,1 Command line debugger in gdb style.
>> 2.2 Default execution mode is interactive.
>> 2.3 Switch for telling which executable to load.
>> 2.4* Switch for running in batch mode. When running in batch mode a
>> file (or stdin) containing debugger commands is read and the debugger
>> executes the
>> commands in straight sequence as if they had been manually entered in
>> interactive mode.
>>
>> 3. Debugger commands
>> -------------------------------------
>>
>> Commands are run by entering them on the gedb prompt. Commands that
>> take arguments have the arguments enclosed in brackets '['  and ']'.
>> Commands should have abbreviated short forms like 'r' for run etc.
>>
>> 3.1 Help. Print info on available commands.
>> 3.2 Run.
>> 3.3 Single step to next execution point.
>> 3.4 Step over to next execution point in current feature.
>> 3.5 Step out of current feature.
>> 3.6 Show info on loaded executable (compile time, compile flags etc.).
>> 3.7 Show stack.
>> 3.8 Show Eiffel text [lines] of n lines surrounding current execution
>> point. 3.9 Show locals.
>> 3.10 Show object [id] (current object if id not given).
>> 3.11 Quit.
>> 3.12 Set breakpoint [class.feature name and line no]. If no
>> class.feature name and line no is given, set breakpoint at current
>> execution point.
>> 3.13 Show breakpoints (together with unique breakpoint id:s).
>> 3.14 Delete breakpoint [breakpoint id].
>> 3.15 Save breakpoints to file.
>> 3.16 Load breakpoints from file.
>> 3.17 Terminate execution.
>> 3.18* Stop execution. Not a proper command, but some way to generate
>> an interrupt and stop the current execution (at some execution point
>> after which one can continue step debugging the program).
>> 3.19* Edit local entity [name and value].
>> 3.20* Edit object [id] [attribute/once name, value]. (current object if no
>> id) 3.21* Set conditional breakpoint [class.feature name and line no]. If
>> no class.feature name and line no is given, set breakpoint at current
>> execution point. A new prompt is displayed where the condition can be
>> expressed.
>> 3.22* Show object info [type/class]. Show number of objects of a given
>> type (or class) together with other interesting info. If no type/class
>> is given show summary stats for all objects in executed system.
>> 3.23* Show GC info. Show number of objects that have been garbage
>> collected and other exciting GC info.
>>
>> /Paul
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>     
Two or three weeks ago I offered to add (mutatis mutandis)
to GEC the debugger I developed for SE.
The debugger is one of three possible additions.
The others are introspection and persistence closure.
Debugger and persistence closure depend on introspection,
and currently I'm still trying to add introspection.
In other words, adding the debugger will be not done
today or tomorrow.

Which of your requirements are already satisfied?
- Not 1.* and 2.* since the debugger is not separate from
the debuggee (a situation like the SE debugger).
To satisfy the requirements needs much more
development and, as I think, has not the highest priority.
- 3.1 to 3.14, 3.17, 3.18, 3.21,3.22 are available;
- 3.15, 3.16 are not hard to implement. Whether
to implement 3.19, 3.20 is a question of philosophy.

While not all of your requirements are satisfied,
some of the already implemented debugger commands
go far beyond, e.g. evaluation of not merely object values
but arbitrary expressions (which may include function calls)
and accompanying breakpoints with more sophisticated
conditions than just "class.feature name and line no".

WJ

PS:
The user's guide of the SE debugger.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] GEC debugger requirements

[Howard T. <how...@di...>]

Hi Paul,

I am working on EDP, an IDE based on the Gobo tools and the infrastructure 
used to build GEC, and have also been thinking about how to debug, trace, 
probe, etc an executing Eiffel system.

As the intricacies of inter-process debugging are so arcane and (in my 
opinion) poorly documented, and of course totally incompatible between Linux 
and Win32, I am intending that debugging be done in-process.

That is, the Eiffel system will be built with at least two threads, the 
initial program entry point and first thread being a (possibly gui front 
ended) debug and monitor thread which creates a second thread which starts in 
the debugged system's root class and creation routine.

The primary difficulty with such a system is the interaction with the C 
runtime library and the aspects of a process that are process-wide rather 
than thread specific, such as file handles (!).

As in SE, debug generated code will have code that updates the current stack 
frame with the POSITION of the about-to-be-executed INSTRUCTION, and code to 
test for thread-suspension etc.

A posting was recently made about some code to do something similar, 
previously implemented for SE, which may be adaptable.

But first, I need some thread building blocks to work on.

I am currently working towards making EDP compilable by EiffelStudio at which 
point I can refer to it from EiffelRoom and start to get other people 
interested (possibly !).

Are you doing any development work yourself ?

Regards,

Howard

On Wednesday 08 August 2007 22:20, Paul Cohen wrote:
> Hi all,
>
> I am not an expert in writing compilers or debuggers but I would like
> to propose a list of requirements for the GEC debugger.
>
> I have rated the requirements with a two graded priority scale
> indicated by the presence of a '*'. Any requirement marked with a '*'
> I consider lower priority. Of course, eventually I would like all
> requirements to be implemented! ;-)
>
> 1. Assumptions
> ------------------------
>
> 1.1 GEC can be run with some debug flag enabling the compiled program
> to be run by the GEC debugger,
> 1.2 The GEC debugger has a nice name or acronym like "gedb" so that I
> don't have to write "GEC debugger" all the time!
>
> 2. General requirements
> --------------------------------------
>
> 2,1 Command line debugger in gdb style.
> 2.2 Default execution mode is interactive.
> 2.3 Switch for telling which executable to load.
> 2.4* Switch for running in batch mode. When running in batch mode a
> file (or stdin) containing debugger commands is read and the debugger
> executes the
> commands in straight sequence as if they had been manually entered in
> interactive mode.
>
> 3. Debugger commands
> -------------------------------------
>
> Commands are run by entering them on the gedb prompt. Commands that
> take arguments have the arguments enclosed in brackets '['  and ']'.
> Commands should have abbreviated short forms like 'r' for run etc.
>
> 3.1 Help. Print info on available commands.
> 3.2 Run.
> 3.3 Single step to next execution point.
> 3.4 Step over to next execution point in current feature.
> 3.5 Step out of current feature.
> 3.6 Show info on loaded executable (compile time, compile flags etc.).
> 3.7 Show stack.
> 3.8 Show Eiffel text [lines] of n lines surrounding current execution
> point. 3.9 Show locals.
> 3.10 Show object [id] (current object if id not given).
> 3.11 Quit.
> 3.12 Set breakpoint [class.feature name and line no]. If no
> class.feature name and line no is given, set breakpoint at current
> execution point.
> 3.13 Show breakpoints (together with unique breakpoint id:s).
> 3.14 Delete breakpoint [breakpoint id].
> 3.15 Save breakpoints to file.
> 3.16 Load breakpoints from file.
> 3.17 Terminate execution.
> 3.18* Stop execution. Not a proper command, but some way to generate
> an interrupt and stop the current execution (at some execution point
> after which one can continue step debugging the program).
> 3.19* Edit local entity [name and value].
> 3.20* Edit object [id] [attribute/once name, value]. (current object if no
> id) 3.21* Set conditional breakpoint [class.feature name and line no]. If
> no class.feature name and line no is given, set breakpoint at current
> execution point. A new prompt is displayed where the condition can be
> expressed.
> 3.22* Show object info [type/class]. Show number of objects of a given
> type (or class) together with other interesting info. If no type/class
> is given show summary stats for all objects in executed system.
> 3.23* Show GC info. Show number of objects that have been garbage
> collected and other exciting GC info.
>
> /Paul
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

[gobo-eiffel-develop] GEC debugger requirements

[Paul C. <pac...@gm...>]

Hi all,

I am not an expert in writing compilers or debuggers but I would like
to propose a list of requirements for the GEC debugger.

I have rated the requirements with a two graded priority scale
indicated by the presence of a '*'. Any requirement marked with a '*'
I consider lower priority. Of course, eventually I would like all
requirements to be implemented! ;-)

1. Assumptions
------------------------

1.1 GEC can be run with some debug flag enabling the compiled program
to be run by the GEC debugger,
1.2 The GEC debugger has a nice name or acronym like "gedb" so that I
don't have to write "GEC debugger" all the time!

2. General requirements
--------------------------------------

2,1 Command line debugger in gdb style.
2.2 Default execution mode is interactive.
2.3 Switch for telling which executable to load.
2.4* Switch for running in batch mode. When running in batch mode a
file (or stdin) containing debugger commands is read and the debugger
executes the
commands in straight sequence as if they had been manually entered in
interactive mode.

3. Debugger commands
-------------------------------------

Commands are run by entering them on the gedb prompt. Commands that
take arguments have the arguments enclosed in brackets '['  and ']'.
Commands should have abbreviated short forms like 'r' for run etc.

3.1 Help. Print info on available commands.
3.2 Run.
3.3 Single step to next execution point.
3.4 Step over to next execution point in current feature.
3.5 Step out of current feature.
3.6 Show info on loaded executable (compile time, compile flags etc.).
3.7 Show stack.
3.8 Show Eiffel text [lines] of n lines surrounding current execution point.
3.9 Show locals.
3.10 Show object [id] (current object if id not given).
3.11 Quit.
3.12 Set breakpoint [class.feature name and line no]. If no
class.feature name and line no is given, set breakpoint at current
execution point.
3.13 Show breakpoints (together with unique breakpoint id:s).
3.14 Delete breakpoint [breakpoint id].
3.15 Save breakpoints to file.
3.16 Load breakpoints from file.
3.17 Terminate execution.
3.18* Stop execution. Not a proper command, but some way to generate
an interrupt and stop the current execution (at some execution point
after which one can continue step debugging the program).
3.19* Edit local entity [name and value].
3.20* Edit object [id] [attribute/once name, value]. (current object if no id)
3.21* Set conditional breakpoint [class.feature name and line no]. If
no class.feature name and line no is given, set breakpoint at current
execution point. A new prompt is displayed where the condition can be
expressed.
3.22* Show object info [type/class]. Show number of objects of a given
type (or class) together with other interesting info. If no type/class
is given show summary stats for all objects in executed system.
3.23* Show GC info. Show number of objects that have been garbage
collected and other exciting GC info.

/Paul

Re: [gobo-eiffel-develop] Introspection, persistence, debugger

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> Eric Bezault wrote:
>>> For the sake of interoperability, I think that the gap to be closed
>>> in terms of introspection should be addressed by ECMA and FreeELKS
>>> first. So I would suggest that you submit your introspection library
>>> interface to FreeELKS so that all compilers supporting FreeELKS can
>>> agree to support it. Then we can safely integrate it to gec without
>>> breaking interoperability.
>>>
>> Well, that's an idea. But don't believe that standardizing consorts
>> are interested: the stuff provides an implementation of
>> introspection etc. but no new concept.
>
> Standardization does not mean finding new concepts but agreeing
> on something that everyone should follow, even if that something
> already exists.
>
> Do you want me to send a message to the FreeELKS mailing list to
> see if people involved in FreeELKS are interested in a standardized
> form of introspection and if yes, if your solution could be
> acceptable by everyone?
>
Yes, this would be very kind. But wait some time
until I implemented the stuff (or at least the core part)
in GEC. Experience of working with two compilers
will make, as I hope, things more streamlined.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] svn compile failure

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

Howard Thomson wrote:
> I just did an svn update, to revision 6039, and attempted to build gec and had 
> a reported error:
> 
> In class UC_UTF8_STRING, the creation routines make_from_utf16le and 
> make_from_utf16be are 'not the final names of a procedure'.

For this one, you need to run 'geant install', as
explained in $GOBO/work/bootstrap/Readme.txt.

> Removing them from the create clause of that class resulted in a successful 
> Eiffel compile, but C compile fails for reasons that are less obvious, except 
> that I haven't yet done a bootstrap build which may fix it.

For this one, you need to run bootstrap.

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

[gobo-eiffel-develop] svn compile failure

[Howard T. <how...@di...>]

Hi all,

I just did an svn update, to revision 6039, and attempted to build gec and had 
a reported error:

In class UC_UTF8_STRING, the creation routines make_from_utf16le and 
make_from_utf16be are 'not the final names of a procedure'.

Removing them from the create clause of that class resulted in a successful 
Eiffel compile, but C compile fails for reasons that are less obvious, except 
that I haven't yet done a bootstrap build which may fix it.

Regards

Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein