gobo-eiffel-develop

[gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

Hi All,

A recent change in YY_COMPRESSED_SCANNER_SKELETON requires that
yy_content_area be set. Unfortunately I relied on the fact you didn't
need to set it, so I could avoid a large memory copy.

I'm not yet sure what to do. What I really need is a SPECIAL with a
valid base_address, but can I rely on ISE Eiffel not to move this? I'm
afraid I can't.

Another solution is if my C malloc wrapper (STDC_BUFFER) implements
ABSTRACT_SPECIAL, so that would require
YY_SCANNER_SKELETON.yy_content_area to be changed to use
ABSTRACT_SPECIAL.

Any thoughts?

So the goal is to run the scanner/parser straight from a malloc
buffer, which used to work.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

> So the goal is to run the scanner/parser straight from a malloc
> buffer, which used to work.

Having done many C/Eiffel interfaces I consider this as being dangerous to do. And
why when using SPECIAL do you want to pass this to the C side? Is the C code doing
to do some processing over the data?

Regards,
Manu

Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

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

    >> So the goal is to run the scanner/parser straight from a malloc
    >> buffer, which used to work.

    Emmanuel> Having done many C/Eiffel interfaces I consider this as
    Emmanuel> being dangerous to do. And why when using SPECIAL do you
    Emmanuel> want to pass this to the C side? Is the C code doing to
    Emmanuel> do some processing over the data?

Nah, it's just the other way around. The data is in a malloc buffer,
and needs to be parsed by YY_PARSER. Previously one could write a
wrapper where data was picked up from such buffer. Now Gobo requires
that it is in a SPECIAL or descendant.

So I'm just trying to see if I can skip this copy or make it faster.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

Berend de Boer wrote:
>>>>>> "Emmanuel" == Emmanuel Stapf [ES] <ma...@ei...> writes:
> 
>     >> So the goal is to run the scanner/parser straight from a malloc
>     >> buffer, which used to work.
> 
>     Emmanuel> Having done many C/Eiffel interfaces I consider this as
>     Emmanuel> being dangerous to do. And why when using SPECIAL do you
>     Emmanuel> want to pass this to the C side? Is the C code doing to
>     Emmanuel> do some processing over the data?
> 
> Nah, it's just the other way around. The data is in a malloc buffer,
> and needs to be parsed by YY_PARSER. Previously one could write a
> wrapper where data was picked up from such buffer. Now Gobo requires
> that it is in a SPECIAL or descendant.

In my mind, it has always been clear that we should use SPECIAL
for efficency reason. The reason why this could be bypassed is
that at the time of writing some of the supported Eiffel compilers
did not support SPECIAL. Using ABSTRACT_SPECIAL is not really
a solution because it introduces polymorphism, hence reducing
the performance that we want to gain by using SPECIAL directly.

YY_SCANNER_SKELETON has been changed in such as way because during
the current migration to void-safety KI_CHARACTER_BUFFER.as_special
has been turned to return a non-void SPECIAL. I think that the problem
comes from here. Your version of class buffer is now likely to
violate this new postcondition in `as_special'.

I'll see what I can do to revert this change. I must say that I'm
not a fan of all this void-safety thing. For code that was well
equipped with assertions like the Gobo libraries, converting to
void-safety makes the code more convoluted, hence harder to read
and maintain.

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

Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

Eric Bezault wrote:
> YY_SCANNER_SKELETON has been changed in such as way because during
> the current migration to void-safety KI_CHARACTER_BUFFER.as_special
> has been turned to return a non-void SPECIAL. I think that the problem
> comes from here. Your version of class buffer is now likely to
> violate this new postcondition in `as_special'.
> 
> I'll see what I can do to revert this change. I must say that I'm
> not a fan of all this void-safety thing. For code that was well
> equipped with assertions like the Gobo libraries, converting to
> void-safety makes the code more convoluted, hence harder to read
> and maintain.

KI_CHARACTER_BUFFER.as_special can now be void, as it used to be.
The scanner skeleton classes have been updated accordingly.

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

Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

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

    Eric> In my mind, it has always been clear that we should use
    Eric> SPECIAL for efficency reason. The reason why this could be
    Eric> bypassed is that at the time of writing some of the
    Eric> supported Eiffel compilers did not support SPECIAL. Using
    Eric> ABSTRACT_SPECIAL is not really a solution because it
    Eric> introduces polymorphism, hence reducing the performance that
    Eric> we want to gain by using SPECIAL directly.

But with SPECIAL comes the need for a copy. Which is a bit slow
especially in debug mode. It's not a huge problem, but it would be
nice if SPECIAL had a fast way to copy data from a given pointer.


    Eric> YY_SCANNER_SKELETON has been changed in such as way because
    Eric> during the current migration to void-safety
    Eric> KI_CHARACTER_BUFFER.as_special has been turned to return a
    Eric> non-void SPECIAL. I think that the problem comes from
    Eric> here. Your version of class buffer is now likely to violate
    Eric> this new postcondition in `as_special'.

Indeed, saw the comment and I indeed inherit from KI_CHARACTER_BUFFER.


    Eric> I'll see what I can do to revert this change. I must say
    Eric> that I'm not a fan of all this void-safety thing. For code
    Eric> that was well equipped with assertions like the Gobo
    Eric> libraries, converting to void-safety makes the code more
    Eric> convoluted, hence harder to read and maintain.

Interesting perspective.

But I suppose it's a hard call. Without SPECIAL reading from the might
be a bit slower, but if you need t copy to special first + read
from SPECIAL I think the overall case has become a bit slower.
-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

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

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> In my mind, it has always been clear that we should use
>     Eric> SPECIAL for efficency reason. The reason why this could be
>     Eric> bypassed is that at the time of writing some of the
>     Eric> supported Eiffel compilers did not support SPECIAL. Using
>     Eric> ABSTRACT_SPECIAL is not really a solution because it
>     Eric> introduces polymorphism, hence reducing the performance that
>     Eric> we want to gain by using SPECIAL directly.
> 
> But with SPECIAL comes the need for a copy. Which is a bit slow
> especially in debug mode. It's not a huge problem, but it would be
> nice if SPECIAL had a fast way to copy data from a given pointer.

In all cases that I had so far, there was no need to copy to a
SPECIAL because the SPECIAL was already available. Hence the
optimization. I had not faced the problem you have with a pointer
because I always try to write pure Eiffel, hence no pointer to
deal with.

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