Loading ...
Sorry, an error occurred while loading the content.

[eiffel-nice-library] Re: ARRAY: insert or not

Expand Messages
  • Alexander Kogtenkov
    ... Dominique Colnet & Olivier Zendra ... In fact the question was should we include insert in the ARRAY or not . It does not matter how it is implemented.
    Message 1 of 17 , Sep 6, 1999
    • 0 Attachment
      Frieder Monninger wrote:

      >> because memory move is not supported in Eiffel. (I speak about
      >> the I386 here). It really can be done extremly fast - with in line
      >> assembly

      Dominique Colnet & Olivier Zendra

      >We don't rely on assembly code, since we trust the C compiler
      >to take care of these optimizations. We in fact write as much
      >as we can in Eiffel, trusting the Eiffel compiler to generate
      >good optimized C code.

      In fact the question was "should we include 'insert' in the ARRAY
      or not". It does not matter how it is implemented.

      regards,
      Alexander Kogtenkov
      Object Tools, Moscow
    • Frieder Monninger
      ... because memory move is not supported in Eiffel. (I speak about the I386 here). It really can be done extremly fast - with in line assembly Whats your real
      Message 2 of 17 , Sep 8, 1999
      • 0 Attachment
        At 08:55 01.09.99 -0700, you wrote:
        >Frieder Monninger wrote:
        >
        >> As it is can be rather efficient to implement insert especially for
        >> an array of "extended" something in Runtime this feature will
        >> help that Eiffel will be more wildely used. (using for example
        >> a move from memory to memory)
        >>
        >> If it is not in the Runtime, it must be programmed "manually"
        >> in Eiffel with much ower performance.
        >
        >We don't agree. Our Eiffel compiler, SmallEiffel is written in
        >Eiffel, as are our libraries, with as little C as possible.
        >Our 'add' feature is _completely_ written in Eiffel and is very fast.
        >Why should efficiently optimized Eiffel be slow ???

        because memory move is not supported in Eiffel. (I speak about
        the I386 here). It really can be done extremly fast - with in line
        assembly

        Whats your real opinion :-) - not the "official" one ??

        --
        Frieder Monninger
        Object Tools GmbH

        fm@... --- http://www.object-tools.com
        Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031
      • dominique.colnet@loria.fr
        ... So SmallEiffel is bad, Visual Eiffel worse, and ISE EiffelBase an example to follow... This would be laughable if it were not a serious matter. We re not
        Message 3 of 17 , Sep 8, 1999
        • 0 Attachment
          Marcel Satchell wrote:

          > Not quite. ISE came first. EiffelBase is first among data structure
          > libraries. The SmallEiffel libraries are not well written - not the
          > last time I looked at them. They are a mess; the algorithmic integrity
          > is irrelevant (and may well be excellent), but the class texts
          > themselves,
          > what I have seen of them and the compiler texts, are something to be
          > ashamed of. Perhaps more recent versions are better. The VisualEiffel
          > libraries are even worse.

          So SmallEiffel is bad, Visual Eiffel worse, and ISE EiffelBase an
          example to follow... This would be laughable if it were not a serious
          matter.
          We're not going to follow on your flame war, which belongs to alt.flame.
          Anyone who has looked to the various Eiffel implementation and libraries,
          and to the development of Eiffel since 1986 knows better than that.

          > I'm a user. I do not want to see ELKS in any way compromise EiffelBase.
          > EiffelBase is more important, in my judgement, than ELKS.

          This is quite understandable, knowing that until recently you couldn't
          tell us whether you were speaking for ISE or not (see below).

          > I am not Emmanuel. I speak for myself.

          Ok, that's good to know.

          > I have a deep involvement in EiffelBase,

          That indeed explains things a bit.

          > but I do not speak for ISE. They seem not to be very
          > interested in this debate ... I wonder why?

          Indeed, why ? We'd love to have an official (not private e-mail) position
          for ISE in this NICE discussion. So far, the only official position is the
          one taken by Emmanuel when working with us on the initial ELKS 2000 proposal.



          --
          Dominique Colnet & Olivier Zendra

          ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
          ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
        • Frieder Monninger
          ... I decided not to vaste my time reading postings like this one by Marcel Satchell. Fortunately my mail system has a good filter [it recognises the original
          Message 4 of 17 , Sep 8, 1999
          • 0 Attachment
            At 02:00 08.09.99 -0700, you wrote:
            >Marcel Satchell wrote:
            >
            >> Not quite. ISE came first. EiffelBase is first among data structure
            >> libraries. The SmallEiffel libraries are not well written - not the
            >> last time I looked at them. They are a mess; the algorithmic integrity
            >> is irrelevant (and may well be excellent), but the class texts
            >> themselves,
            >> what I have seen of them and the compiler texts, are something to be
            >> ashamed of. Perhaps more recent versions are better. The VisualEiffel
            >> libraries are even worse.
            >
            >So SmallEiffel is bad, Visual Eiffel worse, and ISE EiffelBase an
            >example to follow... This would be laughable if it were not a serious
            >matter.

            I decided not to vaste my time reading postings like this one by Marcel
            Satchell.
            Fortunately my mail system has a good filter [it recognises the original
            sender],
            so the problem is solved already :-) - but this works not always as this mail
            came tru Dominique - so I read it.

            Its nice to hear such detailled, polite and qualified opinions about the VE
            libraries.
            We always thought they were clean, simple and easy to use - in our eyes the
            most important attributes of a library (and of a language - that's the
            reason I like
            Eiffel so much). But, maybe we are wrong :-(

            Btw, one of our libraries them got the second rank in the last Eiffel Class
            struggle -
            so at least 2-3 people (the judges) agreed apparently with out viewpoint.

            --
            Frieder Monninger
            Object Tools GmbH

            fm@... --- http://www.object-tools.com
            Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031
          • dominique.colnet@loria.fr
            ... Our real opinion is also our official one ;-) We don t rely on assembly code, since we trust the C compiler to take care of these optimizations. We in fact
            Message 5 of 17 , Sep 8, 1999
            • 0 Attachment
              Frieder Monninger wrote:

              > because memory move is not supported in Eiffel. (I speak about
              > the I386 here). It really can be done extremly fast - with in line
              > assembly
              >
              > Whats your real opinion :-) - not the "official" one ??

              Our real opinion is also our official one ;-)
              We don't rely on assembly code, since we trust the C compiler
              to take care of these optimizations. We in fact write as much
              as we can in Eiffel, trusting the Eiffel compiler to generate
              good optimized C code.


              --
              Dominique Colnet & Olivier Zendra

              ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
              ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
            • dominique.colnet@loria.fr
              ... Agreed. We were just answering Frieder s post, but we may indeed have been a bit off-topic. Also note that the current proposal uses add for ARRAY, since
              Message 6 of 17 , Sep 15, 1999
              • 0 Attachment
                Alexander Kogtenkov wrote:

                > Frieder Monninger wrote:
                >
                > >> because memory move is not supported in Eiffel. (I speak about
                > >> the I386 here). It really can be done extremly fast - with in line
                > >> assembly
                >
                > Dominique Colnet & Olivier Zendra
                >
                > >We don't rely on assembly code, since we trust the C compiler
                > >to take care of these optimizations. We in fact write as much
                > >as we can in Eiffel, trusting the Eiffel compiler to generate
                > >good optimized C code.
                >
                > In fact the question was "should we include 'insert' in the ARRAY
                > or not". It does not matter how it is implemented.

                Agreed. We were just answering Frieder's post, but we may indeed
                have been a bit off-topic.

                Also note that the current proposal uses 'add' for ARRAY, since when
                the initial ELKS 2000 proposal was worked on, we (SmallEiffel team
                and Emmanuela Stapf, from ISE) tought it made more sense than
                'insert_x', especially when considering 'add_last' vs.'insert_last'...


                --
                Dominique Colnet & Olivier Zendra

                ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
                ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
              Your message has been successfully submitted and would be delivered to recipients shortly.