Nabble - Eiffel Software Users

RE: Re: Assertion violation in default Vision2 application

2008-07-26T02:14:14Z

Yes, I'm on Vista Ultimate 64-bit and have posted a bug report on this on as
it seems to me this should not occur. I tried a few different was to set up
the application and got an assertion violation (I don't remember now if it
was the same one) every time.

Regards

Chris Saunders

From: eiffel_software@...
[mailto:eiffel_software@...] On Behalf Of Balázs Kéri
Sent: July-26-08 3:13 AM
To: eiffel_software@...
Subject: Re: [eiffel_software] Re: Assertion violation in default Vision2
application

Hi,

I have just reproduced the same (or similar) error. I used
EiffelStudio 6.2.7.3753 on Windows Vista, 32 bit. I simply generated a
new vision2 default application (turned on all features), changed the
settings in vision2 and vision2_pre libraries to check all assertions.
When the application starts assertion "exists" in
{WEL_PALETTE}.decrement_reference is violated. Here is the call stack:

ObjectClassRoutine
------------------
[0x599A258] WEL_PALETTE decrement_reference (From
WEL_REFERENCE_TRACKABLE) ( @ 1 )
[0x599A260] EV_PIXMAP_IMP reset_bitmap_content ( @ 8 )
[0x599A260] EV_PIXMAP_IMP destroy ( @ 4 )
[0x599A260] EV_PIXMAP_IMP safe_destroy (From EV_ANY_I) ( @ 3 )
[0x599A264] EV_PIXMAP destroy (From EV_ANY) ( @ 1 )
[0x599A268] EV_TOOL_BAR_BUTTON_IMP set_pixmap_in_parent ( @ 37 )
[0x599A26C] EV_TOOL_BAR_IMP insert_item ( @ 17 )
[0x599A26C] EV_TOOL_BAR_IMP insert_i_th (From EV_ITEM_LIST_IMP) ( @ 6 )
[0x599A26C] EV_TOOL_BAR_IMP extend (From EV_DYNAMIC_LIST_I) ( @ 2 )
[0x599A270] EV_TOOL_BAR extend (From EV_DYNAMIC_LIST) ( @ 7 )
Balázs Kéri

[Non-text portions of this message have been removed]

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Re: Assertion violation in default Vision2 application

2008-07-26T00:13:04Z

Hi,

I have just reproduced the same (or similar) error. I used
EiffelStudio 6.2.7.3753 on Windows Vista, 32 bit. I simply generated a
new vision2 default application (turned on all features), changed the
settings in vision2 and vision2_pre libraries to check all assertions.
When the application starts assertion "exists" in
{WEL_PALETTE}.decrement_reference is violated. Here is the call stack:

ObjectClassRoutine
------------------
[0x599A258] WEL_PALETTE decrement_reference (From
WEL_REFERENCE_TRACKABLE) ( @ 1 )
[0x599A260] EV_PIXMAP_IMP reset_bitmap_content ( @ 8 )
[0x599A260] EV_PIXMAP_IMP destroy ( @ 4 )
[0x599A260] EV_PIXMAP_IMP safe_destroy (From EV_ANY_I) ( @ 3 )
[0x599A264] EV_PIXMAP destroy (From EV_ANY) ( @ 1 )
[0x599A268] EV_TOOL_BAR_BUTTON_IMP set_pixmap_in_parent ( @ 37 )
[0x599A26C] EV_TOOL_BAR_IMP insert_item ( @ 17 )
[0x599A26C] EV_TOOL_BAR_IMP insert_i_th (From EV_ITEM_LIST_IMP) ( @ 6 )
[0x599A26C] EV_TOOL_BAR_IMP extend (From EV_DYNAMIC_LIST_I) ( @ 2 )
[0x599A270] EV_TOOL_BAR extend (From EV_DYNAMIC_LIST) ( @ 7 )
Balázs Kéri

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: Re: working directory

2008-07-25T22:50:27Z

In the Execution menu under Execution parameters you have the option to choose the
working directory by adding a profile to your execution.

Manu

> -----Original Message-----
> From: eiffel_software@...
> [mailto:eiffel_software@...] On Behalf Of Jimmy J. Johnson
> Sent: Friday, July 25, 2008 5:38 PM
> To: eiffel_software@...
> Subject: [eiffel_software] Re: working directory
>
> I mean in EiffelStudio for debug mode. I can't find the option.
> where is it?
>
>
> --- In eiffel_software@..., "Emmanuel Stapf [ES]"
> <manus@...> wrote:
> >
> > What do you mean? In class EXECUTION_ENVIRONMENT you can change it
> during
> > execution. In EiffelStudio, you can also change the location where
> the program is
> > executed.
> >
> > Regards,
> > Manu
> >
> > > -----Original Message-----
> > > From: eiffel_software@...
> > > [mailto:eiffel_software@...] On Behalf Of Jimmy J.
> Johnson
> > > Sent: Friday, July 25, 2008 1:39 PM
> > > To: eiffel_software@...
> > > Subject: [eiffel_software] working directory
> > >
> > > Is there a way in 6.2 to change the working directory?
> > >
> > > jjj
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: working directory

2008-07-25T17:38:07Z

I mean in EiffelStudio for debug mode. I can't find the option.
where is it?

--- In eiffel_software@..., "Emmanuel Stapf [ES]"
<manus@...> wrote:
>
> What do you mean? In class EXECUTION_ENVIRONMENT you can change it
during
> execution. In EiffelStudio, you can also change the location where
the program is
> executed.
>
> Regards,
> Manu
>
> > -----Original Message-----
> > From: eiffel_software@...
> > [mailto:eiffel_software@...] On Behalf Of Jimmy J.
Johnson

> > Sent: Friday, July 25, 2008 1:39 PM
> > To: eiffel_software@...
> > Subject: [eiffel_software] working directory
> >
> > Is there a way in 6.2 to change the working directory?
> >
> > jjj
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>

RE: working directory

2008-07-25T15:48:13Z

What do you mean? In class EXECUTION_ENVIRONMENT you can change it during
execution. In EiffelStudio, you can also change the location where the program is
executed.

Regards,
Manu

> -----Original Message-----
> From: eiffel_software@...
> [mailto:eiffel_software@...] On Behalf Of Jimmy J. Johnson
> Sent: Friday, July 25, 2008 1:39 PM
> To: eiffel_software@...
> Subject: [eiffel_software] working directory
>
> Is there a way in 6.2 to change the working directory?
>
> jjj
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

working directory

2008-07-25T13:39:27Z

Is there a way in 6.2 to change the working directory?

jjj

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: [EiffelStudio 6.2] Avoid comment duplication

2008-07-24T16:51:04Z

Olivier, no need to submit a report any more. I've fixed the offending
code. If you are using the live repository (containing the 6.3
development version) then the fix is committed in rev#74194.

Paul.

--- In eiffel_software@..., "Paul Bates" <paul.bates@...>
wrote:

>
> Hi Olivier,
>
> I just tested out 6.3 build too and it does not work for attributes.
> Yes this is a bug. Could you file a report at http://support.eiffel.com?
>
> Thanks,
> Paul.
>
> --- In eiffel_software@..., "olivier.ligot"
> <olivier.ligot@> wrote:
> >
> > Hello,
> >
> > I'm testing the ability to avoid comment duplication by using the
> > <Precursor> in a descendant comment to reuse the parent one. It works
> > for functions but not for attributes (the contract view and the
> > interface view does not show the comments for the attributes using
> > <Precursor>). Is this a bug ?
> >
> > I'm using EiffelStudio 6.2.7.3753 Entreprise Edition on Windows.
> >
> > Thanks in advance,
> >
> > Olivier Ligot
> >
>

Re: [EiffelStudio 6.2] Avoid comment duplication

2008-07-24T09:00:36Z

Hi Olivier,

I just tested out 6.3 build too and it does not work for attributes.
Yes this is a bug. Could you file a report at http://support.eiffel.com?

Thanks,
Paul.

--- In eiffel_software@..., "olivier.ligot"
<olivier.ligot@...> wrote:

>
> Hello,
>
> I'm testing the ability to avoid comment duplication by using the
> <Precursor> in a descendant comment to reuse the parent one. It works
> for functions but not for attributes (the contract view and the
> interface view does not show the comments for the attributes using
> <Precursor>). Is this a bug ?
>
> I'm using EiffelStudio 6.2.7.3753 Entreprise Edition on Windows.
>
> Thanks in advance,
>
> Olivier Ligot
>

Re: Bugs in i18n Library

2008-07-24T05:37:23Z

Indeed. The fix has been committed. Thanks Olivier.

Ted

--- In eiffel_software@..., "olivier.ligot"
<olivier.ligot@...> wrote:

>
> One more:
>
> The arguments in {I18N_DUMMY_DICTIONARY}.has_plural,
> {I18N_DUMMY_DICTIONARY}.singular and {I18N_DUMMY_DICTIONARY}.plural
> should contain STRING_GENERAL instead of STRING_32, as declared in the
> parent I18N_DICTIONARY. Otherwise, EiffelStudio 6.2 will detect a
> catcall at runtime.
>
> Best regards,
>
> Olivier Ligot
>

Re: Bugs in i18n Library

2008-07-24T02:04:38Z

One more:

The arguments in {I18N_DUMMY_DICTIONARY}.has_plural,
{I18N_DUMMY_DICTIONARY}.singular and {I18N_DUMMY_DICTIONARY}.plural
should contain STRING_GENERAL instead of STRING_32, as declared in the
parent I18N_DICTIONARY. Otherwise, EiffelStudio 6.2 will detect a
catcall at runtime.

Best regards,

Olivier Ligot

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[EiffelStudio 6.2] Avoid comment duplication

2008-07-24T01:42:03Z

Hello,

I'm testing the ability to avoid comment duplication by using the
<Precursor> in a descendant comment to reuse the parent one. It works
for functions but not for attributes (the contract view and the
interface view does not show the comments for the attributes using
<Precursor>). Is this a bug ?

I'm using EiffelStudio 6.2.7.3753 Entreprise Edition on Windows.

Thanks in advance,

Olivier Ligot

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: Redirecting standard file output to a string.

2008-07-23T16:34:46Z

> I went back into the vault and found that STD_FILES actually used to use
> IO_MEDIUM.

Out of curiosity I checked what I could. In 1990, it was using FILE, in 1993 it was using UNIX_FILE and was switched to PLAIN_TEXT_FILE in 1994. So I'm wondering from where you had IO_MEDIUM. Do you remember which version it was?

Regards,
Manu

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: Redirecting standard file output to a string.

2008-07-23T16:15:45Z

Hi Manu!

I went back into the vault and found that STD_FILES actually used to use
IO_MEDIUM.
In fact, I had made use of that to define a new class BUFFER_MEDIUM to
support redirection of print statements for a macro facility feedback
mechanism. It worked quite nicely as I recall. I had my own version of
STD_FILEs that simply redefined a few things from the standard one and
excluded the original from my Ace file.
I guess is safe to assume that won't work anymore :)

R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: RE: [eiffel_software] Redirecting standard file output to a
> string.
> From: "Emmanuel Stapf [ES]" <manus@...>
> Date: Wed, July 23, 2008 6:37 pm
> To: <eiffel_software@...>
> > I was wondering why STD_FILES uses PLAIN_TEXT_FILE for input, output
> > and error, rather than IO_MEDIUM.
> Actually I'm not sure why. Most likely the plain text nature of the output has to
> do with this. There are some features such as `flush' and `read_word' which are
> useful but not present in IO_MEDIUM.
>
> > The reason I ask, is that doing so makes it difficult (and time
> > consuming) to redirect the output to a string. I found myself having to
> > create an ugly descendant of PLAIN_TEXT_FILE, which wrote to a string
> > instead of using the C file-output functions. It would have been more
> > elegant and quicker had IO_MEDIUM been the base class.
> Make sense.
>
> > Has STD_FILES chosen too specific a type for these features? And is
> > there a better way of re-directing the io.output to a string?
> At the moment, I don't see an easy way.
> Regards,
> Manu

