Nabble - Eiffel Software Development

Business Software Development

2007-11-23T05:48:50Z

Business Software Development is a boon to the corporate world. The tedious tasks have been simplified by the use of Business software applications such as enterprise resource planning, enterprise content management (ECM), business process management and product lifecycle management. Also, medium sized software like the shopping cart software is an added advantage in online or e-shopping.

[url=http://www.hanusoftware.com]
business software development [/url]

[url=http://www.hanusoftware.com]
business software development[/url]

Re: Capture Replay

2007-10-17T09:52:06Z

Hi Andreas,

This new "execution replay" mechanism is for now quite basic.
In a word, it enable the user to record an execution, and and some point
to replay it.
By replaying, I mean being able to go back to previous call stack levels
and watch the object's values at they were at this point.

For now,
- only classic system are supported
- only going back and (then) forth in the call stack is supported.
- Only attribute values are recorded (and thus restored during replay).
- Once status are not changed (no reset).
- It needs more testing about expanded objects.
- the recording could be smarter (and it will be smarter in the future)

There are basic optimizations about memory and speed regarding the
recording, more optimizations will come later.
For now, there is a limit of
`{RT_DBG_EXECUTION_RECORDER}.max_record_count' records (by default, it
is 5_000), then when the limit is reached, the oldest records are
discarded. (you can change the 5_000 limit, by editing the code of
RT_DBG_EXECUTION_RECORDER, in the future the debugger will handle that
operation).

The 6.1 has then a first implementation of this execution replay
mechanism, it will be improved in the future.
And despite of all the limitation, this can already be helpful.

Hope this answers a few questions,
-- Jocelyn

On 10/17/2007 16:16 PM, Andreas Leitner wrote:

> In the release notes for the new 6.1 interim I saw a notice about a
> capture/replay feature. I am interested in such features, can anybody
> explain a little bit more what is provided?
>
> tia,
> Andreas
> _______________________________________________
> Es-devel mailing list
> Es-devel@...
> http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
>
>

--
Jocelyn
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Capture Replay

2007-10-17T08:16:52Z

In the release notes for the new 6.1 interim I saw a notice about a
capture/replay feature. I am interested in such features, can anybody
explain a little bit more what is provided?

tia,
Andreas
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Overriding Assertions

2007-10-16T23:48:22Z

Opening the .ecf file in an XML editor can speed things up. Also, somebody
might produce some xslt/xquery (whatever) script/template that will
generate this information from the .ecf file.

Bernd

On Tue, 16 Oct 2007 19:45:50 +0200, Mark Bolstad
<the.render.dude@...> wrote:

> I found that in the clusters panel, you can right click a cluster or
> class
> and override the assertions for that class. However, I can't find any
> way to
> tell which clusters I've overridden (other than clicking each cluster,
> and
> only the cluster right above the leaf nodes).
>
> Is there an easy way to find out which clusters are overridden, or if
> not,
> can we add one in 6.1? Like change the icon perhaps?
>
> Mark

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Overriding Assertions

2007-10-16T17:53:26Z

> Sounds like a job for the Metrics tool.

It could but for now the metrics tool only knows about classes, features and
about containers/groups from the configuration system but nothing about the
settings. So we need to do some work in order to do that.

Regards,
Manu

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Overriding Assertions

2007-10-16T17:37:25Z

Mark Bolstad wrote:
> Is there an easy way to find out which clusters are overridden,
> or if not, can we add one in 6.1? Like change the icon perhaps?

Sounds like a job for the Metrics tool.

- Peter Gummer

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Mailing list discontinuation

2007-10-16T16:59:52Z

Hi,

In the next few days, we will stop the mailing lists which Origo was hosting
for us. Instead of recreating another set of mailing lists we decided to use
the forum feature from the new Origo
(http://eiffelstudio.origo.ethz.ch/forum). We will keep the archives of the
mailing lists and we will publish them later on our website once we found an
appropriate location.

Regards,
Manu

------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
Product information: mailto:info@...
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Overriding Assertions

2007-10-16T16:56:28Z

At the moment, this is not possible. Currently this could be done as an expensive operation but this is definitely in our wish list.

Manu

From: es-devel-bounces@... [mailto:es-devel-bounces@...] On Behalf Of Mark Bolstad
Sent: Tuesday, October 16, 2007 10:46 AM
To: es-devel@...
Subject: [Es-devel] Overriding Assertions

I found that in the clusters panel, you can right click a cluster or class and override the assertions for that class. However, I can't find any way to tell which clusters I've overridden (other than clicking each cluster, and only the cluster right above the leaf nodes).

Is there an easy way to find out which clusters are overridden, or if not, can we add one in 6.1? Like change the icon perhaps?

Mark

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Overriding Assertions

2007-10-16T11:45:50Z

I found that in the clusters panel, you can right click a cluster or class and override the assertions for that class. However, I can't find any way to tell which clusters I've overridden (other than clicking each cluster, and only the cluster right above the leaf nodes).

Is there an easy way to find out which clusters are overridden, or if not, can we add one in 6.1? Like change the icon perhaps?

Mark

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Error on precompile

2007-10-10T10:58:30Z

Looks like it is compiling the wrong version of TYPED_POINTER which is coming from FreeELKS. My guess is that you may be checking out the wrong branch in FreeELKS. Indeed for the Eiffel_60 branch of EiffelStudio, we are checking out the Eiffel_60 branch from FreeELKS, but for the trunk of EiffelStudio we check out the trunk of FreeELKS.

Manu

> -----Original Message-----
> From: es-devel-bounces@...
> [mailto:es-devel-bounces@...] On Behalf Of Bernd
> Schoeller
> Sent: Wednesday, October 10, 2007 9:43 AM
> To: es-devel@...
> Subject: [Es-devel] Error on precompile
>
> Hi,
>
> using the latest Windows x86 version of ES from Origo
> (extracted .7z with all environment variables set), I get the
> following error when trying to precompile EiffelBase:
>
> --------------------------------------------------------------
> -----------------
>
> Error code: Library_error
> Error: Particular class content does not match what compiler
> is expecting.
> What to do: Make sure you haven't modified one of the kernel
> classes on which
> compiler relies.
>
> Class: TYPED_POINTER [G]
> Class TYPED_POINTER must have one attribute of name `pointer_item'
>
> --------------------------------------------------------------
> -----------------
>
> Probably some stupid problem with my setup (I try to avoid
> using register entries), still any hint on what might be the
> problem is welcome.
>
> Bernd
> _______________________________________________
> Es-devel mailing list
> Es-devel@...
> http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
>

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Error on precompile

2007-10-10T10:42:51Z

Hi,

using the latest Windows x86 version of ES from Origo (extracted .7z with
all environment variables set), I get the following error when trying to
precompile EiffelBase:

-------------------------------------------------------------------------------

Error code: Library_error
Error: Particular class content does not match what compiler is expecting.
What to do: Make sure you haven't modified one of the kernel classes on
which
compiler relies.

Class: TYPED_POINTER [G]
Class TYPED_POINTER must have one attribute of name `pointer_item'

-------------------------------------------------------------------------------

Probably some stupid problem with my setup (I try to avoid using register
entries), still any hint on what might be the problem is welcome.

Bernd
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: ecf files get overwritten

2007-10-03T10:11:39Z

Arno Fiva wrote:
> I noticed when you compile a project, close EiffelStudio, make changes
> to the .ecf file in an editor and run EiffelStudio again, all changes
> made by hand are overwritten.
> Is there a reason for that?
>
What kind of changes did you do? What did you do in EiffelStudio? When
you go to the project settings, the ecf file is parsed and saved at the
end, so things that do not belong to the official ecf format are lost
(e.g. if you add new attributes or xml comments)

Regards,
Patrick

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

ecf files get overwritten

2007-10-03T05:42:46Z

I noticed when you compile a project, close EiffelStudio, make changes
to the .ecf file in an editor and run EiffelStudio again, all changes
made by hand are overwritten.
Is there a reason for that?

Arno

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: BYTE_SERVER

2007-09-28T21:47:39Z

> At which stage does the BYTE_SERVER ( system.byte_server )
> receives the byte code generated for the user's classes? I
> noticed that when the the precompiled files are available it
> will load them but I couldn't find the stage in which it adds
> the user's byte code.

Currently, most `server' have a counterpart `tmp_server'. The `tmp_server'
holds the data of the current compilation and it takes priority over
`server'. Once a compilation is successful, the data from `tmp_server' is
merged to `server'.

In the case of BYTE_SERVER, during degree 3 we add the generated BYTE_CODE
to the TMP_BYTE_SERVER.

> Is the byte_code from the new classes also written to file?

Yes, all the data is stored to the servers so that next time you load your
project, we have everything handy.

Hope this helps,
Manu

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

BYTE_SERVER

2007-09-27T11:40:28Z

Hi All,

I have a question regarding the byte server. I have tried to watch its
main writing functions but could catch the clients that are writing to it.

At which stage does the BYTE_SERVER ( system.byte_server ) receives
the byte code generated for the user's classes? I noticed that when the the
precompiled files are available it will load them but I couldn't
find the stage in which it adds the user's byte code.

Is the byte_code from the new classes also written to file?

Thanks,
Lucas

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

New SVN URL

2007-09-19T14:23:16Z

Hi,

We have migrated our svn repository to the new origo site. To update your
local copy to the new URL, you simply have to do:

svn switch --relocate https://eiffelsoftware.origo.ethz.ch/svn/es
https://svn.origo.ethz.ch/eiffelstudio

Regards,
Manu

------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
Product information: mailto:info@...
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Feature_Table and Code Generation

2007-09-18T03:42:20Z

Hello Lucas,

I hope you do not mind some comments and asking for some clarifications:

On Tue, 18 Sep 2007 10:57:57 +0200, Lucas S. Silva <lssilva@...>
wrote:
> Well, If I get enough time, my goals are:
>
> 1 Learn how the ec works

Sure - it is not too difficult, once you have managed to climb some hills.
Feel free to ask on the list for specific details.

> 2 Split the static analysis from the compilation. I want to be able to
> compile without the static analysis

I do not get this point. The whole compiler frontend is static analysis.
What is it exactly that you want to avoid?

> 3 Update the naming system, I think that the current encoder will
> generate the feature name based on their ids which depends on the number
> of
> features/types, hence in the inheritance analysis.

Which naming system? At some time during the compilation, names are
dropped and replaced by IDs. Multiple IDs for a single feature are needed
because of multiple subtyping (merging of different features). It does not
need to be ID sets, there are other possible techniques, but in the end it
boils down to the same.

> 4 Have the feature loading / binding done dynamically

Do you mean "loading" as in "class loading"?

> I think that the Eiffel Compiler does a excellent job, I would like to
> have
> a simpler compiler
> which is easier to experiment.

There exists the GOBO Eiffel compiler, which is work-in-progress, but
definitely using a more simplistic approach to compilation. You might want
to have a look at it, though some of Eric's "magic" is difficult to grasp.
Not that I want to push you away from EC (it is a good compiler), just
want to mention alternatives. You should avoid SmartEiffel, because that
is not an Eiffel compiler.

> class loading of precompiled Eiffel modules", you should be aware that
>> there is probably a major problem: as far as I know the following three
>> things cannot be joined:
>>
>> - Efficient class loading
>> - Constant dynamic binding
>> - Multiple subtyping
>
>
> I think we could cross the Efficient out from Class loading, that would
> do
> it.

OK. You have to globally recompute the feature table every time you add a
new class that implements the feature. Smart updating mechansism can help
there.

> Eiffel is so fast, because it can generate a global feature table for
>> constant feature lookup in dynamic binding. This is not possible any
>> more if you introduce incremental compilation and dynamic class loading.
>
> It is one reason why people in C++ are so picky about "virtual" and Java
>> is so slow (because it needs a search routine for dynamic binding).
>
>
> I believe that Eiffel's efficient is not only attributed to the constant
> feature look-up, and
> as I said my goal is not to replace the Eiffel Compiler.

It is one of the reasons. But surely not the only one, you are right.

> Even with dynamic
> loading/binding
> some people will say that Java is no longer so slow, in fact they will
> claim
> that it is faster than
> C/C++ in some areas[1][2].

Java has non-constant lookup when you are making use of 'invokeinterface',
which requires non-constant lookup because of multiple subtyping. This is
nearly never the case in the benchmarks you mention, but happens really
often in complex data-models as they are present in the industry.

An other source of speed problems is the use of "functional programming
style" of coding, because Java does not propagate Command/Query
separation. As an effect, this creates very many short-lives objects (for
intermediate results). Object creation is expensive, making Java slow.
This is another property of Java that is not tested in benchmarks, but has
a strong impact on performance of large scale applications.

> The only solution would be to recompute the global feature table when
>> loading a new class, making class loading rather inefficient. YMMV
>
> I think that if the naming is not dependent on the entire feature
> history,
> we might
> not have to recompute the whole feature table but just the new ones

True, as said it is only necessary to recompute the feature tables of all
features of the dynamically loaded class, and there is quite some room
"algorithmic smartness", though it will not change the "worst case"
behavior.

Bernd
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Feature_Table and Code Generation

2007-09-18T02:57:57Z

Thanks for the reply,

I am not sure what you are aiming at, but if you want to have a "dynamic

Well, If I get enough time, my goals are:

1 Learn how the ec works

2 Split the static analysis from the compilation. I want to be able to compile
without the static analysis

3 Update the naming system, I think that the current encoder will generate
the feature name based on their ids which depends on the number of features/types,
hence in the inheritance analysis.

4 Have the feature loading / binding done dynamically

I think that the Eiffel Compiler does a excellent job, I would like to have a simpler compiler
which is easier to experiment.

class loading of precompiled Eiffel modules", you should be aware that
there is probably a major problem: as far as I know the following three
things cannot be joined:

- Efficient class loading
- Constant dynamic binding
- Multiple subtyping

I think we could cross the Efficient out from Class loading, that would do it.

Eiffel is so fast, because it can generate a global feature table for
constant feature lookup in dynamic binding. This is not possible any
more if you introduce incremental compilation and dynamic class loading.

It is one reason why people in C++ are so picky about "virtual" and Java
is so slow (because it needs a search routine for dynamic binding).

I believe that Eiffel's efficient is not only attributed to the constant feature look-up, and
as I said my goal is not to replace the Eiffel Compiler. Even with dynamic loading/binding
some people will say that Java is no longer so slow, in fact they will claim that it is faster than
C/C++ in some areas[1][2].

The only solution would be to recompute the global feature table when
loading a new class, making class loading rather inefficient. YMMV

I think that if the naming is not dependent on the entire feature history, we might
not have to recompute the whole feature table but just the new ones

Bernd

Regards,
Lucas S. Silva

[1] http://www.kano.net/javabench/
[2] http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Feature_Table and Code Generation

2007-09-18T01:46:04Z

Lucas S. Silva wrote:
> I see that INHERIT_TABLE -> pass2 calls the analyze which based on the
> inheritance
> info will add the features is that right?. But could a feature table of
> a single class be generated without
> the inheritance analyzes? A feature table containing only the features
> declared in a given class
> without worrying about the renaming, redefinition and inheritance??

I am not sure what you are aiming at, but if you want to have a "dynamic
class loading of precompiled Eiffel modules", you should be aware that
there is probably a major problem: as far as I know the following three
things cannot be joined:

- Efficient class loading
- Constant dynamic binding
- Multiple subtyping

Eiffel is so fast, because it can generate a global feature table for
constant feature lookup in dynamic binding. This is not possible any
more if you introduce incremental compilation and dynamic class loading.

It is one reason why people in C++ are so picky about "virtual" and Java
is so slow (because it needs a search routine for dynamic binding).

The only solution would be to recompute the global feature table when
loading a new class, making class loading rather inefficient. YMMV

Bernd
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Feature_Table and Code Generation

2007-09-17T17:31:54Z

> How is the feature table computed? Is it computed from the
> CLASS_AS and CLASS_INFO?.

More or less. All the computation is done as you found out in
INHERIT_TABLE.pass2.

> right?. But could a feature table of a single class be
> generated without the inheritance analyzes? A feature table
> containing only the features declared in a given class
> without worrying about the renaming, redefinition and inheritance??

At the moment, we do not do that, but I don't see why one could not do it.
In that case, it might be just simpler to use the CLASS_AS object and
iterates through the various routines declared in the class.

> Another doubt I have is regarding the c code generation. So
> far I have understood is that the c code is generated from
> the list of features am I right? Is the byte code stored in
> the FEATURE_I?
> in the FEATURE_I.generate I see that it retrieves the byte
> code from a byte code server, why is that?

Currently, we build from the AST instanaces (the _AS classes) a set of
BYTE_NODE instances (the _B classes). Those _B are more suitable for code
generation than the AST (although over the past few years this is less and
less the case) and because we don't want all those objects in memory, we
store them into `servers'.

At degree -1 when we generate the code, we retrieve the BYTE_NODE instances
from the byte code server and then generate the code.

Hope this helps,
Manu

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Feature_Table and Code Generation

2007-09-15T08:07:42Z

Hi,

I have some doubts regarding the code generation and feature table and
I would be glad if someone could give me some directions.

How is the feature table computed? Is it computed from the CLASS_AS and CLASS_INFO?.

I see that INHERIT_TABLE -> pass2 calls the analyze which based on the inheritance
info will add the features is that right?. But could a feature table of a single class be generated without
the inheritance analyzes? A feature table containing only the features declared in a given class
without worrying about the renaming, redefinition and inheritance??

Another doubt I have is regarding the c code generation. So far I have understood is that the c code is
generated from the list of features am I right? Is the byte code stored in the FEATURE_I?
in the FEATURE_I.generate I see that it retrieves the byte code from a byte code server, why is that?

Thanks in advance,
Lucas S. Silva

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Re: ec verbose level

2007-08-24T17:21:56Z

Manu wrote:

> We were thinking to change the default to only print the starting of the
> degrees (i.e. like in the output window of EiffelStudio). And adding the
> -verbose option if you want the same behavior as today. What do you think?

This is the usual approach taken by other command-line tools, in my
experience, and I would definitely prefer it. My SCons builder for Eiffel
(http://www.scons.org/wiki/EiffelStudioTool?highlight=%28Tool%24%29) goes to
a lot of effort to redirect the output to a log file, and then if there's an
error it displays the last 1000 characters from the log file. This works
fine, but the idea of displaying the last 1000 characters is a bit
arbitrary; and it's silly that I had to go to this effort in the first
place.

If you decide to take the -verbose approach, it would be nice to be able to
turn warnings on or off.

- Peter Gummer

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Error messages when running ES on unix

2007-08-24T15:06:11Z

I compiled my branch (origo_integration) under linux-x86. But when I run it I get pretty often this error message in the console:

(ec: 23324): GdkPixbuf - CRITICAL **: gdk_pixbufcopy_area: assertion 'dest_x >= 0 && dest_x + width >= dest_pixbuf - > width ' failed

My branch is on revision 70112 of the trunk and the only thing i can think of that could cause this problem is that i added the attached image to EB_SHARED_PIXMAPS. I couldn't test to compile revision 70112 of the trunk to check whether it happens there too because the only 32 bit linux machine that i could use to compile it is used by someone else (who is already mad at me because of compiling eiffelstudio there ;) ) at the moment. but i will try it out as soon as i can.

Do you know what the problem could be?

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

origo.png (1K) Download Attachment

Re: Re: ec verbose level

2007-08-23T15:08:08Z

On 8/23/07, Patrick Ruckstuhl <patrick@...> wrote:

I think that would be great.

me too!

> We were thinking to change the default to only print the starting of the

> degrees (i.e. like in the output window of EiffelStudio). And adding the
> -verbose option if you want the same behavior as today. What do you think?
>
> Regards,
> Manu
>
>> -----Original Message-----
>> From: es-devel-bounces@...
>> [mailto:es-devel-bounces@...] On Behalf Of
>> Patrick Ruckstuhl
>> Sent: Thursday, August 23, 2007 10:48 AM
>> To: es-devel@...
>> Subject: [Es-devel] Re: ec verbose level
>>

>> Hi,
>>
>>>     Are you doing the experiment in the X window session? If so, you
>>>     should do without an X server running as the output
>> will be slow due
>>>     to the X server trying to scroll the content.
>>>
>>>
>>> Ops.. my bad!
>>>
>>>     To better compare the speed, you should do in bash:
>>>
>>>     ec -finalize -config ec.ecf -target batch_unix > OUTPUT.txt 2>&1
>>>
>>>     That way you can eliminate the slowness of the X server.
>>>
>>>
>>> Correct, now the difference is insignificant!

>> I personally would still like a less verbose mode, most of
>> the time I'm not interested in all the details and I'm
>> working on remote machines so I have to redirect the output
>> to a file and then check the file if a compilation error happens.
>>
>> Regards,
>>
>> Patrick
>>
>> http://origo.ethz.ch
>>
>> _______________________________________________
>> Es-devel mailing list
>> Es-devel@...
>> http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
>>

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: Re: ec verbose level

2007-08-23T15:00:19Z

And what of the new command line?

http://eiffelsoftware.origo.ethz.ch/EC_Command_Line

Paul.

Emmanuel Stapf [ES] wrote:

> We were thinking to change the default to only print the starting of the
> degrees (i.e. like in the output window of EiffelStudio). And adding the
> -verbose option if you want the same behavior as today. What do you think?
>
> Regards,
> Manu
>
>> -----Original Message-----
>> From: es-devel-bounces@...
>> [mailto:es-devel-bounces@...] On Behalf Of
>> Patrick Ruckstuhl
>> Sent: Thursday, August 23, 2007 10:48 AM
>> To: es-devel@...
>> Subject: [Es-devel] Re: ec verbose level
>>
>> Hi,
>>
>>> Are you doing the experiment in the X window session? If so, you
>>> should do without an X server running as the output
>> will be slow due
>>> to the X server trying to scroll the content.
>>>
>>>
>>> Ops.. my bad!
>>>
>>> To better compare the speed, you should do in bash:
>>>
>>> ec -finalize -config ec.ecf -target batch_unix > OUTPUT.txt 2>&1
>>>
>>> That way you can eliminate the slowness of the X server.
>>>
>>>
>>> Correct, now the difference is insignificant!
>> I personally would still like a less verbose mode, most of
>> the time I'm not interested in all the details and I'm
>> working on remote machines so I have to redirect the output
>> to a file and then check the file if a compilation error happens.
>>
>> Regards,
>>
>> Patrick
>>
>> http://origo.ethz.ch
>>
>> _______________________________________________
>> Es-devel mailing list
>> Es-devel@...
>> http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
>>
>

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: ec verbose level

2007-08-23T14:57:03Z

I think that would be great.

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Re: ec verbose level

2007-08-23T14:55:43Z

We were thinking to change the default to only print the starting of the
degrees (i.e. like in the output window of EiffelStudio). And adding the
-verbose option if you want the same behavior as today. What do you think?

Regards,
Manu

> -----Original Message-----
> From: es-devel-bounces@...
> [mailto:es-devel-bounces@...] On Behalf Of
> Patrick Ruckstuhl
> Sent: Thursday, August 23, 2007 10:48 AM
> To: es-devel@...
> Subject: [Es-devel] Re: ec verbose level
>
> Hi,
>
> > Are you doing the experiment in the X window session? If so, you
> > should do without an X server running as the output
> will be slow due
> > to the X server trying to scroll the content.
> >
> >
> > Ops.. my bad!
> >
> > To better compare the speed, you should do in bash:
> >
> > ec -finalize -config ec.ecf -target batch_unix > OUTPUT.txt 2>&1
> >
> > That way you can eliminate the slowness of the X server.
> >
> >
> > Correct, now the difference is insignificant!
>
> I personally would still like a less verbose mode, most of
> the time I'm not interested in all the details and I'm
> working on remote machines so I have to redirect the output
> to a file and then check the file if a compilation error happens.
>
> Regards,
>
> Patrick
>
> http://origo.ethz.ch
>
> _______________________________________________
> Es-devel mailing list
> Es-devel@...
> http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
>

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Missing images

2007-08-23T14:53:57Z

There was a small error we introduce in Vision2 early this week. If you update to the new version of the library it should be ok.

Manu

From: es-devel-bounces@... [mailto:es-devel-bounces@...] On Behalf Of Rafael Bischof
Sent: Thursday, August 23, 2007 11:46 AM
To: es-devel@...
Subject: [Es-devel] Missing images

hi

I compiled the current head version of Eiffel Studio with the latest beta release (32 bit Windows). If I start the compiled EiffelStudio all images are missing, but I don't get any execptions or error messages. Merged with my branch there is one single image that is displayed and that's the one i added myself (as a distinct png file and added to eb_shared_pixmaps). It doesn't matter whether I start the compiled EiffelStudio directely from the IDE or if i finalize it and overwrite the ec.exe in my EiffelStudio installation directory. Do you have any ideas what the problem could be?

Rafael Bischof

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Missing images

2007-08-23T12:46:28Z

I compiled the current head version of Eiffel Studio with the latest beta release (32 bit Windows). If I start the compiled EiffelStudio all images are missing, but I don't get any execptions or error messages. Merged with my branch there is one single image that is displayed and that's the one i added myself (as a distinct png file and added to eb_shared_pixmaps). It doesn't matter whether I start the compiled EiffelStudio directely from the IDE or if i finalize it and overwrite the ec.exe in my EiffelStudio installation directory. Do you have any ideas what the problem could be?

Rafael Bischof

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: ec verbose level

2007-08-23T11:47:42Z

Hi,

> Are you doing the experiment in the X window session? If so, you
> should do without an X server running as the output will be slow due
> to the X server trying to scroll the content.
>
>
> Ops.. my bad!
>
> To better compare the speed, you should do in bash:
>
> ec -finalize -config ec.ecf -target batch_unix > OUTPUT.txt 2>&1
>
> That way you can eliminate the slowness of the X server.
>
>
> Correct, now the difference is insignificant!

I personally would still like a less verbose mode, most of the time I'm
not interested in all the details and I'm working on remote machines so
I have to redirect the output to a file and then check the file if a
compilation error happens.

Regards,

Patrick

http://origo.ethz.ch

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

Re: ec verbose level

2007-08-23T10:34:13Z

Hi Emmanuel,

Thanks for the response.

On 8/23/07, Emmanuel Stapf [ES] < manus@...> wrote:

Are you doing the experiment in the X window session? If so, you should do without an X server running as the output will be slow due to the X server trying to scroll the content.

Ops.. my bad!

To better compare the speed, you should do in bash:

ec -finalize -config ec.ecf -target batch_unix > OUTPUT.txt 2>&1

That way you can eliminate the slowness of the X server.

Correct, now the difference is insignificant!

Thanks,
Lucas

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: ec verbose level

2007-08-23T09:19:54Z

Are you doing the experiment in the X window session? If so, you should do without an X server running as the output will be slow due to the X server trying to scroll the content.

To better compare the speed, you should do in bash:

ec -finalize -config ec.ecf -target batch_unix > OUTPUT.txt 2>&1

That way you can eliminate the slowness of the X server.

Regards,

Manu

From: es-devel-bounces@... [mailto:es-devel-bounces@...] On Behalf Of Lucas S. Silva
Sent: Thursday, August 23, 2007 7:14 AM
To: es-devel@...
Subject: [Es-devel] ec verbose level

Hi,

Is there a command line parameter for ec that suppresses
the compilation output?

My machine is not that fast, so I wanted to find out how
much time the degree(s)_output were consuming from the
total time taken to finalize a system.

I have conducted some experiments and I think the results
are interesting, so I will post them here.

My processor:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model             : 7
model name   : AMD Athlon(tm) 64 FX-55 Processor
stepping         : 10
cpu MHz         : 1200.000
cache size      : 1024 KB

I have finalized the ec 5 times with the current ( 6.1XX) Eiffel
compiler and 5 times with a modified version, where most of
the output information were suppressed.

command used:

ec -finalize -config ec.ecf -target batch_unix

Results:

With output
real    8m50.473s
user    5m1.331s
sys     0m9.769s

real    9m6.929s
user    5m2.847s
sys     0m9.685s

real    9m4.969s
user    5m2.527s
sys     0m9.569s

real    8m50.723s
user    5m0.839s
sys     0m9.485s

real    9m3.535s
user    5m1.155s
sys     0m10.245s

Without output
real    5m1.514s
user    4m37.469s
sys     0m7.704s

real    4m57.933s
user    4m35.517s
sys     0m8.121s

real    4m59.459s
user    4m38.349s
sys     0m7.828s

real    4m57.029s
user    4m35.849s
sys     0m7.752s

real    4m58.161s
user    4m36.201s
sys     0m8.297s

I am not sure if I conducted this experiment properly.
I just used time to record the process time. I thought
that it would be at most 1 minute faster, I didn't expect
it to be 40% faster.

Regards,
Lucas Silva

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

ec verbose level

2007-08-23T08:14:17Z

Hi,

Is there a command line parameter for ec that suppresses
the compilation output?

My machine is not that fast, so I wanted to find out how
much time the degree(s)_output were consuming from the
total time taken to finalize a system.

I have conducted some experiments and I think the results
are interesting, so I will post them here.

My processor:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model             : 7
model name   : AMD Athlon(tm) 64 FX-55 Processor
stepping         : 10
cpu MHz         : 1200.000
cache size      : 1024 KB

I have finalized the ec 5 times with the current ( 6.1XX) Eiffel
compiler and 5 times with a modified version, where most of
the output information were suppressed.

command used:

ec -finalize -config ec.ecf -target batch_unix

Results:

With output
real    8m50.473s
user    5m1.331s
sys     0m9.769s

real    9m6.929s
user    5m2.847s
sys     0m9.685s

real    9m4.969s
user    5m2.527s
sys     0m9.569s

real    8m50.723s
user    5m0.839s
sys     0m9.485s

real    9m3.535s
user    5m1.155s
sys     0m10.245s

Without output
real    5m1.514s
user    4m37.469s
sys     0m7.704s

real    4m57.933s
user    4m35.517s
sys     0m8.121s

real    4m59.459s
user    4m38.349s
sys     0m7.828s

real    4m57.029s
user    4m35.849s
sys     0m7.752s

real    4m58.161s
user    4m36.201s
sys     0m8.297s

I am not sure if I conducted this experiment properly.
I just used time to record the process time. I thought
that it would be at most 1 minute faster, I didn't expect
it to be 40% faster.

Regards,
Lucas Silva
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

RE: Another C compilation error

2007-08-22T09:12:29Z

It is possible that you were using the old version of the EiffelBase FUNCTION class which is incompatible between 6.0 and the latest 6.1.

Manu

From: es-devel-bounces@... [mailto:es-devel-bounces@...] On Behalf Of Rafael Bischof
Sent: Wednesday, August 22, 2007 2:56 AM
To: 'Rafael Bischof'; es-devel@...
Subject: AW: [Es-devel] Another C compilation error

ok, i could solve the problem by deleting everything once again and recompiling everything once more from scratch. maybe i missed something before

Von: es-devel-bounces@... [mailto:es-devel-bounces@...] Im Auftrag von Rafael Bischof
Gesendet: Mittwoch, 22. August 2007 10:36
An: es-devel@...
Betreff: [Es-devel] Another C compilation error

hi

I just installed the EiffelStudio beta release from the beta download Area (6.1.6.9962 GPL Edition - windows). Then i updated the EiffelStudio source from the SVN (revision 70070) and wanted to compile it. The eiffel compilation went fine but the C compilation aborted with this output:

big_file_C177_c.c
big_file_C176_c.c
big_file_C175_c.c
big_file_C174_c.c
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(41) : error C2059: Syntaxfehler: ')'
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(79) : error C2061: Syntaxfehler: Bezeichner 'Fvwjn_5'
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(79) : error C2059: Syntaxfehler: ';'
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(79) : error C2059: Syntaxfehler: 'Typ'
NMAKE : fatal error U1077: ""C:\Programme\Microsoft Visual Studio 8\VC\BIN\cl.EXE"": R³ckgabe-Code "0x2"
Stop.

Do you have any idea how to solve this?

Rafael Bischof

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel

AW: Another C compilation error

2007-08-22T03:55:49Z

ok, i could solve the problem by deleting everything once again and recompiling everything once more from scratch. maybe i missed something before

Von: es-devel-bounces@... [mailto:es-devel-bounces@...] Im Auftrag von Rafael Bischof
Gesendet: Mittwoch, 22. August 2007 10:36
An: es-devel@...
Betreff: [Es-devel] Another C compilation error

I just installed the EiffelStudio beta release from the beta download Area (6.1.6.9962 GPL Edition - windows). Then i updated the EiffelStudio source from the SVN (revision 70070) and wanted to compile it. The eiffel compilation went fine but the C compilation aborted with this output:

big_file_C177_c.c
big_file_C176_c.c
big_file_C175_c.c
big_file_C174_c.c
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(41) : error C2059: Syntaxfehler: ')'
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(79) : error C2061: Syntaxfehler: Bezeichner 'Fvwjn_5'
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(79) : error C2059: Syntaxfehler: ';'
c:\eth\masterarbeit\eiffelstudio\dev60old2\eiffel\ace\eifgens\bench\w_code\c174\fu5723.c(79) : error C2059: Syntaxfehler: 'Typ'
NMAKE : fatal error U1077: ""C:\Programme\Microsoft Visual Studio 8\VC\BIN\cl.EXE"": R³ckgabe-Code "0x2"
Stop.

Do you have any idea how to solve this?

Rafael Bischof

_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel