gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Comments in KI_BUFFER

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

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Adams <col...@go...> writes:
> 
>     Colin> On 17/01/2008, Eric Bezault <er...@go...> wrote:
>     >> Should we decide now that SE 1.2 is not supported anymore, and
>     >> let the job to the possible future maintainers of SE 1.2 to
>     >> adapt it so that it can compile the Gobo project? After all,
>     >> that's what I'm currently doing with 'gec': I adapt it so that
>     >> it can compile Eiffel libraries other than those from Gobo,
>     >> such as EiffelBase, EiffelVision2, etc
> 
>     Colin> I would say yes.
> 
> Now Daniel has released SE 1.2r8 and is soliciting comments about the
> direction people want it to go, I'm not so sure.

You might want to ask Daniel about the functionalities from
FreeELKS's UNIX_FILE_INFO that you need in your classes.
Or are they already available in one way or another in SE's
kernel library classes?

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

Re: [gobo-eiffel-develop] Comments in KI_BUFFER

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

>>>>> "Colin" == Colin Adams <col...@go...> writes:

    Colin> On 17/01/2008, Eric Bezault <er...@go...> wrote:
    >> Should we decide now that SE 1.2 is not supported anymore, and
    >> let the job to the possible future maintainers of SE 1.2 to
    >> adapt it so that it can compile the Gobo project? After all,
    >> that's what I'm currently doing with 'gec': I adapt it so that
    >> it can compile Eiffel libraries other than those from Gobo,
    >> such as EiffelBase, EiffelVision2, etc

    Colin> I would say yes.

Now Daniel has released SE 1.2r8 and is soliciting comments about the
direction people want it to go, I'm not so sure.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     >> So I should wrap a C library then?
> 
> I wasn't actually serious about that

Yes, I knew that you would prefer assembly code ;-)

> 
>     Eric> What I had in mind is more something like EiffelParse
>     Eric> vs. geyacc.
> 
> Can you expand on that statement please?

I don't know the current status, but 10 years ago using
EiffelParse to write parsers (yooc was there to help) produced
very slow parsers. EiffelParse has a very nice object-oriented
design for the parser implementation. I don't know if it's
related on not, but it's slow.

On the other hand, geyacc was written to produce ugly
non-object-oriented parsers, based on zillions of integers
put in tables or used in inspect statement. The resulting
parser looks more or less what the parser would look like
if generated by yacc in C, but with an Eiffel syntax.
I don't remember the exact results of the benchmarks, but
parsers generated by geyacc were much faster than EiffelParse.

Of course the geyacc solution is usable only if the clients
of the generated parsers don't have to dive into the code
of the parsers themselves. We should see it as a black-box.

I think that a regexp library has the same criteria. That's
typically something that clients want to be fast. And clients
see it as a black-box (not that many people decide to dive
into the code of regexp implementation to understand how it
works).

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

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

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

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

    >> So I should wrap a C library then?

I wasn't actually serious about that, by the way (I don't actually
know of an available one, for a start, and I'm in favour of everything
in pure Eiffel).

    Eric> What I had in mind is more something like EiffelParse
    Eric> vs. geyacc.

Can you expand on that statement please?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Assuming that from the client point of view they have the
>     Eric> same interface (only the implementation differs), as a
>     Eric> client of the library I'm only concerned in speed and memory
>     Eric> usage.
> 
> So I should wrap a C library then?

What I had in mind is more something like EiffelParse vs. geyacc.

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

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

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

> So I should wrap a C library then?

I would not agree there, everything should be done in Eiffel because in the
long term it is better. We can achieve very good performance with Eiffel
when things are written with performance in mind.

Manu

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

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

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

    Eric> Assuming that from the client point of view they have the
    Eric> same interface (only the implementation differs), as a
    Eric> client of the library I'm only concerned in speed and memory
    Eric> usage.

So I should wrap a C library then?

    Eric> Now you might say that compiler writers should make
    Eric> it so that the cost of non-expandedness + dynamic binding
    Eric> should not be noticeable compared to giant inspect ;-)

I'd rather say allow ineritance of expanded types.
What are the issues apart from space layout (which could be solved by
forbidding conforming inheritance if attributes are added, or any
function/attribute redefinition, and use non-conforming inheritance
syntax for these cases)?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

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

CRISMER Paul-Georges wrote:
> What is the "cost" you are ready to pay for?
> 
> - OO / Single choice :
>   cost of non-expandedness + dynamic binding (time)
>   benefit of readability (development effort)
> 
> - Integer (instruction number) + giant inspect
>   cost - readability (development effort)
>   benefit - run-time efficiency (time)

