external C

[helmut.brandl]

I was wondering of having so many features with "external C" within
FreeELKS.

The "external C"s I have reviewed are related to the specific ISE
implementation of Eiffel (i.e. they are tied to the runtime of
EiffelStudio).

This makes FreeELKS hard to use for the Eiffel compiler "tecomp",
because it has a different implementation of its runtime. Since it is
able to execute Eiffel code directly in its virtual machine without
going over C (in its basic version, it works like an interpreter in
order to make it very easy to use for beginners of Eiffel), "external C"
in the kernel is disturbing. I would like to make tecomp FreeELKS
compatible. But I do not like the idea of building a lot of hooks into
it to handle the references to the EiffelStudio runtime.

What about converting the "external C"s to "external built_in"s? This
gives any Eiffel compiler freedom to implement them.

 From my point of view "external C" in Eiffel is a mechanism to link to
functions written in C. It should not be a constraint for Eiffel
compilers to clone (or adapt to) a certain runtime.


Regards
Helmut

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


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin LeMahieu]

I don't see why you couldn't re implement these classes to fit your compiler.  At some point the abstract Eiffel code needs to be translated to a machine specific implementation.  Right now the target machine implementation for FreeELKS is a C library.

Base C implementations have similar issues, when porting to a new platform you need to reimplement libc; I cannot copy the libc from a Windows machine and use it on a new Motorola chip.  Your reimplementation should export the same interface; using subclassing in eiffel can help you with this as can the project-level class renaming when you have a reimplemented version complete.

On Mon, Jul 28, 2008 at 4:55 PM, Helmut Brandl <[hidden email]> wrote:

I was wondering of having so many features with "external C" within
FreeELKS.

The "external C"s I have reviewed are related to the specific ISE
implementation of Eiffel (i.e. they are tied to the runtime of
EiffelStudio).

This makes FreeELKS hard to use for the Eiffel compiler "tecomp",
because it has a different implementation of its runtime. Since it is
able to execute Eiffel code directly in its virtual machine without
going over C (in its basic version, it works like an interpreter in
order to make it very easy to use for beginners of Eiffel), "external C"
in the kernel is disturbing. I would like to make tecomp FreeELKS
compatible. But I do not like the idea of building a lot of hooks into
it to handle the references to the EiffelStudio runtime.

What about converting the "external C"s to "external built_in"s? This
gives any Eiffel compiler freedom to implement them.

 From my point of view "external C" in Eiffel is a mechanism to link to
functions written in C. It should not be a constraint for Eiffel
compilers to clone (or adapt to) a certain runtime.


Regards
Helmut

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


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Peter Gummer-2]

Colin LeMahieu wrote:

> I don't see why you couldn't re implement these classes to fit
> your compiler.

But then it wouldn't be FreeELKS any more. It would be HelmutELKS :-)

As Manu and Eric have pointed out, FreeELKS is not just an interface, it's
an implementation too. If someone swaps in their own different
implementation, then it isn't FreeELKS any more, is it?

- Peter



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Colin LeMahieu wrote:

> I don't see why you couldn't re implement these classes to fit your
> compiler.  At some point the abstract Eiffel code needs to be
> translated to a machine specific implementation.  Right now the target
> machine implementation for FreeELKS is a C library.
>
> Base C implementations have similar issues, when porting to a new
> platform you need to reimplement libc; I cannot copy the libc from a
> Windows machine and use it on a new Motorola chip.  Your
> reimplementation should export the same interface; using subclassing
> in eiffel can help you with this as can the project-level class
> renaming when you have a reimplemented version complete.
>

Clearly I can patch (or reimplement -- put the wording as you like) the
features of FreeELKS in a way that they fit into my compiler without
changing the external interface. No problem with that. But I had the
impression that FreeELKS had a different purpose.

May be I am wrong, but the basic idea behind FreeELKS is to be a
reference implementation that can be run on any compiler. I would
support that idea, because it gives the users some confidence that if
they build their application of FreeELKS, they are portable across
compilers.

There are different ways to reach portablity. Having a reference
implementation is one way. I thought that FreeELKS had chosen to go that
way.

But tell me, if I am wrong!

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


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Emmanuel Stapf]

> I was wondering of having so many features with "external C" within
> FreeELKS.

Because of historical reason but also for practical reason. I would distinguish 2
cases:
1 - cases of externals specific to the Eiffel Software implementation (MEMORY,
INTERNAL, GC_INFO, ....)
2 - cases of externals needed to wrap OS facilities (I/O, ...)

What we need is to extract the C routine called for #2 into C inline routines or
built_in. For #1, I think we could remove those classes from FreeELKS gradually
until the library is sound.
 
> order to make it very easy to use for beginners of Eiffel), "external C"
> in the kernel is disturbing. I would like to make tecomp FreeELKS
> compatible. But I do not like the idea of building a lot of hooks into
> it to handle the references to the EiffelStudio runtime.

I know this is annoying. We have the same problem for our .NET implementation
which does not rely on the C runtime library but on the .NET runtime library. For
the moment, we override those classes in our .NET distribution but this is not so
great, because it requires a lot more maintenance work if those classes are going
to change a lot.
 
Regards,
Manu


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel