String reverse
Pelle
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
Helmut
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".
Helmut
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.
llothar
> 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.
Helmut
> > 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.
Regards
Helmut
http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net
llothar
> > 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.
Helmut
>
> 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).
llothar
> 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.
Helmut
>
> > 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.
Pelle
> 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.
>
the feature 'mirror' did the job.
Thanks,
Jan