RE: Redirecting standard file output to a string.

2008-07-23T15:37:37Z

> I was wondering why STD_FILES uses PLAIN_TEXT_FILE for input, output
> and error, rather than IO_MEDIUM.

Actually I'm not sure why. Most likely the plain text nature of the output has to
do with this. There are some features such as `flush' and `read_word' which are
useful but not present in IO_MEDIUM.

> The reason I ask, is that doing so makes it difficult (and time
> consuming) to redirect the output to a string. I found myself having to
> create an ugly descendant of PLAIN_TEXT_FILE, which wrote to a string
> instead of using the C file-output functions. It would have been more
> elegant and quicker had IO_MEDIUM been the base class.

Make sense.

> Has STD_FILES chosen too specific a type for these features? And is
> there a better way of re-directing the io.output to a string?

At the moment, I don't see an easy way.

Regards,
Manu

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Re: formatted output

2008-07-23T15:28:35Z

Helmut Brandl wrote:
>
> 4. Freeze the interface part of FreeELKS and allow only
> implementation improvements, in order to bind FreeELKS
> to the standard (to avoid divergence in the future).

I don't like the idea of freezing the interface of FreeELKS. We want to keep
improving it, slowly and carefully.

Helmut, do you know about the FreeELKS mailing list?

freeelks-devel@...

- Peter Gummer

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: Re: formatted output

2008-07-23T15:12:33Z

> That is one possibility. Make a reference implementation of what is
> considered to be standard and define the flat short form to be the
> standard. This has the advantage that it is something which really
> exists and is not just paperwork. I have proposed this already to Manu
> as one possibility.
>
> If thats the way, in my opinion the following is necessary:
>
> 1. Clean up FreeELKS to be compliant with the ECMA Eiffel standard (that
> is currently not yet the case, but the differences are not that big)

This is in our agenda but we are doing it at our own pace to ensure that no
breaking changes are imposed on our users.

> 2. Agree on what is considered standard (it could be all, but there are
> some very implementation specific classes in FreeELKS which might not
> make sense to be part of the standard).

Definitely and this is what we are working on. We started FreeELKS by using ISE's
EiffelBase library. This library has some external dependency of the ELKS classes
to non-ELKS classes which cause many other classes to be present in FreeELKS. Give
it some time and this will be cleaned up.

> 3. Extract the flat short documentation of the classes considered as
> standard and publish them within the ECMA Eiffel standard or some
> companion document (clearly a little bit "around" the flat short form
> would be necessary, but the major part could be the flat short form. It
> is great plus of Eiffel having the flat short form and design by
> contract.).

I've you heard of "Been there, done that" :-) This was more or less the idea
behind the original ELKS but it was a complete failure for interoperability.
Indeed, it lacks inheritance specification (thus the ISE's ARRAY/STRING classes
chose to make reference to classes outside ELKS) and it does not prevent someone
to add a feature to an existing class, which causes the code to most likely not
compile when you go from one compiler to another. The other part is that by only
providing specification, there is still some rooms for slightly different
behaviors between implementations.

This is why we want FreeELKS as is to become the next ELKS standard. The
specification is set by code and thus should work the same among various
compilers. The other idea we had for FreeELKS is that all Eiffel compilers should
be part of the development of FreeELKS to ensure that it works for them. If it
doesn't, then you could say that they are not a good Eiffel compiler.

> 4. Freeze the interface part of FreeELKS and allow only implementation
> improvements, in order to bind FreeELKS to the standard (to avoid
> divergence in the future).

By standardizing on an open source library such as FreeELKS you won't have that
problem and therefore it does not freeze the future innovation of the library
itself.

> What I want is a standardized set of libraries. Of course an agreement
> of what has to be in the standardized libraries might be difficult to
> reach. But I would be happy, if the Eiffel community agreed on the goal
> to have a standardized set of libraries and took some action to reach it.

To standardize ARRAY and STRING it took about 3 years. I don't think we want to
spend so much time on standardizing other libraries. I think compiler writers
should simply focus on FreeELKS and then any other library should compile with any
other Eiffel compilers, if it does not, then again, your compiler is not a good
enough Eiffel compiler.

Hope this helps,
Manu

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Re: formatted output

2008-07-23T08:07:43Z

Brian Heilig wrote:

> --- Helmut Brandl wrote:
>
>> [We need] a standardized set of libraries. This is not
>> yet the case with Eiffel.
>>
>
>
>> Now you can say, that we have FreeELKS. But what of FreeELKS is
>> considered as standard?
>>
>
> Well, it has the word Standard in it. Would you be happy if ISO put a
> stamp on it? I know it's out-of-the box thinking, but what's wrong
> with having the code be the standard? It has some advantages:
>
> * It guarantees compatibility
> * It comes with its own reference implementation
> * No need to maintain separate implementations
> * It is completely unambiguous
> * No need to maintain separate documents
>
> Maybe all that's missing is a mention in ECMA-367 that FreeELKS is the
> Library Kernel Standard.
>
> What about FreeELKS being used as the standard library do you dislike?
>
> Brian
>
>
>

That is one possibility. Make a reference implementation of what is
considered to be standard and define the flat short form to be the
standard. This has the advantage that it is something which really
exists and is not just paperwork. I have proposed this already to Manu
as one possibility.

If thats the way, in my opinion the following is necessary:

1. Clean up FreeELKS to be compliant with the ECMA Eiffel standard (that
is currently not yet the case, but the differences are not that big)

2. Agree on what is considered standard (it could be all, but there are
some very implementation specific classes in FreeELKS which might not
make sense to be part of the standard).

3. Extract the flat short documentation of the classes considered as
standard and publish them within the ECMA Eiffel standard or some
companion document (clearly a little bit "around" the flat short form
would be necessary, but the major part could be the flat short form. It
is great plus of Eiffel having the flat short form and design by contract.).

4. Freeze the interface part of FreeELKS and allow only implementation
improvements, in order to bind FreeELKS to the standard (to avoid
divergence in the future).

But I don't know if this is the way the ECMA committee wants to go.

What I want is a standardized set of libraries. Of course an agreement
of what has to be in the standardized libraries might be difficult to
reach. But I would be happy, if the Eiffel community agreed on the goal
to have a standardized set of libraries and took some action to reach it.

Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: formatted output

2008-07-23T06:38:06Z

--- Helmut Brandl wrote:
> [We need] a standardized set of libraries. This is not
> yet the case with Eiffel.

> Now you can say, that we have FreeELKS. But what of FreeELKS is
> considered as standard?

Well, it has the word Standard in it. Would you be happy if ISO put a
stamp on it? I know it's out-of-the box thinking, but what's wrong
with having the code be the standard? It has some advantages:

* It guarantees compatibility
* It comes with its own reference implementation
* No need to maintain separate implementations
* It is completely unambiguous
* No need to maintain separate documents

Maybe all that's missing is a mention in ECMA-367 that FreeELKS is the
Library Kernel Standard.

What about FreeELKS being used as the standard library do you dislike?

Brian

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Re: formatted output

2008-07-23T06:20:29Z

Howard Thomson wrote:

> Hi,
>
> There appears to be some confusion over what the term
> 'kernel library' means.
>
> To me, it means the set of classes whose implementation is
> tightly bound to a specific compiler, such as gec [the Gobo
> Eiffel Compiler] or ec [ISE's Eiffel Compiler from EiffelStudio].
>
> While the implementation of these classes are compiler dependent,
> their interface to other classes that do not, and do not need to, contain
> external "C" [or "C++" etc], are standardized such that all other pure
> Eiffel classes can be used with any implementation of the kernel classes.
>
> The only pure Eiffel classes in the kernel class set are those, such as HASHABLE,
> on which compiler dependent classes, such as INTEGER_32_REF depend.
>
> All other pure Eiffel classes, such as the structure library, are outside the 'kernel' and
> are, or should be, useable with any Eiffel standard implementation.
>
> Regards
>
> Howard Thomson
>
>

Hello Howard,

you are absolutely right concerning the implementation aspect and I
agree with you 100%. It is good practice to define a set of classes
(maybe called kernel) to provide the functions which need support by the
specific compiler or the operating system. Then you can build on these
functions more complex functionality.

But if you focus on the usability you get a different picture. As a
user, you are not interested on how the things are implemented. Look at
the famous "printf" function in C. Using your definition of kernel, it
would not belong to the kernel. You can implement printf completely in C
based e.g. putc or puts. However it belongs to "standard input output"
(i.e. stdio.h). Why? Because the inventors of C considered printf such a
basic function that each user can expect it to be available on a
standard C compiler. Wasn't it a very wise decision ...... ?

Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Volunteers needed to create exam focused on application security

2008-07-23T05:21:59Z

The Open Web Application Security Project (OWASP) is working on
creating a new certification around Web Application Security and are
looking for volunteer contributors. If you are interested in joining,
please subscribe to the mailing list at:
https://lists.owasp.org/mailman/listinfo/owasp-cert

Upon joining, please introduce yourself...

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: formatted output

2008-07-23T04:09:52Z

Hi,

There appears to be some confusion over what the term
'kernel library' means.

To me, it means the set of classes whose implementation is
tightly bound to a specific compiler, such as gec [the Gobo
Eiffel Compiler] or ec [ISE's Eiffel Compiler from EiffelStudio].

While the implementation of these classes are compiler dependent,
their interface to other classes that do not, and do not need to, contain
external "C" [or "C++" etc], are standardized such that all other pure
Eiffel classes can be used with any implementation of the kernel classes.

The only pure Eiffel classes in the kernel class set are those, such as HASHABLE,
on which compiler dependent classes, such as INTEGER_32_REF depend.

All other pure Eiffel classes, such as the structure library, are outside the 'kernel' and
are, or should be, useable with any Eiffel standard implementation.

Regards

Howard Thomson

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

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: formatted output

2008-07-22T19:19:46Z

Peter Gummer wrote:

> Maybe I'm going nuts, but Helmut's complaint that FORMAT_INTEGER is not in
> ELKS, and Manu's apparent acceptance of this, contradict Roger's helpful
> observation that FORMAT_INTEGER is in fact in ELKS. It's in the ELKS support
> cluster. I just double checked this.
>
> Formatted output _is_ available in ELKS, so what's the problem?
>
> - Peter Gummer
>
>

Peter,

let me try to make my point again. The goal is to win more people to use
Eiffel, which we all on this list think is a very good programming
language. For many people, especially companies, one important
precondition is to have a standardized language and a standardized set
of libraries. This is not yet the case with Eiffel. We have the ECMA
Eiffel specification which does a very good job in standardizing the
language. But it is the pure and naked language!! We have nearly nothing
(only some features of the class ANY mentioned in the ECMA standard)
comparable with respect to standard functions.

Now you can say, that we have FreeELKS. But what of FreeELKS is
considered as standard? Is it only the kernel (I think, that was the
remark of Manu, that only the kernel is going to be standardized)? Is it
also the support cluster? Are all clusters be considered as part of the
standard library?

So again: I do not complain that something is not available. I try to
convince the Eiffel community, that we have to specify, what basic
functions belong to the standard and what is optional. I don't know if
there is a chance to reach an agreement on this point.

By the way, there is a document on Bertrand's homepage (I don't know, if
it is still there) which obviously is a working draft describing ELKS
for standard Eiffel. This working draft mentions only the kernel classes
as ELKS classes (without FORMAT_INTEGER). No support cluster, no
structures cluster etc. So it is easy to find out, what is all available
in the Eiffel world, but it is very difficult to answer the question:
"What basic functions must be provided by a standard conformant compiler?".

Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: formatted output

2008-07-22T17:28:35Z

Roger Osmond wrote:

> You can use the FORMAT_INTEGER class (in ELKS support lib) ...

And Helmut Brandl replied:

> ... I was hoping that formatted output were available within the
> kernel library in order to have something portable across different
> compilers.

To which Emmanuel Stapf replied:

> It would not be the kernel library anymore. The idea behind ELKS
> was the minimal set of classes that can be shared among various
> implementations. What you are suggesting is a layer on top of ELKS
> ...

Maybe I'm going nuts, but Helmut's complaint that FORMAT_INTEGER is not in
ELKS, and Manu's apparent acceptance of this, contradict Roger's helpful
observation that FORMAT_INTEGER is in fact in ELKS. It's in the ELKS support
cluster. I just double checked this.

Formatted output _is_ available in ELKS, so what's the problem?

- Peter Gummer

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: formatted output

2008-07-22T13:48:57Z

Hi Helmut!

I didn't assume you were advocating layer violations :) I apologize if
that's what it seems I was saying.
I agree that a more complete 'standard functionality' is an important
ingredient for success. I'm pretty sure most in the Eiffel community
would agree as well. How and when we get there is another matter.

Perhaps such a thing could be accomplished unofficially, from the
available libraries. You know, defacto standards are standards too :)
I am not advocating any sort of insurgency here, but a best-practices
paper on the topic might be quite worthwhile (to be published in the
usual places). Each of us has favorites of course, and there already
are lists of libraries, but nothing in that form as far as I know.

Thanks
R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: Re: [eiffel_software] formatted output
> From: Helmut Brandl <helmut.brandl@...>
> Date: Tue, July 22, 2008 4:00 pm
> To: eiffel_software@...
> Roger,
> sorry that I did not make my point very well. I was not talking about
> mixing layers. Clearly it is good design to separate a minimal set of
> kernel functions from something which can be built on top of the kernel
> functionality.
> I was talking about a set of standard functionality which will be
> encountered on any Eiffel installation. In other words a set of standard
> functions on which I can base my application.
> Regards
> Helmut
> http://www.sourceforge.net/projects/tecomp
> http://tecomp.sourceforge.net
> rfo@... wrote:
> > Thanks Manu!
> >
> > I couldn't have said it better myself. Formatted IO, while seemingly
> > everywhere, does not rise to kernel status. That said, there's no
> > reason it can't be eveywhere in Eiffel also, and still keep ELKS the way
> > it should be. We need to avoid layer confusion as much as we need to
> > make Eiffel more acceptable.
> >
> > R
> >
> > ==================================================
> > Roger F. Osmond
> > ----------------------------------------
> > Amalasoft Corporation
> > 273 Harwood Avenue
> > Littleton, MA 01460
> >
> >
> >> -------- Original Message --------
> >> Subject: RE: [eiffel_software] formatted output
> >> From: "Emmanuel Stapf [ES]" <manus@...>
> >> Date: Tue, July 22, 2008 2:37 pm
> >> To: <eiffel_software@...>
> >>
> >>> I hope it is possible to convince the standardization committee to
> >>> include this very basic functionality into the kernel library. This
> >>>
> >> It would not be the kernel library anymore. The idea behind ELKS was the minimal set of classes that can be shared among various implementations. What you are suggesting is a layer on top of ELKS and as long as the library is entirely written in Eiffel then it should work on all Eiffel implementations making the need for a standardization less critical.
> >> Regards,
> >> Manu
> >>
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >

Re: formatted output

2008-07-22T12:54:07Z

Roger,

sorry that I did not make my point very well. I was not talking about
mixing layers. Clearly it is good design to separate a minimal set of
kernel functions from something which can be built on top of the kernel
functionality.

I was talking about a set of standard functionality which will be
encountered on any Eiffel installation. In other words a set of standard
functions on which I can base my application.

Regards
Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

rfo@... wrote:

> Thanks Manu!
>
> I couldn't have said it better myself. Formatted IO, while seemingly
> everywhere, does not rise to kernel status. That said, there's no
> reason it can't be eveywhere in Eiffel also, and still keep ELKS the way
> it should be. We need to avoid layer confusion as much as we need to
> make Eiffel more acceptable.
>
> R
>
> ==================================================
> Roger F. Osmond
> ----------------------------------------
> Amalasoft Corporation
> 273 Harwood Avenue
> Littleton, MA 01460
>
>
>> -------- Original Message --------
>> Subject: RE: [eiffel_software] formatted output
>> From: "Emmanuel Stapf [ES]" <manus@...>
>> Date: Tue, July 22, 2008 2:37 pm
>> To: <eiffel_software@...>
>>
>>> I hope it is possible to convince the standardization committee to
>>> include this very basic functionality into the kernel library. This
>>>
>> It would not be the kernel library anymore. The idea behind ELKS was the minimal set of classes that can be shared among various implementations. What you are suggesting is a layer on top of ELKS and as long as the library is entirely written in Eiffel then it should work on all Eiffel implementations making the need for a standardization less critical.
>> Regards,
>> Manu
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

RE: formatted output

2008-07-22T12:36:30Z

Thanks Manu!

I couldn't have said it better myself. Formatted IO, while seemingly
everywhere, does not rise to kernel status. That said, there's no
reason it can't be eveywhere in Eiffel also, and still keep ELKS the way
it should be. We need to avoid layer confusion as much as we need to
make Eiffel more acceptable.

R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: RE: [eiffel_software] formatted output
> From: "Emmanuel Stapf [ES]" <manus@...>
> Date: Tue, July 22, 2008 2:37 pm
> To: <eiffel_software@...>
> > I hope it is possible to convince the standardization committee to
> > include this very basic functionality into the kernel library. This
> It would not be the kernel library anymore. The idea behind ELKS was the minimal set of classes that can be shared among various implementations. What you are suggesting is a layer on top of ELKS and as long as the library is entirely written in Eiffel then it should work on all Eiffel implementations making the need for a standardization less critical.
> Regards,
> Manu

Re: formatted output

2008-07-22T12:32:35Z

Emmanuel Stapf [ES] wrote:

>> I hope it is possible to convince the standardization committee to
>> include this very basic functionality into the kernel library. This
>>
>
> It would not be the kernel library anymore. The idea behind ELKS was the minimal set of classes that can be shared among various implementations. What you are suggesting is a layer on top of ELKS and as long as the library is entirely written in Eiffel then it should work on all Eiffel implementations making the need for a standardization less critical.
>
> Regards,
> Manu
>
>
>

I agree, that the kernel ELKS is more critical. But I still consider
formatted input/output as something very, very basic. Even if
implemented completely in Eiffel (this is a good thing anyhow) it should
be required to be available on any Eiffel installation. Consider the
example of C. On each installation I find the 15 headers

assert.h, float.h, math.h, stdarg.h, stdlib.h, ctype.h, limits.h,
setjmp.h, stddef.h, string.h, errno.h, locale.h, signal.h stdio.h
and time.h

because this is required by the ANSI standard. The same applies to C++
with more standard libraries. This is a great plus. I can write
considerable applications without leaving the standard. With Eiffel
currently I do not even have the kernel. And this after more than 20
years ....

I hope, that my remarks are not considered as being negative.

Regards

Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: formatted output

2008-07-22T11:37:31Z

> I hope it is possible to convince the standardization committee to
> include this very basic functionality into the kernel library. This

It would not be the kernel library anymore. The idea behind ELKS was the minimal set of classes that can be shared among various implementations. What you are suggesting is a layer on top of ELKS and as long as the library is entirely written in Eiffel then it should work on all Eiffel implementations making the need for a standardization less critical.

Regards,
Manu

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/