Assuming that from the client point of view they
have the same interface (only the implementation
differs), as a client of the library I'm only
concerned in speed and memory usage. And specially
in case of regexp. When there is a trade-off to be
made, the client should be the winner. That's what
happen for the Eiffel language itself: put the burden
on the compiler writers, not on the language users.
Now you might say that compiler writers should make
it so that the cost of non-expandedness + dynamic binding
should not be noticeable compared to giant inspect ;-)

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

Re: [gobo-eiffel-develop] Object-oriented byte-codes for regularexpressions?

[CRISMER Paul-G. <Pau...@gr...>]

Hello Colin,

What is the "cost" you are ready to pay for?

- OO / Single choice :=0D
  cost of non-expandedness + dynamic binding (time)
  benefit of readability (development effort)

- Integer (instruction number) + giant inspect
  cost - readability (development effort)
  benefit - run-time efficiency (time)

The only way to know the difference between both solutions is to write
them both and measure the run-time cost.

- A mixed solution would be the following
* a class INSTRUCTION and its descendants model your instruction set
* at startup you fill an instruction table with one instruction object
* The program is a sequence of integers that refer to the appropriate
instruction in the instruction table
* execution is something like this : instructions.item (op_code).execute

Hope this helps.

My personal taste is the following :
- first model a well designed (OO) solution and make it work
- If measurable performance problems arise, then optimize.

Best regards,

Paul G. Crismer

-----Original Message-----
From: gob...@li...
[mailto:gob...@li...] On Behalf Of
Colin Paul Adams
Sent: vendredi 25 janvier 2008 15:22
To: gob...@li...
Subject: [gobo-eiffel-develop] Object-oriented byte-codes for
regularexpressions?

Classes RX_PCRE_MATCHER and RX_PCRE_BYTE_CODE_CONSTANTS violate the
single choice principle as they both contain giant inspect statements on
the operation code. And the list of operation codes is defined in yet a
third class (RX_PCRE_BYTE_CODE_CONSTANTS).

The pure OO way would be to have a class for the concept of the machine
operation and descendant class for each operation. But as these classes
can't be expanded, there is cost associated with this, compared to using
a 32-bit integer to represent instructions (which is a resonable model
of a 32-bit microprocessor instruction - that is - its the model an
assembler programmer has).

I have to decide which way to go for the Unicode engine I am working on.

Any opinions one way or the other?
--
Colin Adams
Preston Lancashire

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gobo-eiffel-develop mailing list
gob...@li...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

[gobo-eiffel-develop] Object-oriented byte-codes for regular expressions?

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

Classes RX_PCRE_MATCHER and RX_PCRE_BYTE_CODE_CONSTANTS violate the
single choice principle as they both contain giant inspect statements 
on the operation code. And the list of operation codes is defined in
yet a third class (RX_PCRE_BYTE_CODE_CONSTANTS).

The pure OO way would be to have a class for the concept of the machine
operation and descendant class for each operation. But as these
classes can't be expanded, there is cost associated with this,
compared to using a 32-bit integer to represent instructions (which is
a resonable model of a 32-bit microprocessor instruction - that is -
its the model an assembler programmer has).

I have to decide which way to go for the Unicode engine I am working
on.

Any opinions one way or the other?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

Colin Adams wrote:
>> Update the file gobo/misc/eiffel.eant and try again.
> 
> That works.
> 
> I've updated the system.xace file for gexslt to use boehm when
> available. This works for linux. Not sure about Windows. Can you check
> it please?

It didn't work. Actually I wonder how it could work on Linux.
I had to replace:

    <option if="{GOBO_EIFFEL}=ge">
        <option if="{BOEHM_GC}">

by:

    <option if="${GOBO_EIFFEL}=ge">
        <option if="${BOEHM_GC}">

The $ signs were missing. It's now fixed in SVN.

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

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

> Update the file gobo/misc/eiffel.eant and try again.

That works.

I've updated the system.xace file for gexslt to use boehm when
available. This works for linux. Not sure about Windows. Can you check
it please?

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

Colin Adams wrote:
> On 22/01/2008, Eric Bezault <er...@go...> wrote:
>>> If the former, then is it possible to test to see if an environment
>>> variable is set within a system.xace file?
>>    <option name="garbage_collector" value="boehm" if="${BOEHM_GC}"/>
>>
> 
> It doesn't work.
> 
> Not even if I add -DBOEHM_GC =/usr/local to the geant invocation.
> 
> Geant is not passing on BOEHM_GC to gexace command, and so the line
> does not appear in the generated compile_ge.xace.
> 
> Here is the generated command:
> 
> gexace --define="GOBO_EIFFEL=ge GOBO_OS=unix GOBO_CC=gcc"
> --system="ge" --output="compile_ge.xace"
> /home/colin/gobo/src/gexslt/system.xace
> 
> If I manually add BOEHM_GC=/usr/local into the --define= stuff, then
> the correct xace gets generated.

Update the file gobo/misc/eiffel.eant and try again.

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

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

On 22/01/2008, Eric Bezault <er...@go...> wrote:
>
> > If the former, then is it possible to test to see if an environment
> > variable is set within a system.xace file?
>
>    <option name="garbage_collector" value="boehm" if="${BOEHM_GC}"/>
>

It doesn't work.

Not even if I add -DBOEHM_GC =/usr/local to the geant invocation.

Geant is not passing on BOEHM_GC to gexace command, and so the line
does not appear in the generated compile_ge.xace.

Here is the generated command:

gexace --define="GOBO_EIFFEL=ge GOBO_OS=unix GOBO_CC=gcc"
--system="ge" --output="compile_ge.xace"
/home/colin/gobo/src/gexslt/system.xace

If I manually add BOEHM_GC=/usr/local into the --define= stuff, then
the correct xace gets generated.

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

Colin Adams wrote:
> On 22/01/2008, Eric Bezault <er...@go...> wrote:
>> Eric Bezault wrote:
> 
>>>> Apart from the two typos, the sentence seems to suggest that <option
>>>> name="garbage_collector" value="boehm"/> should now work.
>>>>
>>>> But there is no confirmation of this in the section on gec itself.
> 
>> It's now implemented in svn#6276.
> 
> Thanks.
> 
> What happens if this option is supplied, but BOEHM_GC is not set? Is
> an error message issued, or does compilation go ahead assuming the
> value is actually set to "none"?

Even if the environment variable BOEHM_GC is not set, gec will
generate code that works with the Boehm GC. Indeed, it is possible
that one wants to generate the C code, and then compile it later
on another computer where the Boehm GC is installed. Furthermore,
the environment variable BOEHM_GC is something that is used in
the config files in $GOBO/tool/gec/config/c, but it is just a
convention and it is possible to write config files that don't
use this environment variable.

> If the former, then is it possible to test to see if an environment
> variable is set within a system.xace file?

   <option name="garbage_collector" value="boehm" if="${BOEHM_GC}"/>

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

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

On 22/01/2008, Eric Bezault <er...@go...> wrote:
> Eric Bezault wrote:

> >> Apart from the two typos, the sentence seems to suggest that <option
> >> name="garbage_collector" value="boehm"/> should now work.
> >>
> >> But there is no confirmation of this in the section on gec itself.

> It's now implemented in svn#6276.

Thanks.

What happens if this option is supplied, but BOEHM_GC is not set? Is
an error message issued, or does compilation go ahead assuming the
value is actually set to "none"?

If the former, then is it possible to test to see if an environment
variable is set within a system.xace file?

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>> I did an svn update this morning, and noticing the large number of
>> changes, I decided to re-run the bootstrap.
>>
>> Looking at History.txt, I see, amongst others:
>>
>> This makes if possible for example for 'gec' to determine
>>            --
>>  whether the Boehm GC should be used trhough the Xace option
>>                                       --
>>  'garbage_collector'.
>>
>> Apart from the two typos, the sentence seems to suggest that <option
>> name="garbage_collector" value="boehm"/> should now work.
>>
>> But there is no confirmation of this in the section on gec itself. I
>> see that a compile_ge.xace file is generated and read, and the option
>> gets passed through to that file. But it looks like the option is
>> still ignored. Can you confirm that for the moment I still have to
>> type the gec command by hand to add the --gc=boehm option? 
> 
> Yes, you still have to do that. "It makes it possible" does not
> mean that it is already done. But it should be done anytime soon.
> I will open a bug report as a reminder.

It's now implemented in svn#6276.

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

Re: [gobo-eiffel-develop] Gec, Boehm and xace

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

Colin Paul Adams wrote:
> I did an svn update this morning, and noticing the large number of
> changes, I decided to re-run the bootstrap.
> 
> Looking at History.txt, I see, amongst others:
> 
> This makes if possible for example for 'gec' to determine
>            --
>  whether the Boehm GC should be used trhough the Xace option
>                                       --
>  'garbage_collector'.
> 
> Apart from the two typos, the sentence seems to suggest that <option
> name="garbage_collector" value="boehm"/> should now work.
> 
> But there is no confirmation of this in the section on gec itself. I
> see that a compile_ge.xace file is generated and read, and the option
> gets passed through to that file. But it looks like the option is
> still ignored. Can you confirm that for the moment I still have to
> type the gec command by hand to add the --gc=boehm option? 

Yes, you still have to do that. "It makes it possible" does not
mean that it is already done. But it should be done anytime soon.
I will open a bug report as a reminder.

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

[gobo-eiffel-develop] Gec, Boehm and xace

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

I did an svn update this morning, and noticing the large number of
changes, I decided to re-run the bootstrap.

Looking at History.txt, I see, amongst others:

This makes if possible for example for 'gec' to determine
           --
 whether the Boehm GC should be used trhough the Xace option
                                      --
 'garbage_collector'.

