when I was testing a piece of code, I tried to use the reverse- procedure which is described in the string class interface. This small sample code will not compile, saying that reverse is an unknown identifier. Is my code wrong, or is the error on the compiler side?
class ROOT_CLASS creation make
feature test: STRING
feature make is do io.readline test:=clone(io.laststring) test.reverse end -- make end--class
> when I was testing a piece of code, I tried to use the reverse- > procedure which is described in the string class interface. This small > sample code will not compile, saying that reverse is an unknown > identifier. Is my code wrong, or is the error on the compiler side?
> class ROOT_CLASS > creation make
> feature test: STRING
> feature make is do > io.readline > test:=clone(io.laststring) > test.reverse > end -- make > end--class
> Kind regards, > Jan Pellegrims
It depends which compiler and which library you use. You have to look into the STRING class of your library and see, if it has a feature "reverse".
> when I was testing a piece of code, I tried to use the reverse- > procedure which is described in the string class interface. This small > sample code will not compile, saying that reverse is an unknown > identifier. Is my code wrong, or is the error on the compiler side?
> class ROOT_CLASS > creation make
> feature test: STRING
> feature make is do > io.readline > test:=clone(io.laststring) > test.reverse > end -- make > end--class
> Kind regards, > Jan Pellegrims
In the library of EiffelStudio there is a feature name "mirrored". It returns the reverse of the string. The feature "mirror" does inline reversal.
Unfortunately the kernel library is not standardized. Therefore different Eiffel compiler might have different kernel libraries (which is a bad thing).
I hope that the Eiffel standardization committee will also standardize the kernel library. Although of what I have heard up to now there is no activity in that direction. The reason seems to be that the members of the Eiffel standardization are all from EiffelStudio and they have no interest in open up competition for different Eiffel compilers.
> I hope that the Eiffel standardization committee will also standardize > the kernel library. Although of what I have heard up to now there is > no activity in that direction. The reason seems to be that the members > of the Eiffel standardization are all from EiffelStudio and they have > no interest in open up competition for different Eiffel compilers.
Maybe that cause there isn't any competition anymore?
GEC is not an option and all other compilers are dead or like yours haven' even reached alpha usability.
On Nov 15, 12:43 pm, llothar <scholz.lot...@gmail.com> wrote:
> > I hope that the Eiffel standardization committee will also standardize > > the kernel library. Although of what I have heard up to now there is > > no activity in that direction. The reason seems to be that the members > > of the Eiffel standardization are all from EiffelStudio and they have > > no interest in open up competition for different Eiffel compilers.
> Maybe that cause there isn't any competition anymore?
> GEC is not an option and all
Why not?
> other compilers are dead or like yours > haven' even reached alpha usability.
What do you mean by "alpha usability?". The major constraint in tecomp is, that there is not yet good support of libraries. But that is on purpose. Before providing a rich set of libraries, I want to reach full language compliance.
Anyhow. Have you tested tecomp lately? I yes, please give me some feedback of what you are missing. You are welcome to post feature request on the tracking system (http://sourceforge.net/tracker/? group_id=208120). Bugs are usually resolved very fast. For feature requests .... well it depends on the complexity.
On 15 Nov., 23:07, Helmut <helmut.bra...@gmx.net> wrote:
> > GEC is not an option and all
> Why not?
No assertion checking.
So what is the real usefull feature of Eiffel if you remove DbC? Multiple inheritance for sure is not. Also the C output it is not optimized in any way - it's slow.
Garbage collection, good object orientation, imperative programming style, generics, speed, DbC (with Smarteiffels stack traces pleaaaaassssseeee) and native executable are _my_ absolute requirements for using eiffel.
Remove one and it becomes worthless compared to other more active developed solutions. Only D would be a competitor but it is still worse then a 8 years old (patched) Smarteiffel.
> > other compilers are dead or like yours > > haven' even reached alpha usability.
> What do you mean by "alpha usability?".
Useful maybe for language testing only. Unless you provide C (or llvm or whatever target language you want to use) support and i can interface to the operating system and other libraries.
Also i never understood why you created an interpreter. I'm scared that the runtime performance is even to worse for developing. Please show some number when you have GEC compiling and running on your interpreter.
On Nov 15, 6:51 pm, llothar <scholz.lot...@gmail.com> wrote:
> Useful maybe for language testing only. Unless you provide > C (or llvm or whatever target language you want to use) support > and i can interface to the operating system and other libraries.
Usually an interface to C or anything else is only needed for very special things. Nearly nobody uses the C interface for java. The developers programming in java programs use java exclusively. The same applies to C#, php, python or whatever else you like. The interface to the operating system is usually done by libraries. This should be the normal way.
Don't get me wrong. I agree that a C opening is necessary. And it will be there as soon as compilation to native code is available. But it is currently not on the top of my priority list. If you are willing to write some project with tecomp and you need the C opening, I might change my mind. But you won't do that, because of the missing libraries in tecomp. Therefore I think that a good set of libraries have higher priorities than the C opening.
> Also i never understood why you created an interpreter. > I'm scared that the runtime performance is even to worse for > developing. Please show some number when you have GEC compiling > and running on your interpreter.
There are many languages for which only interpreters are available. Python, php, java (ok, java has jit), tcl, perl. And these languages are in use widespread. So they have their value. And tecomp is not an interpreter. The virtual machine is currently the only way to execute the code. But the core of the compiler is independent of the execution engine.
During development the execution of the code in a virtual machine really speeds up the development process enormously. The edit, compile, execute cycle is very fast. Try it. The compiler is really fast. Much faster than EiffelStudio.
But I agree: If you do heavy execution, code which is compiled to native is superior. I wouldn't run a compiler in a virtual machine. Code run in a virtual machine is always (unless you have a jit) one or two orders of magnitude slower than code compiled to native.
But soon you will have both possibilities. Virtual machine execution for fast development and compile to native for fast execution of the compiled code. Currently for the former you can use tecomp and for the latter you would have to use EiffelStudio (give me some time and you can use tecomp for both).
> Usually an interface to C or anything else is only needed for very > special things. Nearly nobody uses the C interface for java. The
Oh yes they do. Its just wrapped in something called "Java Runtime Environment" and "SWT" the Standard Widget Toolkit.
And this makes it the platform. Java was never a cross development platform it was always targeting a 15+ MB runtime on top of a OS. If your community/supporting company is big enough you only need libraries.
> the operating system is usually done by libraries. This should be the > normal way.
Right but given the fatal situation in eiffel land the library situation is beyond any reasonable polite comment.
> There are many languages for which only interpreters are available. > Python, php, java (ok, java has jit), tcl, perl. And these languages
Sorry they all only work because they come with huge libraries written in C while in Eiffel even the fundamental string operations are written in Eiffel. So your argument is irrelevant - script languages are a different world and environment.
So an interpreter without a very good jit (like llvm which can even transfrom all jit automatically to C) will not do anything then giving pain here.
> During development the execution of the code in a virtual machine > really speeds up the development process enormously. The edit, > compile, execute cycle is very fast. > Try it.
With what? Is it possible to execute gobo tools and gec? I ask because i don't know about any other eiffel project with a resaonable code base for a real world tool. I don't give to much about micro benchmark. They are good for developing the VM but have no meaning in real world.
See all these Java benchmarks that try to tell me that Java is fast. In reality it is not.
> The compiler is really fast. Much faster than EiffelStudio.
That shouldn't be difficult :-)
> But I agree: If you do heavy execution, code which is compiled to > native is superior. I wouldn't run a compiler in a virtual machine. > Code run in a virtual machine is always (unless you have a jit) one or > two orders of magnitude slower than code compiled to native.
Right and in real world projects you often need a lot of cpu power to reach a certain state in the run phase of the edit-compile-run cycle, for example if you develop a gui application you need to startup the whole application. If this is slow all your fast compilation is not worth a bit.
> But soon you will have both possibilities.
Well i wait and will see.
In the meantime i continue my development of Edison, an Eiffel inspirated language with a simplified single inheritance object structure.
At the current coding rate i expect to hit the SmallEiffel compiler limits in about 2 years or earlier if i have to go 64bit - there are somes serious bugs in the 64bit code.
On Nov 15, 9:48 pm, llothar <scholz.lot...@gmail.com> wrote:
> > There are many languages for which only interpreters are available. > > Python, php, java (ok, java has jit), tcl, perl. And these languages
> Sorry they all only work because they come with huge libraries > written > in C while in Eiffel even the fundamental string operations are > written > in Eiffel. So your argument is irrelevant - script languages are a > different world and environment.
The library part written in C doesn't need to be big. Only the time critical operations need to be written in C.
You are claiming that in Eiffel even the fundamental string operations are written in Eiffel. Maybe some implementations do it that way. But this has nothing to do with Eiffel. In tecomp all time critical operations on arrays (like inserting, copying ranges, filling elements, up-rotation, down-rotation are implemented in the virtual machine in plain C/C++, i.e. these operations run at native speed. There is no need to implement low level loops in Eiffel.
> With what? Is it possible to execute gobo tools and gec?
Why should I run gec in tecomp? Maybe for benchmarking reasons this might be interesting. If you want gec, just download it from the gobo site.
On 14 nov, 15:18, Helmut <helmut.bra...@gmx.net> wrote:
> On Nov 12, 5:11 am, Pelle <jan.pellegr...@gmail.com> wrote:
> > LS,
> > when I was testing a piece of code, I tried to use the reverse- > > procedure which is described in the string class interface. This small > > sample code will not compile, saying that reverse is an unknown > > identifier.
> In the library of EiffelStudio there is a feature name "mirrored". It > returns the reverse of the string. The feature "mirror" does inline > reversal.
|
