Hi All

I have been following the Javel and related discussions, and while I
admire the enthusiasm, I feel the focus on syntax and presentation is
off the mark.  While it is true that being "C-like" has been cited by
adopters of java, C++, and javascript it was not the reason they looked
at those languages in the first place, just icing on a cake they were
already eating.  They wanted that cake for another reason first.

This holds true for newly popular scripting languages as well.  They do
not resemble C so much, but they are popular.  Clearly it is not the
syntax that draws users to a language - or more precisely to a tool.  It
is something else.  There must be, as mentioned in one of the earlier
posts, a clear value to that user.  If the value is clear, then and only
then do other factors enter into consideration.  Pimping Eiffel's syntax
will do no more to help its popularity than genetically engineering
fuscia colored Brussels Sprouts will do for that much maligned
vegetable.

I confess that I do like the idea of -projecting- the semantics in
different -consumable- forms, but that is not the thing that will
attract new users to Eiffel.  It will appeal to those using Eiffel
already.  The challenge is to attract them in the first place.  This can
happen only when two things occur:
1.  Eiffel - as a tool - offers conspicuous value to the uneducated user
2.  Word of that value is spread quickly

I do not mean to imply that we need to attract only the ignorancia.  By
uneducated, I mean users who have not as yet imbibed of the Eiffel Kool
Aide.  A rule of marketing is that any time you have to educate your
user before they buy, they won't buy.

We all know the value of Eiffel, but it's not a single sugar-coated
pill.  It's more sophisticated than that.  For years, Bertrand and
Company (OK, family) tried to sell Eiffel by emphasizing the "Q" word.
Look around you - quality rarely attracts.  It's a second-order value
sadly.

What sells today?  Sexy, sweet, fun and easy.  Quality is not sexy -
though the converse can of course be true :)  Even cost effectiveness is
a second-order factor in this market.  It is only after a user is
attracted to a tool that the cost calculations enter the picture, and
then it's often subjective.

C offered portability and that was a HUGE value.  Forty years ago, it
was a important attractor.  It powered a revolution in technology.  We
have C to thank for near-standard operating systems.  Today's user takes
portability for granted.

C++ offered an easy way to play with classes.  Earlier adopters wanted
to learn OO because that was the sexiest thing in the Eighties (we
didn't get out much it seems).  That was a quarter century ago and a lot
has changed.  Many users moved to C++ when the C and C++ compilers
merged, migrating from ANSI C to C++ piece by piece.  Today's users take
objects for granted (even if most see only a tip of the object iceberg).

Java had, in addition to a massive marketing push thanks to Kim Polesi
et al, the ability to embed a working chunk of code into your browser
page.  The applet was a sexy attractor, and it was easy - almost no
coding at all.  The applet fell out of favor, but by then the mythology
of "write once, run anywhere" was well entrenched.  The C-like syntax
made it easy for those -already attracted by the core value proposition-
to make the transition to using the tool for other things, even though
those other things were not a great fit for the tool (users had invested
time and emotion into it).

Livescript/javascript was never very good as a language but has been
hugely successful as a tool.  The attractor was not the syntax, but the
ability to put into your web-based application or pages some logic that
would execute on the client.  It was initially appealing as a way to
speed things up, make things more dynamic, and to add a little more of
an application flavor to otherwise static content.  It's a hard language
to love, but it's still the best tool for the job it does.

I hope for the sake of civilization as a whole that the attractor for
Python is not the syntax.  Python had it's early adopters who probably
liked being able to create objects in a scripting language - at least
that was what intrigued me at first.  The syntax is at best a
second-order factor.  It's what's under the hood (bonnet for our British
friends) that offers value, in addition to being ubiquitous (read: easy
to get/use).

What I find to be common amongst these examples is that each offered a
strong attractor that was something other than syntax.  It was never
about the language or tool in its own right, but about the conspicuous
and timely value proposition if provided.

Eiffel has objects.  So what?.  Every language these days has objects.
Eiffel has stronger semantics.  So what?  Rank and file users simply
don't care.
Eiffel is more self-consistent.  So what?  Only purists care about such
things.
Eiffel has the best support for DbC.  So what?  I can get DbC (sort of)
for other languages.

The fact that Eiffel is MUCH better at objects, semantics, quality, DbC,
engineering and so on, is utterly uninteresting to non-Eiffelists and
anyone else other than perhaps computer linguists.  That it is better
comes into the picture only -after- a user has been attracted to it in
the first place.  I'm not saying it's not hugely important, I'm saying
it's not a huge initial attractor.

The key to increasing Eiffel's popularity is to make it -conspicuously-
valuable to the user that doesn't use it yet.  That means it must be
attractive to less sophisticated users.  It's not the language that is
the problem!  It has been suggested many times, including in these
threads, that we need to focus on frameworks and other high-value
mechanisms.  I agree.  We also need to make Eiffel the best tool for
doing really attractive things.

Those things must appeal to the youthful segment, not just to mossbacks
like myself.  Our target market came of age long after the language
wars, long after the performance wars, long after most of the struggles
that have made us who we are.

The new user expects and demands immediate gratification.  We cannot
expect them to follow some quasi-monastic discipline before realizing
value.  They want it now, and our competitors are giving it to them.  C
is not the future.  It's a quaint artifact.  Java is not the future.
Compiled languages in general are not the future, at least in the mass
market.  Simply put, it's script or the crypt.  Eiffel needs a scripted
implementation and a sexy/sweet/fun/easy (SSFE) horse to ride.  It needs
to become the tool of choice for multiscreen (mobile, tablet, pc, tv)
apps.

Have a look at the Corona framework from Ansca.  It uses Lua as its
language.  Its focus is mobile game development, but it's an example of
SSFE.  It could just as easily have used Eiffelscript had that existed
(note the avoidable of camelCase).  An Eiffelscript interpreter could be
included free in new Linux distros and made yum-able for existing ones.

Eiffelscript should, as I said long long ago, be able to mix in compiled
Eiffel too.  Bertrand, years ago, cast Eiffel as the "great component
combinator".  It never quite got to that point, but he was right in
claiming that it could.  With the addition of Eiffelscript (better
called something else, perhaps simply "tower"), the reality might be
more achievable.  I imagine a tool/framework that lets users, by way of
the Eiffel interpreter, pull in components from multiple languages.
Eiffel gave us a glimpse of this in the compiled world with .NET -
better than any other language as it happens.  That dog don't hunt, so
it's time to move on to one that does.

So, lets' focus our considerable energy on the first-order challenge.
Let's focus on red vs white before we spend all of our energy debating
micro-regional soil conditions.

Thanks

R

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

I won't get into this debate much further, but we need to be aware that
those unwashed 'others' we keep talking about come in different flavours:

   * A - sometimes it's us (most of us have to use other languages as well)
   * B - there is a huge camp of Java-only and C#-only people, and a
     small number of C++ people (which we can treat as a single 'culture')
   * C - a very large camp of fast development people, centred on Python
     and Ruby
   * D - an equally big camp of web developers using various HTML
     derivatives, PHP and Javascript
   * E - the 'serious' open source patform developers - Linux, Apache etc
     - these are all C people

It is groups B (my guess is this group dwarfs the rest, large as they
may be), and E that I would hope to engage with Javel. Making the other
groups interested requires different things completely, which we have
already spent quite some time on in nETC, and we need to solve, and
which I agree are 'more important' in any substantive sense.

- thomas


On 20/04/2012 13:27, rfo@... wrote:
>
> Hi All
>
> I have been following the Javel and related discussions, and while I
> admire the enthusiasm, I feel the focus on syntax and presentation is
> off the mark. While it is true that being "C-like" has been cited by
> adopters of java, C++, and javascript it was not the reason they looked
> at those languages in the first place, just icing on a cake they were
> already eating. They wanted that cake for another reason first.
>
> This holds true for newly popular scripting languages as well. They do
> not resemble C so much, but they are popular. Clearly it is not the
> syntax that draws users to a language - or more precisely to a tool. It
> is something else. There must be, as mentioned in one of the earlier
> posts, a clear value to that user. If the value is clear, then and only
> then do other factors enter into consideration. Pimping Eiffel's syntax
> will do no more to help its popularity than genetically engineering
> fuscia colored Brussels Sprouts will do for that much maligned
> vegetable.
>
> I confess that I do like the idea of -projecting- the semantics in
> different -consumable- forms, but that is not the thing that will
> attract new users to Eiffel. It will appeal to those using Eiffel
> already. The challenge is to attract them in the first place. This can
> happen only when two things occur:
> 1. Eiffel - as a tool - offers conspicuous value to the uneducated user
> 2. Word of that value is spread quickly
>
> I do not mean to imply that we need to attract only the ignorancia. By
> uneducated, I mean users who have not as yet imbibed of the Eiffel Kool
> Aide. A rule of marketing is that any time you have to educate your
> user before they buy, they won't buy.
>
> We all know the value of Eiffel, but it's not a single sugar-coated
> pill. It's more sophisticated than that. For years, Bertrand and
> Company (OK, family) tried to sell Eiffel by emphasizing the "Q" word.
> Look around you - quality rarely attracts. It's a second-order value
> sadly.
>
> What sells today? Sexy, sweet, fun and easy. Quality is not sexy -
> though the converse can of course be true :) Even cost effectiveness is
> a second-order factor in this market. It is only after a user is
> attracted to a tool that the cost calculations enter the picture, and
> then it's often subjective.
>
> C offered portability and that was a HUGE value. Forty years ago, it
> was a important attractor. It powered a revolution in technology. We
> have C to thank for near-standard operating systems. Today's user takes
> portability for granted.
>
> C++ offered an easy way to play with classes. Earlier adopters wanted
> to learn OO because that was the sexiest thing in the Eighties (we
> didn't get out much it seems). That was a quarter century ago and a lot
> has changed. Many users moved to C++ when the C and C++ compilers
> merged, migrating from ANSI C to C++ piece by piece. Today's users take
> objects for granted (even if most see only a tip of the object iceberg).
>
> Java had, in addition to a massive marketing push thanks to Kim Polesi
> et al, the ability to embed a working chunk of code into your browser
> page. The applet was a sexy attractor, and it was easy - almost no
> coding at all. The applet fell out of favor, but by then the mythology
> of "write once, run anywhere" was well entrenched. The C-like syntax
> made it easy for those -already attracted by the core value proposition-
> to make the transition to using the tool for other things, even though
> those other things were not a great fit for the tool (users had invested
> time and emotion into it).
>
> Livescript/javascript was never very good as a language but has been
> hugely successful as a tool. The attractor was not the syntax, but the
> ability to put into your web-based application or pages some logic that
> would execute on the client. It was initially appealing as a way to
> speed things up, make things more dynamic, and to add a little more of
> an application flavor to otherwise static content. It's a hard language
> to love, but it's still the best tool for the job it does.
>
> I hope for the sake of civilization as a whole that the attractor for
> Python is not the syntax. Python had it's early adopters who probably
> liked being able to create objects in a scripting language - at least
> that was what intrigued me at first. The syntax is at best a
> second-order factor. It's what's under the hood (bonnet for our British
> friends) that offers value, in addition to being ubiquitous (read: easy
> to get/use).
>
> What I find to be common amongst these examples is that each offered a
> strong attractor that was something other than syntax. It was never
> about the language or tool in its own right, but about the conspicuous
> and timely value proposition if provided.
>
> Eiffel has objects. So what?. Every language these days has objects.
> Eiffel has stronger semantics. So what? Rank and file users simply
> don't care.
> Eiffel is more self-consistent. So what? Only purists care about such
> things.
> Eiffel has the best support for DbC. So what? I can get DbC (sort of)
> for other languages.
>
> The fact that Eiffel is MUCH better at objects, semantics, quality, DbC,
> engineering and so on, is utterly uninteresting to non-Eiffelists and
> anyone else other than perhaps computer linguists. That it is better
> comes into the picture only -after- a user has been attracted to it in
> the first place. I'm not saying it's not hugely important, I'm saying
> it's not a huge initial attractor.
>
> The key to increasing Eiffel's popularity is to make it -conspicuously-
> valuable to the user that doesn't use it yet. That means it must be
> attractive to less sophisticated users. It's not the language that is
> the problem! It has been suggested many times, including in these
> threads, that we need to focus on frameworks and other high-value
> mechanisms. I agree. We also need to make Eiffel the best tool for
> doing really attractive things.
>
> Those things must appeal to the youthful segment, not just to mossbacks
> like myself. Our target market came of age long after the language
> wars, long after the performance wars, long after most of the struggles
> that have made us who we are.
>
> The new user expects and demands immediate gratification. We cannot
> expect them to follow some quasi-monastic discipline before realizing
> value. They want it now, and our competitors are giving it to them. C
> is not the future. It's a quaint artifact. Java is not the future.
> Compiled languages in general are not the future, at least in the mass
> market. Simply put, it's script or the crypt. Eiffel needs a scripted
> implementation and a sexy/sweet/fun/easy (SSFE) horse to ride. It needs
> to become the tool of choice for multiscreen (mobile, tablet, pc, tv)
> apps.
>
> Have a look at the Corona framework from Ansca. It uses Lua as its
> language. Its focus is mobile game development, but it's an example of
> SSFE. It could just as easily have used Eiffelscript had that existed
> (note the avoidable of camelCase). An Eiffelscript interpreter could be
> included free in new Linux distros and made yum-able for existing ones.
>
> Eiffelscript should, as I said long long ago, be able to mix in compiled
> Eiffel too. Bertrand, years ago, cast Eiffel as the "great component
> combinator". It never quite got to that point, but he was right in
> claiming that it could. With the addition of Eiffelscript (better
> called something else, perhaps simply "tower"), the reality might be
> more achievable. I imagine a tool/framework that lets users, by way of
> the Eiffel interpreter, pull in components from multiple languages.
> Eiffel gave us a glimpse of this in the compiled world with .NET -
> better than any other language as it happens. That dog don't hunt, so
> it's time to move on to one that does.
>
> So, lets' focus our considerable energy on the first-order challenge.
> Let's focus on red vs white before we spend all of our energy debating
> micro-regional soil conditions.
>
> Thanks
>
> R
>
> ==================================================
> Roger F. Osmond
>
>


--
Ocean Informatics  *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>


*
*


[Non-text portions of this message have been removed]

Roger, I agree with all you have said.

I am teaching someone who has no knowledge of programming whatsoever to
model an engineering process, with which they are familiar, using Eiffel.
They are enjoying it and it is productive. They are learning system design
and, at the same time, increasing their knowledge and understanding of the
engineering process, Each is enhancing the other.

But this is an ideal situation. As I said in an earlier post, the
programming masses have already committed a significant portion of their
lives and a great deal of intellectual effort to doing what they do.
Nothing short of absolutely stunning is going to get their attention.

Regards
Dave.
David Williams
Software Team Leader & Intellectual Property Manager
email: dwilliams@...
tel: +44 1305 208341



From: <rfo@...>
To: "Eiffel Studio Mail Group" <eiffel_software@yahoogroups.com>
Date: 20/04/2012 13:28
Subject: [eiffel_software] eiffel popularity challenge
Sent by: eiffel_software@yahoogroups.com






Hi All

I have been following the Javel and related discussions, and while I
admire the enthusiasm, I feel the focus on syntax and presentation is
off the mark. While it is true that being "C-like" has been cited by
adopters of java, C++, and javascript it was not the reason they looked
at those languages in the first place, just icing on a cake they were
already eating. They wanted that cake for another reason first.

This holds true for newly popular scripting languages as well. They do
not resemble C so much, but they are popular. Clearly it is not the
syntax that draws users to a language - or more precisely to a tool. It
is something else. There must be, as mentioned in one of the earlier
posts, a clear value to that user. If the value is clear, then and only
then do other factors enter into consideration. Pimping Eiffel's syntax
will do no more to help its popularity than genetically engineering
fuscia colored Brussels Sprouts will do for that much maligned
vegetable.

I confess that I do like the idea of -projecting- the semantics in
different -consumable- forms, but that is not the thing that will
attract new users to Eiffel. It will appeal to those using Eiffel
already. The challenge is to attract them in the first place. This can
happen only when two things occur:
1. Eiffel - as a tool - offers conspicuous value to the uneducated user
2. Word of that value is spread quickly

I do not mean to imply that we need to attract only the ignorancia. By
uneducated, I mean users who have not as yet imbibed of the Eiffel Kool
Aide. A rule of marketing is that any time you have to educate your
user before they buy, they won't buy.

We all know the value of Eiffel, but it's not a single sugar-coated
pill. It's more sophisticated than that. For years, Bertrand and
Company (OK, family) tried to sell Eiffel by emphasizing the "Q" word.
Look around you - quality rarely attracts. It's a second-order value
sadly.

What sells today? Sexy, sweet, fun and easy. Quality is not sexy -
though the converse can of course be true :) Even cost effectiveness is
a second-order factor in this market. It is only after a user is
attracted to a tool that the cost calculations enter the picture, and
then it's often subjective.

C offered portability and that was a HUGE value. Forty years ago, it
was a important attractor. It powered a revolution in technology. We
have C to thank for near-standard operating systems. Today's user takes
portability for granted.

C++ offered an easy way to play with classes. Earlier adopters wanted
to learn OO because that was the sexiest thing in the Eighties (we
didn't get out much it seems). That was a quarter century ago and a lot
has changed. Many users moved to C++ when the C and C++ compilers
merged, migrating from ANSI C to C++ piece by piece. Today's users take
objects for granted (even if most see only a tip of the object iceberg).

Java had, in addition to a massive marketing push thanks to Kim Polesi
et al, the ability to embed a working chunk of code into your browser
page. The applet was a sexy attractor, and it was easy - almost no
coding at all. The applet fell out of favor, but by then the mythology
of "write once, run anywhere" was well entrenched. The C-like syntax
made it easy for those -already attracted by the core value proposition-
to make the transition to using the tool for other things, even though
those other things were not a great fit for the tool (users had invested
time and emotion into it).

Livescript/javascript was never very good as a language but has been
hugely successful as a tool. The attractor was not the syntax, but the
ability to put into your web-based application or pages some logic that
would execute on the client. It was initially appealing as a way to
speed things up, make things more dynamic, and to add a little more of
an application flavor to otherwise static content. It's a hard language
to love, but it's still the best tool for the job it does.

I hope for the sake of civilization as a whole that the attractor for
Python is not the syntax. Python had it's early adopters who probably
liked being able to create objects in a scripting language - at least
that was what intrigued me at first. The syntax is at best a
second-order factor. It's what's under the hood (bonnet for our British
friends) that offers value, in addition to being ubiquitous (read: easy
to get/use).

What I find to be common amongst these examples is that each offered a
strong attractor that was something other than syntax. It was never
about the language or tool in its own right, but about the conspicuous
and timely value proposition if provided.

Eiffel has objects. So what?. Every language these days has objects.
Eiffel has stronger semantics. So what? Rank and file users simply
don't care.
Eiffel is more self-consistent. So what? Only purists care about such
things.
Eiffel has the best support for DbC. So what? I can get DbC (sort of)
for other languages.

The fact that Eiffel is MUCH better at objects, semantics, quality, DbC,
engineering and so on, is utterly uninteresting to non-Eiffelists and
anyone else other than perhaps computer linguists. That it is better
comes into the picture only -after- a user has been attracted to it in
the first place. I'm not saying it's not hugely important, I'm saying
it's not a huge initial attractor.

The key to increasing Eiffel's popularity is to make it -conspicuously-
valuable to the user that doesn't use it yet. That means it must be
attractive to less sophisticated users. It's not the language that is
the problem! It has been suggested many times, including in these
threads, that we need to focus on frameworks and other high-value
mechanisms. I agree. We also need to make Eiffel the best tool for
doing really attractive things.

Those things must appeal to the youthful segment, not just to mossbacks
like myself. Our target market came of age long after the language
wars, long after the performance wars, long after most of the struggles
that have made us who we are.

The new user expects and demands immediate gratification. We cannot
expect them to follow some quasi-monastic discipline before realizing
value. They want it now, and our competitors are giving it to them. C
is not the future. It's a quaint artifact. Java is not the future.
Compiled languages in general are not the future, at least in the mass
market. Simply put, it's script or the crypt. Eiffel needs a scripted
implementation and a sexy/sweet/fun/easy (SSFE) horse to ride. It needs
to become the tool of choice for multiscreen (mobile, tablet, pc, tv)
apps.

Have a look at the Corona framework from Ansca. It uses Lua as its
language. Its focus is mobile game development, but it's an example of
SSFE. It could just as easily have used Eiffelscript had that existed
(note the avoidable of camelCase). An Eiffelscript interpreter could be
included free in new Linux distros and made yum-able for existing ones.

Eiffelscript should, as I said long long ago, be able to mix in compiled
Eiffel too. Bertrand, years ago, cast Eiffel as the "great component
combinator". It never quite got to that point, but he was right in
claiming that it could. With the addition of Eiffelscript (better
called something else, perhaps simply "tower"), the reality might be
more achievable. I imagine a tool/framework that lets users, by way of
the Eiffel interpreter, pull in components from multiple languages.
Eiffel gave us a glimpse of this in the compiled world with .NET -
better than any other language as it happens. That dog don't hunt, so
it's time to move on to one that does.

So, lets' focus our considerable energy on the first-order challenge.
Let's focus on red vs white before we spend all of our energy debating
micro-regional soil conditions.

Thanks

R

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





The information in this e-mail and any attachments transmitted with it are
provided in commercial confidence for the intended recipient(s). If you have
received this e-mail in error, please notify the Postmaster by e-mail at
postmaster@.... Any views or opinions expressed are solely those of the
author and do not necessarily represent those of DEK.

For local company specific legal information for your country or region and any
local contact information for DEK, please refer to:

http://www.dek.com/dek.nsf/reg!openform

This footnote confirms that this message has been checked for the presence of
computer viruses and other 'malware' to the best of our knowledge when it left
our systems. DEK is not responsible in any way for any malware that may be or
become associated with this message. Recipients are strongly urged to use
appropriate protection and requested to assure themselves that opening any
attachments is safe.


[Non-text portions of this message have been removed]

Let’s not get carried away. No one said that adding the possibility of syntax
skins, including a Javel skin, would change the world, or that this was the only
problem to be addressed. It’s simply an idea worth pursuing at relatively
little effort. It can also be the opportunity for a successful community
project.

-- BM


[Non-text portions of this message have been removed]

Sorry if this is a duplicate. I never received it after sending....

We should recognize the other strength of scripting languages – that is, no
waiting round for compiles.

Now the downside of that is that all checking must be done at runtime, but that
is not visible to programming newbies - it just seems to be the way things work.
When they hit a compiled language they have to wait and then get all these
errors (mainly cryptic because they don't understand the principles behind
them), so they give up in shock and return to scripting.

ISE did try to alleviate the compile time problem with the frozen ice technology
which provided a byte code with interpreter (very clever technology).

I had an insight a year or so ago, a sort of corollary to Bertrand's
non-programmers (UML diagrammers) like diagrams because they don't crash. Well
programmers like running programs even if imperfect because watching them crash
is exciting.

I have written on this thrill before:

Testing and Complexity

Testing is also a place where complexity is handled. Testing has come to
prominence in the programming profession with test-driven development. Testing
is all very desirable, but it also makes up for ignoring a lot of other
techniques to ensure program correctness. One of these is typing in programs
that can detect many programming errors at compile time. Without types,
programmers must run their programs to test them for problems that would have
otherwise been disallowed by a type system.

Testing is of course more exciting for programmers to do – after all the goal of
writing software is to run it and test it out. However, typing removes this fun
and makes it somewhat dry. An exciting run-time error, glorified in the term
'crash', is replaced by a dry 'syntax' (really semantic) error. Thus beginning
programmers soon turn against such a-priori testing. It actually needs a
reasonable amount of programming experience and sophistication to get over the
thrill of crashing programs. Crashing of course does provide a thrill – people
like to see slot- or drag-car racing, and it seems why young drivers drive in an
irresponsible manner for the thrill.

From

http://www.ianjoyner.name/Ian_Joyner/Complexity.html

Ian

On 20 Apr 2012, at 20:05, Alexander Kogtenkov wrote:

> Paul Cohen wrote:
>
>> For a long time my wish has been to be able to do something like:
>>
>>  $ apt-get install eiffel
>>  $ <my favorite_editor> foo.e
>>  $ eiffel foo.e
>>  $ foo
>
> Not sure about the first 2 steps, but if you have "ec" installed and in your
path,
> the last 2 lines work just fine if you replace "eiffel" with "ec" and the
class FOO
> is a self-contained (a-la Hello-World) application:
>
>    $ ec foo.e
>    $ foo
>
> Regards,
> Alexander Kogtenkov
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>



[Non-text portions of this message have been removed]

We should recognize the other strength of scripting languages – that is, no
waiting round for compiles.

Now the downside of that is that all checking must be done at runtime, but that
is not visible to programming newbies - it just seems to be the way things work.
When they hit a compiled language they have to wait and then get all these
errors (mainly cryptic because they don't understand the principles behind
them), so they give up in shock and return to scripting.

ISE did try to alleviate the compile time problem with the frozen ice technology
which provided a byte code with interpreter (very clever technology).

I had an insight a year or so ago, a sort of corollary to Bertrand's
non-programmers (UML diagrammers) like diagrams because they don't crash. Well
programmers like running programs even if imperfect because watching them crash
is exciting.

I have written on this thrill before:

Testing and Complexity

Testing is also a place where complexity is handled. Testing has come to
prominence in the programming profession with test-driven development. Testing
is all very desirable, but it also makes up for ignoring a lot of other
techniques to ensure program correctness. One of these is typing in programs
that can detect many programming errors at compile time. Without types,
programmers must run their programs to test them for problems that would have
otherwise been disallowed by a type system.

Testing is of course more exciting for programmers to do – after all the goal of
writing software is to run it and test it out. However, typing removes this fun
and makes it somewhat dry. An exciting run-time error, glorified in the term
'crash', is replaced by a dry 'syntax' (really semantic) error. Thus beginning
programmers soon turn against such a-priori testing. It actually needs a
reasonable amount of programming experience and sophistication to get over the
thrill of crashing programs. Crashing of course does provide a thrill – people
like to see slot- or drag-car racing, and it seems why young drivers drive in an
irresponsible manner for the thrill.

From

http://www.ianjoyner.name/Ian_Joyner/Complexity.html

Ian

On 20 Apr 2012, at 20:05, Alexander Kogtenkov wrote:

> Paul Cohen wrote:
>
>> For a long time my wish has been to be able to do something like:
>>
>>  $ apt-get install eiffel
>>  $ <my favorite_editor> foo.e
>>  $ eiffel foo.e
>>  $ foo
>
> Not sure about the first 2 steps, but if you have "ec" installed and in your
path,
> the last 2 lines work just fine if you replace "eiffel" with "ec" and the
class FOO
> is a self-contained (a-la Hello-World) application:
>
>    $ ec foo.e
>    $ foo
>
> Regards,
> Alexander Kogtenkov
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi,

I am agree too.

Eiffel is undeniably an excellent language, maybe the better.
Reliable, power, easy, scalable ...
When I talk about Eiffel language with others I am always enthusiastic !


But Eiffel don't know how to sell itself. I think today its diffusion is
low, very low or else in regression.
It lacks a documentation (tutorial) updated and multilingual. It is
necessary to echo the Eiffel worldwide (programmer community, social
network, ...)
For example, in France, before to read the Bertrand Meyer's book
(Construction et programmation Orienté Object) I never heard anyone talk
about Eiffel Language.

For example a new on www.developpez.com/ and www.siteduzero.com/ to signal
a new version of EiffelStudio and new features (void-safety, ...) would
improve the visibility of Eiffel in the french programming world.

It could organize programming competitions, ... as Startups and
multinationals

Improve the visibility of Eiffel and Eiffel Software.
It is also a work for the community.


The multiplatform mobile developpment is booming (Phonegap (Javascripts),
RhodesMobile (Ruby, Javascript), Titanium Appcelerator (Java, ...)). Why
not try a partnership?


Thanks

--
Victorien ELVINGER


[Non-text portions of this message have been removed]

I realize that the discussion of the popularity of Eiffel, the talk of
adapting the syntax to be more C-like, and the creation of a EiffelScript
language has crossed over several message threads. I know because I
have replayed to all of them.

I am new to the forum and I probably missed the start of the conversation
so I don't know all that has been said. But from what I have been able to
read and understand the whole point of these conversations to research
how the use of Eiffel as a development language can increase. Someone
tell me if I'm wrong.

I believe that this topic is a white elephant in the room that most people want
to ignore.
Whether you are developing for the web or for desktop systems you
can find numerous tools to create what you need. But mostly you can find a
large amount of FREE tools. Linux, which is for the most part a free product
you get a free C/C++ complier, a free JVM, a free editor in Vi or Emacs,
Apache which is a free web server. With a free download you can add a
database - MySql, and  Cassandra which is a free database scaling software.
I found a webpage that went into detail about all the tools used to create
Facebook.
I provide the link for you here.
http://www.makeuseof.com/tag/facebook-work-nuts-bolts-technology-explained/
Everything needed to create Facebook was free. The guy who built it while in
college
is now a billionaire! Most development tools outside of Microsoft are free.
I used to program for some big defense contractors and nearly all the tools we
used were free. Other than the Oracle database everything else was free.
You can even get most of these free products to run on Windows.

All the scripting languages that people keep mentioning are free. People will
even admit
that it's not the syntax or it's not the ability to do this or that, but they
will not
admit that the first thing that draws people to a language or a product is that
it's
free. Talk about great marketing. Free attracts people. If I think that a
product
will help me complete a task and it's free I'll start off trying to use that
product
even if I have to try to figure out how to use it. Ease of use may make it
faster
to learn but free get me started using it.

Do you think that the Facebook folks will let you look at their code so you can
see
how it works? I don't think so. The advertisers on Facebook will never see the
code.

I am my own best example. I create charting software for stocks, commodities,
foreign
exchange, and anything that is traded and has data. I sell the service on a
monthly
subscription basis. I provide service and my clients freely pay for it. My
proprietary code
that finds price reversals is protected from copycats. I can't afford to let the
world see my
code. I use Java for the front-end interface and C++ to connect to the data
prover I use.
It's all free stuff. I could create a better product with something like Eiffel
but I can't afford to make that
investment. My system is not broken so why fix it?  As a side note, I did not
know Java before
I created the interface. I used Netbeans and bought 3 big Java books to help me
write it.
At this time I am making a huge facelift to the system on both the front-end and
the back end.
I'm not wild about the way I'm having to go about doing it but I use the tools
that are available.

Steve

>>>>> "Emmanuel" == Emmanuel Stapf <manus@...> writes:

     Emmanuel> If this is easy to reproduce (I'm thinking more about
     Emmanuel> setup requirements), could you submit your code to
     Emmanuel> http://support.eiffel.com so that we can find out what
     Emmanuel> is going wrong?

It's very easy to reproduce, but requires a lot of code. I'll wait for
ISE Eiffel 7.1 to see if it is still there.

--
All the best,

Berend de Boer


           ------------------------------------------------------
           Awesome Drupal hosting: https://www.xplainhosting.com/

The way to really attract new users to Eiffel is to advertise it
as a "green and environmentally friendly programming language
with a low carbon foot-print".

Sorry, I needed some comic relief after a long day.

Given two text files with different creation dates and any contents at:


C:\File_Test\test_1.txt
C:\File_Test\test_2.txt


I was trying to see if file_1.txt had the same last-changed date as file_2.txt,
using the program below.  However, it appears that creating file_2 side-effects
the file_info : UNIX_FILE_INFO object of file_1, making it appear that the date
for file_1 and file_2 are always the same.  The file_info object does not appear
to be a once-function.


Is this a bug or am I just doing something wrong?


Thanks,


--Bruce



============= Simplified program ==========================

class
FILE_TEST


create
make


feature {NONE}
make
local
file_1, file_2           : PLAIN_TEXT_FILE
file_1_info, file_2_info : UNIX_FILE_INFO
file_1_date, file_2_date : INTEGER
do
create file_1.make("C:\File_Test\test_1.txt")
file_1_info := file_1.file_info
file_1_date := file_1_info.date
print(file_1_info.date.out + ", " + file_1_date.out + "%N")


create file_2.make("C:\File_Test\test_2.txt")
file_2_info := file_2.file_info
file_2_date := file_2_info.date
print(file_1_info.date.out + ", " + file_1_date.out + "%N")  -- ERROR: values no
longer match!
print(file_2_info.date.out + ", " + file_2_date.out + "%N")
end
end


=============== Output of the Program ==================
1335009268, 1335009268
1335010300, 1335009268
1335010300, 1335010300


================ Comments ================
Line 1 is correct: file_1_info.date matches the saved integer value for 'date'
Line 2 is wrong!  file_1_info.date NO LONGER MATCHES the saved integer value! 
It how has file_2 info.
Line 3 is correct: file_2_info.date matches the saved integer value for 'date',
but seems to have side-effected file_1_info





[Non-text portions of this message have been removed]

Sorry, I forgot to add, that I'm using Eiffel 7.0.


--B


-----Original Message-----
From: brucemount <brucemount@...>
To: eiffel_software <eiffel_software@yahoogroups.com>
Sent: Sat, Apr 21, 2012 8:42 am
Subject: UNIX_FILE_INFO: bug or misunderstanding?


Given two text files with different creation dates and any contents at:


C:\File_Test\test_1.txt
C:\File_Test\test_2.txt


I was trying to see if file_1.txt had the same last-changed date as file_2.txt,
using the program below.  However, it appears that creating file_2 side-effects
the file_info : UNIX_FILE_INFO object of file_1, making it appear that the date
for file_1 and file_2 are always the same.  The file_info object does not appear
to be a once-function.


Is this a bug or am I just doing something wrong?


Thanks,


--Bruce



============= Simplified program ==========================

class
FILE_TEST


create
make


feature {NONE}
make
local
file_1, file_2           : PLAIN_TEXT_FILE
file_1_info, file_2_info : UNIX_FILE_INFO
file_1_date, file_2_date : INTEGER
do
create file_1.make("C:\File_Test\test_1.txt")
file_1_info := file_1.file_info
file_1_date := file_1_info.date
print(file_1_info.date.out + ", " + file_1_date.out + "%N")


create file_2.make("C:\File_Test\test_2.txt")
file_2_info := file_2.file_info
file_2_date := file_2_info.date
print(file_1_info.date.out + ", " + file_1_date.out + "%N")  -- ERROR: values no
longer match!
print(file_2_info.date.out + ", " + file_2_date.out + "%N")
end
end


=============== Output of the Program ==================
1335009268, 1335009268
1335010300, 1335009268
1335010300, 1335010300


================ Comments ================
Line 1 is correct: file_1_info.date matches the saved integer value for 'date'
Line 2 is wrong!  file_1_info.date NO LONGER MATCHES the saved integer value! 
It how has file_2 info.
Line 3 is correct: file_2_info.date matches the saved integer value for 'date',
but seems to have side-effected file_1_info






[Non-text portions of this message have been removed]

Hi there,

After updating from the SVN repository today, I couldn't compile
EiffelStudio/EVE on a Linux machine. Compilation was successful before
that, and the last update was two weeks ago. The errors are during
C-compilation, including several identifiers not defined and, I believe
to be the main reason, failing to locate the file "gtk/gtk.h"-- a file
included by "ev_gtk.h". I searched for the file "gtk.h" in the Src
directory and also the EiffelStudio installation directory, but found
nothing.

I am not sure whether this is because of some mistakes on my side, on
the EiffelStudio/EVE side, or on the OS side (e.g. missing environment
variable or file). Has anyone some idea about this?


Thanks and regards,
Max

You need to update to the latest nightly build of EiffelStudio 7.1.

Manu

On Apr 21, 2012, at 16:29, "Y. P." <maximilian.pei@...> wrote:

> Hi there,
>
> After updating from the SVN repository today, I couldn't compile
> EiffelStudio/EVE on a Linux machine. Compilation was successful before
> that, and the last update was two weeks ago. The errors are during
> C-compilation, including several identifiers not defined and, I believe
> to be the main reason, failing to locate the file "gtk/gtk.h"-- a file
> included by "ev_gtk.h". I searched for the file "gtk.h" in the Src
> directory and also the EiffelStudio installation directory, but found
> nothing.
>
> I am not sure whether this is because of some mistakes on my side, on
> the EiffelStudio/EVE side, or on the OS side (e.g. missing environment
> variable or file). Has anyone some idea about this?
>
>
> Thanks and regards,
> Max
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I see. Thanks.

Max


On 4/22/2012 2:05 AM, Emmanuel Stapf wrote:
>
> You need to update to the latest nightly build of EiffelStudio 7.1.
>
> Manu
>
> On Apr 21, 2012, at 16:29, "Y. P." <maximilian.pei@...
> <mailto:maximilian.pei%40gmail.com>> wrote:
>
> > Hi there,
> >
> > After updating from the SVN repository today, I couldn't compile
> > EiffelStudio/EVE on a Linux machine. Compilation was successful before
> > that, and the last update was two weeks ago. The errors are during
> > C-compilation, including several identifiers not defined and, I believe
> > to be the main reason, failing to locate the file "gtk/gtk.h"-- a file
> > included by "ev_gtk.h". I searched for the file "gtk.h" in the Src
> > directory and also the EiffelStudio installation directory, but found
> > nothing.
> >
> > I am not sure whether this is because of some mistakes on my side, on
> > the EiffelStudio/EVE side, or on the OS side (e.g. missing environment
> > variable or file). Has anyone some idea about this?
> >
> >
> > Thanks and regards,
> > Max
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>



[Non-text portions of this message have been removed]

The reason of this misbehavior is that the `file_info' query returns the same
underlying object. We will fix this in a future release. In the meantime, you
should either use the FILE queries instead of going through the `file_info'
query,
or create the UNIX_FILE_INFO instances manually rather than getting it from
FILE,
i.e.

create file_info.make
file_info.update (file_name)

Hope this helps,
Manu

> -----Original Message-----
> From: eiffel_software@yahoogroups.com
> [mailto:eiffel_software@yahoogroups.com] On Behalf Of brucemount@...
> Sent: Saturday, April 21, 2012 5:43 AM
> To: eiffel_software@yahoogroups.com
> Subject: [eiffel_software] UNIX_FILE_INFO: bug or misunderstanding?
>
>
> Given two text files with different creation dates and any contents at:
>
>
> C:\File_Test\test_1.txt
> C:\File_Test\test_2.txt
>
>
> I was trying to see if file_1.txt had the same last-changed date as
> file_2.txt, using the program below.  However, it appears that creating
> file_2 side-effects the file_info : UNIX_FILE_INFO object of file_1,
> making it appear that the date for file_1 and file_2 are always the same.
> The file_info object does not appear to be a once-function.
>
>
> Is this a bug or am I just doing something wrong?
>
>
> Thanks,
>
>
> --Bruce
>
>
>
> ============= Simplified program ==========================
>
> class
> FILE_TEST
>
>
> create
> make
>
>
> feature {NONE}
> make
> local
> file_1, file_2           : PLAIN_TEXT_FILE
> file_1_info, file_2_info : UNIX_FILE_INFO
> file_1_date, file_2_date : INTEGER
> do
> create file_1.make("C:\File_Test\test_1.txt")
> file_1_info := file_1.file_info
> file_1_date := file_1_info.date
> print(file_1_info.date.out + ", " + file_1_date.out + "%N")
>
>
> create file_2.make("C:\File_Test\test_2.txt")
> file_2_info := file_2.file_info
> file_2_date := file_2_info.date
> print(file_1_info.date.out + ", " + file_1_date.out + "%N")  -- ERROR:
> values no longer match!
> print(file_2_info.date.out + ", " + file_2_date.out + "%N")
> end
> end
>
>
> =============== Output of the Program ==================
> 1335009268, 1335009268
> 1335010300, 1335009268
> 1335010300, 1335010300
>
>
> ================ Comments ================
> Line 1 is correct: file_1_info.date matches the saved integer value for
> 'date'
> Line 2 is wrong!  file_1_info.date NO LONGER MATCHES the saved integer
> value!  It how has file_2 info.
> Line 3 is correct: file_2_info.date matches the saved integer value for
> 'date', but seems to have side-effected file_1_info
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Thanks Manu!


--Bruce


[Non-text portions of this message have been removed]

Please refer to:
http://docs.eiffel.com/book/solutions/eiffellex-tutorial
<http://docs.eiffel.com/book/solutions/eiffellex-tutorial>
I have created a class based on SCANNING. The `make' looks like:
make Precursor build (store_file_name, grammar_file_name) analyze
(input_file_name) file.closeend
There are features for `store_file_name', `grammar_file_name',
`input_file_name' and `file: PLAIN_TEXT_FILE', where file is an
attribute with a create.make_open_write (output_file_name).
All of this works very well. I have a redefine of `do_a_token (a_token:
TOKEN)' which then examines each token found with a_token.string_value,
type, keyword_code, line_number and column_number.
What I am finding are a couple of matters I do not understand just yet.

     1. Regardless of my grammar file definition, SCANNING seems to know
about a respect Eiffel language keywords (even though they are not
present in my grammar file). Is my understanding correct? Does SCANNING
know about Eiffel language keywords by default?
     2. When I provide grammar for an HTML-5 element like '<title>', the
`analyze (input_file_name)' process does not seem to see it. The grammar
file specifies it as: "Title (<title>)" (without the quotes). I test
this in a regex tester and the regex engine is able to see the string in
the line (e.g. "try to find <title> in this line" returns expression
"<title>" found at 12 with a length of 7). When I run the code, the
`do_a_token' routine does not seem to get "<title>" ever, but only
"title". What am I doing wrong?
Thank you in advance!Larry



[Non-text portions of this message have been removed]

Sorry about the disaster code layout. It looked pretty in the Yahoo Rich-Text
editor and in the Preview and then THIS (below) is the mangled garbage it
produced nonetheless! Just a little upsetting! Oh well! :-)

At the same time, can someone relate to me how to do proper code examples in
this editor?

--- In eiffel_software@yahoogroups.com, "larry_rix" <ljr1981@...> wrote:
>
> Please refer to:
> http://docs.eiffel.com/book/solutions/eiffellex-tutorial
> <http://docs.eiffel.com/book/solutions/eiffellex-tutorial>
> I have created a class based on SCANNING. The `make' looks like:
> make Precursor build (store_file_name, grammar_file_name) analyze
> (input_file_name) file.closeend
> There are features for `store_file_name', `grammar_file_name',
> `input_file_name' and `file: PLAIN_TEXT_FILE', where file is an
> attribute with a create.make_open_write (output_file_name).
> All of this works very well. I have a redefine of `do_a_token (a_token:
> TOKEN)' which then examines each token found with a_token.string_value,
> type, keyword_code, line_number and column_number.
> What I am finding are a couple of matters I do not understand just yet.
>
>     1. Regardless of my grammar file definition, SCANNING seems to know
> about a respect Eiffel language keywords (even though they are not
> present in my grammar file). Is my understanding correct? Does SCANNING
> know about Eiffel language keywords by default?
>     2. When I provide grammar for an HTML-5 element like '<title>', the
> `analyze (input_file_name)' process does not seem to see it. The grammar
> file specifies it as: "Title (<title>)" (without the quotes). I test
> this in a regex tester and the regex engine is able to see the string in
> the line (e.g. "try to find <title> in this line" returns expression
> "<title>" found at 12 with a length of 7). When I run the code, the
> `do_a_token' routine does not seem to get "<title>" ever, but only
> "title". What am I doing wrong?
> Thank you in advance!Larry
>
>
>
> [Non-text portions of this message have been removed]
>

Thank you for the answer.



--- In eiffel_software@yahoogroups.com, "Emmanuel Stapf" <manus@...> wrote:
>
> > - is there a deep_import mechanism, as described in OOSC/2E, page 976-
> > 977?
>
> The mechanism is not yet implemented. For reason similar to `deep_twin', it is
> something that one should try to avoid. In 7.1, we will start adding some
`import'
> routines to import objects like strings.
>
> > - can I qualify the processor when creating a separate object?
> > It is described in "a format reference to SCOOP" and in "a contract-based
> > concurrent object-oriented programming model" as separate <p> but I get
> > syntax errors when I try that.
>
> This syntax extension is not yet implemented. We focused on implementing the
SCOOP
> mechanism first. The extension to specify a processor is mostly a runtime
feature
> which relies on a syntax extension that needs to be finalized and a little bit
of
> type checking.
>
> Hope this helps,
> Manu
>

Thanks for the answer. In the context I'm currently working in, writing to file
and reading is a little extreme.

--- In eiffel_software@yahoogroups.com, Thomas Beale <Thomas.Beale@...> wrote:
>
> On 17/04/2012 17:38, Emmanuel Stapf wrote:
> >
> > > - is there a deep_import mechanism, as described in OOSC/2E, page 976-
> > > 977?
> >
> > The mechanism is not yet implemented. For reason similar to
> > `deep_twin', it is
> > something that one should try to avoid. In 7.1, we will start adding
> > some `import'
> > routines to import objects like strings.
> >
>
> Actually, I do this all the time, with the dADL syntax - any time I want
> an object, I just write a text file, and suck it in.
>
> Example text files:
> * error db for an app:
>
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/apps/adl_workbench/ap\
p/error_db/
>      appears as a HASH_TABLE [HASH_TABLE [STRING, STRING], STRING]
>
> * object model schemas - e.g.
>
http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/openehr_demographic_102.b\
mm
>      these appear as P_BMM_* objects defined by the classes here:
>
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/libraries/common_libs\
/src/basic_meta_model/
>
> The object <=> text converter code is mainly implemented in a very ugly
> (but powerful) class -
>
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/libraries/common_libs\
/src/structures/data_tree/dt_object_converter.e
>
> And the parser is here -
>
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/libraries/common_libs\
/src/structures/syntax/dadl/parser/
>
> The above doesn't fully implement all the Eiffel basic types yet (e.g.
> INTEGER_64 etc) but it is close. I was working on making this completely
> generalised with Marco Picconi, but ran out of time for the moment.
>
> The syntax spec is chapter 4 of this doc -
>
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5\
.pdf
>
> All of this is free, and I have built a standalone system based on these
> classes, which works fine. Let me know if you are interested.
>
> The more I use this mechanism, the more I wish all .ecf files, config
> files, and direct object serialisations were in it - all ours are. Any
> takers?
>
> - thomas
>
>
> [Non-text portions of this message have been removed]
>

Hi All,

I want to adapt my .ecf files to be able to use the same .ecf files for
compiling projects with 'ec' and with the gobo compiler.

To that end I need to be able to select the kernel/base libraries that
will be used for a given compilation.

On looking at the 'condition' and 'custom' options for the 'library' and
'precompile' entries, I thought I had found the answer but have so far
been unable to emit the magic incantation to get it to work ...

Is there some lucid guidance as to the detail of a .ecf file, other than
the out-of-date page on the dev.eiffel.com wiki and the source code ?

Thanks,

Howard



--
Howard Thomson <howard.thomson@...>

>>>>> "Howard" == Howard Thomson <howard.thomson@...> writes:

     Howard> Hi All, I want to adapt my .ecf files to be able to use
     Howard> the same .ecf files for compiling projects with 'ec' and
     Howard> with the gobo compiler.

For this use case people tend to use geant + gexace. You write your
.ecf as a system.xace, and you use gexace to translate it. This
translation can be done handily with geant, so this is what I do:

   geant compile_debug_ise

or

   geant compile_ge


--
All the best,

Berend de Boer


           ------------------------------------------------------
           Awesome Drupal hosting: https://www.xplainhosting.com/

Hi All,

Thank you Berend for answering the previous question.

I had forgotten out the compile_ise option ...

However, while I have now understood how to include the right kernel
libraries for compiling with ec/gec, the generated .ecf file currently
defaults to not specifying the syntax requirements, which is interpreted
by 'ec' as 'Old syntax', as displayed in the Project Config when I run
estudio.

An additional syntax="standard" needs to be generated into [one of] the
options sections of the .ecf file, and it is not obvious as to how to
achieve that.

Any ideas, or suggestions please ?

Regards,

Howard



Generated .ecf using Gobo standard compile_ise:
[I don't think this has altered in the current git repo]

	 <target name="guide">
		 <root class="GUIDE" feature="make"/>
		 <option trace="false" profile="false" debug="false" warning="true">


After modifying with Estudio and selecting Standard Syntax:

	 <target name="guide">
		 <root class="GUIDE" feature="make"/>
		 <option trace="false" profile="false" debug="false" warning="true"
is_attached_by_default="false" syntax="standard">

The missing syntax setting is causing me grief !


--
Howard Thomson <howard.thomson@...>

Hi All,

Problem solved ...

The latest git version of Gobo does pass on the syntax="standard"
setting that I needed, so I will have to update my 'guide' branch of the
gobo package to match ...

Regards,

Howard



--
Howard Thomson <howard.thomson@...>

Hi,
I have create an Eiffel library and that library is used in multiple
projects that I develop. I want to modify the name of a class in that
library. Normally, in a project, I use the "Rename" tools in the
"Refactor" menu. I want to know if there is a way to do this with my
library (modify the library and the projects).

Thanks!

Louis M


--
View this message in context:
http://eiffel.641255.n2.nabble.com/Refactor-on-library-tp7532462.html
Sent from the Eiffel Software Users mailing list archive at Nabble.com.

[Non-text portions of this message have been removed]

Hi All,

I am using gec and ec to compile a program that uses the Vision2 library
from the Eiffel Software distribution.

Compiling with gec reports an error:

[VMRC-2] class EV_WIDGET_LIST (29,2): replicated features
EV_DYNAMIC_LIST.put, EV_CONTAINER.cl_put have not been selected.

However, compiling the Vision2 example 'widgets' program, which also
uses  EV_WIDGET_LIST, with ec does not report such an error.

Does the fact that EV_WIDGET_LIST is a deferred class have anything to
do with the difference in error treatment, or is this a probable bug in
the current gec implementation ?

Regards,

Howard



--
Howard Thomson <howard.thomson@...>

>>>>> "Howard" == Howard Thomson <howard.thomson@...> writes:

     Howard> Does the fact that EV_WIDGET_LIST is a deferred class have
     Howard> anything to do with the difference in error treatment, or
     Howard> is this a probable bug in the current gec implementation ?

Probably a question better asked on the Gobo users mailing list?

--
All the best,

Berend de Boer


           ------------------------------------------------------
           Awesome Drupal hosting: https://www.xplainhosting.com/

If I understand your problem correctly, you can prefix all class names in a
library on a project by project basis in the Project Settings tool
(Project|Project Settings). Navigate to the library and in the "Advanced" list
provide a prefix string for the library name. For example, if you are using your
own "time" library, you could add the prefix "MY_" so that all classes in your
library are prefixed. So, "TIME" would become "MY_TIME"

--
Peter Horan             Faculty of Science and Technology
peter@...<mailto:peter@...>     Deakin University
+61-3-5221 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-4-0831 2116 (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

From: eiffel_software@yahoogroups.com [mailto:eiffel_software@yahoogroups.com]
On Behalf Of Louis M
Sent: Monday, 7 May 2012 00:26
To: eiffel_software@yahoogroups.com
Subject: [eiffel_software] Refactor on library



Hi,
I have create an Eiffel library and that library is used in multiple
projects that I develop. I want to modify the name of a class in that
library. Normally, in a project, I use the "Rename" tools in the
"Refactor" menu. I want to know if there is a way to do this with my
library (modify the library and the projects).

Thanks!

Louis M

--
View this message in context:
http://eiffel.641255.n2.nabble.com/Refactor-on-library-tp7532462.html
Sent from the Eiffel Software Users mailing list archive at Nabble.com.

[Non-text portions of this message have been removed]



[Non-text portions of this message have been removed]

Hello,

I've just fetched the latest and greatest sources from the repository, EVE
branch. However, upon compiling the code from Mac OS X, I get an error in
COM_OBJECT, where as the feature 'last_object' of type COM_LIGHT_OBJECT fails as
the type does not exist.

Currently, I've isolated the problem by simply commenting-out the code causing
the problem, however I am wondering if anyone have similar problems and/or have
a solution to this particular problem?

Thanks,
Søren (soen)