Apart from the two typos, the sentence seems to suggest that <option
name="garbage_collector" value="boehm"/> should now work.

But there is no confirmation of this in the section on gec itself. I
see that a compile_ge.xace file is generated and read, and the option
gets passed through to that file. But it looks like the option is
still ignored. Can you confirm that for the moment I still have to
type the gec command by hand to add the --gc=boehm option? 
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Does Gexace support 'supplier_precondition' setting ?

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

Eric Bezault wrote:
> CRISMER Paul-Georges wrote:
>> EiffelStudio provides a 'supplier_precondition' option.
>>
>> Is Gexace capable of generating such a 'supplier_precondition' option?
> 
> Since gexace does not generate ECF files, it does not support
> 'supplier_precondition'. I would look weird to me that EiffelStudio
> support this option for Ace files as well?

The option 'supplier_precondition', and other ECF options, are
now supported in svn#6258. For that, gexace had to be changed
to generate ECF directly instead of going through Ace which is
then converted to ECF by EiffelStudio. See $GOBO/History.txt
for more details.

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

Re: [gobo-eiffel-develop] Comments in KI_BUFFER

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

On 17/01/2008, Eric Bezault <er...@go...> wrote:

>  Should we decide now that SE 1.2 is not
> supported anymore, and let the job to the possible future
> maintainers of SE 1.2 to adapt it so that it can compile
> the Gobo project? After all, that's what I'm currently doing
> with 'gec': I adapt it so that it can compile Eiffel libraries
> other than those from Gobo, such as EiffelBase, EiffelVision2,
> etc

I would say yes.

Re: [gobo-eiffel-develop] Comments in KI_BUFFER

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

 > -----Original Message-----
 > From: Colin Adams
 > Sent: Thursday, January 17, 2008 3:20 AM
 > To: Eric Bezault
 > Subject: Comments in KI_BUFFER
 >
 > I just took a look at this class (I got a Rose Studio
 > notification about it, and I didn't recall the name).
 >
 > At least two of the routines have comments like:
 >
 > 	-- TODO: This routine should be deferred, but there is
 > 	-- a bug with ISE Eiffel 5.1.5 and 5.2 in the generated
 > 	-- C code in finalized mode, and having this
 > 	-- routine effective is a workaround.
 >
 > Does this still apply with 5.7?

I would hope not, but I never checked since then.
Note that there might be other comments like that explaining
workarounds for various compilers and compiler versions.
I will need to do some clean up at some stage. In particular,
I plan to remove the remaining vestiges of VE (as you pointed
out a couple of months ago, there are still some references
to VE laying around). There is indeed very little chances that
VE resurrects from its ashes.

We also need to make a final decision about SE 1.2. It looks
like there is still no sign of life over there. The next
release of ISE will be in June (or May, I don't remember),
and the next release of Gobo will be just before. I was
planning to give SE 1.2 a chance to get back to life say
one month before the release in order to make a decision.
But now that the Gobo bootstrap does not even work with
SE 1.2 (because of UNIX_FILE_INFO for example), I really
wonder why we should wait until then. Why should we keep
the development of the Gobo project in slow gear because
of a compiler that is currently (and possibly forever)
not maintained? Should we decide now that SE 1.2 is not
supported anymore, and let the job to the possible future
maintainers of SE 1.2 to adapt it so that it can compile
the Gobo project? After all, that's what I'm currently doing
with 'gec': I adapt it so that it can compile Eiffel libraries
other than those from Gobo, such as EiffelBase, EiffelVision2,
etc.

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

Re: [gobo-eiffel-develop] Errors compiling xml example with gec

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

I just tried again, and this time there was no problem.
Strange indeed.

On 23/12/2007, Eric Bezault <er...@go...> wrote:

> In fact this is strange because the code that it is complaining
> about is exactly the same that it compiled in the generated
> C code for all applications. It is a copy of file
> $GOBO/tool/gec/runtime/c/eif_file.c. The generated .h file
> should contain a copy of the file $GOBO/tool/gec/runtime/c/eif_except.h
> which has an include of <errno.h>, which itself should declared
> 'errno'.
>
> There is no problem when compiling under Windows:

Re: [gobo-eiffel-develop] Multi-processing whilst compiling with gec

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> No work has been done to let gec compile several C files
>     Eric> concurrently. Currently it is a mere script compiling the C
>     Eric> files one after the other.
> 
> Where is this script?

It's called <your_application>.sh and is located in the
same directory as your generated C files.

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

Re: [gobo-eiffel-develop] Multi-processing whilst compiling with gec

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

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

    Eric> No work has been done to let gec compile several C files
    Eric> concurrently. Currently it is a mere script compiling the C
    Eric> files one after the other.

Where is this script?
-- 
Colin Adams
Preston Lancashire