headers
Markus Pilman | 1 Mar 2011 18:25
Picon

How is "rename" implemented in .NET

Hi all,

I am looking into the way Eiffel implements multiple inheritance in .NET. I understood the trick with the
interfaces and the private fields (if I might call them like this), but there is still something I am
wondering how it is done: renaming.

How does Eiffel for .NET do that? Let's assume I have these classes:

class A

feature
  featureA is
      do
           -- my implementation
      end

end
-----------------------------------------
class B

feature
  featureA is
      do
           -- my implementation
      end

end
-----------------------------------------
class C
(Continue reading)

Permalink | Reply | 2 comments |
headers
rfo | 1 Mar 2011 19:47

problem install/compile 6.7 on linux

Hi All

I am just now trying to install and build 6.7 on a 32 bit CentOS 5.5
linux system, running in VmWare.
I have run 6.6 on CentOS 5.4 in the past (but the system died a horrible
death and we're not trying to rebuild it with more modern parts)

When attempting to build the base precompile, all is OK until it comes
time to link, and then I get a barrage of undefines for
__sync_val_compare_and_swap_4 and __sync_add_and_fetch.

My ISE_PLATFORM env var is linux-x86
The uname output shows a 2.6.18 SMP kernel and i686 architecture.
I am running gcc 4.1.2

Suggestions?

     R

==================================================
Roger F. Osmond

------------------------------------
Permalink | Reply | 1 comment |
headers
Emmanuel Stapf [ES] | 1 Mar 2011 19:55
Favicon

RE: How is "rename" implemented in .NET

> might call them like this), but there is still something I am wondering
> how it is done: renaming.

.Net let you define a routine that implements a routine with a different name and
this is what we use.

> If I now have a variable which has the static type A and the dynamic type
> C, a call to featureA has to be a call to C.other_featureA and not to
> C.featureA. To do this correctly, the implementation must take in account
> the static type of a variable. So how is this done in Eiffel?

All calls in .NET are done via the interface (the static type) never through the
implementation so that we can get the proper dynamic dispatch at runtime.

Hope this helps,
Manu

------------------------------------
Permalink | Reply | 1 comment |
headers
Emmanuel Stapf [ES] | 1 Mar 2011 19:56
Favicon

RE: Invalid operator expression

> product alias "*" (other: like Current): like Current

Looks like you need to create a small system reproducing the error, there is not enough information here.

Manu

------------------------------------
Permalink | Reply | 0 comments |
headers
Emmanuel Stapf [ES] | 1 Mar 2011 19:58
Favicon

RE: object once semantics: INTERNAL and deep_twin

> If you have an object once, let's call it "foo", INTERNAL will show you
> a field that has been created by the compiler (that's why I called it
> synthetic) named like _23234_foo_something.
> So, since the field has been added by the compiler, I'm surprised that
> INTERNAL is showing it.

This is indeed not expected, those attributes are supposedly hidden to the user.

> >  > 2. deep_twin already sets object once functions?

Currently it does indeed that. If you have good arguments against or in favor of
doing that, please let me know.

Regards,
Manu

------------------------------------
Permalink | Reply | 0 comments |
headers
Emmanuel Stapf [ES] | 1 Mar 2011 20:17
Favicon

RE: problem install/compile 6.7 on linux

We are using those routines when we detect GCC 4.1.2 which supposedly support those. But it looks like it
does not on your system.

Can you comment line 72 to 74 in the file $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/include/eif_scoop.h'
and recompile the C code of the precompiled from scratch?

Regards,
Manu

> -----Original Message-----
> From: eiffel_software@...
> [mailto:eiffel_software@...] On Behalf Of rfo@...
> Sent: Tuesday, March 01, 2011 10:47 AM
> To: Eiffel Studio Mail Group
> Subject: [eiffel_software] problem install/compile 6.7 on linux
> 
> Hi All
> 
> I am just now trying to install and build 6.7 on a 32 bit CentOS 5.5
> linux system, running in VmWare.
> I have run 6.6 on CentOS 5.4 in the past (but the system died a horrible
> death and we're not trying to rebuild it with more modern parts)
> 
> When attempting to build the base precompile, all is OK until it comes
> time to link, and then I get a barrage of undefines for
> __sync_val_compare_and_swap_4 and __sync_add_and_fetch.
> 
> My ISE_PLATFORM env var is linux-x86
> The uname output shows a 2.6.18 SMP kernel and i686 architecture.
> I am running gcc 4.1.2
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfo | 2 Mar 2011 00:21

RE: [eiffel_software] problem install/compile 6.7 on linux

Thank you Manu and David!

Commenting out the lines in eif_scoop.h did the trick.

I'm not certain though that the problem lies with gcc 4.1.2, or with
Eiffel.
As I said, we're rebuilding from bare metal, or saran-wrap I suppose,
because it's a VM.  It might be that VmWare is the issue, or it might be
that I'm missing a package or two.

     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: RE: [eiffel_software] problem install/compile 6.7 on linux
> From: "Emmanuel Stapf [ES]" <manus@...>
> Date: Tue, March 01, 2011 2:17 pm
> To: <eiffel_software@...>
> 
> 
> We are using those routines when we detect GCC 4.1.2 which supposedly support those. But it looks like it
does not on your system.
> 
> Can you comment line 72 to 74 in the file
$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/include/eif_scoop.h' and recompile the C code of the
precompiled from scratch?
> 
> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfo | 2 Mar 2011 00:27

arrays in a void safe world

Hi All

We've gone round and round a few times with Void safety, but things seem
to be settling down a bit, so it's time for me to ask what is likely a
really stupid question.

What is the correct way to use ARRAYs in which some of the slots will
necessarily, desirably and by design, be Void?

With 6.7 I'm getting a lot warnings about such arrays, even though their
signatures are (sometimes) [detachable <something or other>], as in
my_array: ARRAY [detachable STRING]

I was under the apparently mistaken impression that such a declaration
would shield me from the epithets being hurled by the compiler.

So how do I get in the compiler's good graces once more?  It seemed to
like me just fine in 6.6 but not anymore.

Thanks

     R

==================================================
Roger F. Osmond

------------------------------------
Permalink | Reply | 2 comments |
headers
Peter Gummer | 2 Mar 2011 00:32
Picon

Re: arrays in a void safe world

Roger wrote:

> With 6.7 I'm getting a lot warnings about such arrays, even though  
> their
> signatures are (sometimes) [detachable <something or other>], as in
> my_array: ARRAY [detachable STRING]

I haven't dared touch void safety yet, except in toy projects, but I'm  
curious. They are warnings, are they, not errors? What do the warnings  
say?

- Peter Gummer

------------------------------------
Permalink | Reply | 1 comment |
headers
rfo | 2 Mar 2011 01:12

RE: [eiffel_software] arrays in a void safe world

Hi Peter

They are indeed warnings, but the more ominous 'obsolete' variety.
This example does not have reference types, but it doesn't matter.

Warning code: Obsolete Call

Warning: call uses obsolete feature.
What to do: update to new feature at your earliest convenience. The
  feature is still available but may be removed in the future.

Class: ACCESS_POLICY
Feature: group_ids
Obsolete feature: make (min_index, max_index: INTEGER_32) (class ARRAY)
Obsolete message:  `make' is not void-safe statically. Use `make_empty'
or `make_filled' instead. [07-2010]			

     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] arrays in a void safe world
> From: Peter Gummer <p-gummer@...>
> Date: Tue, March 01, 2011 6:32 pm
> To: eiffel_software@...
> 
> 
> Roger wrote:
(Continue reading)

Permalink | Reply | 7 comments |

Gmane