eiffelroom - Comments

Oh yes, the BeBox

schoelle — Sat, 10 May 2008 07:10:30 -0700

My BeBox 2x133 is taking on dust. Perhaps I should reactivate it to see if I can get Eiffel to work on it ;-)

Nice job Manu, if I find some time I will have a look at your build - but it looks like the latest family extension is not keeping you sufficiently busy :D

ISE only?

colin-adams — Thu, 01 May 2008 03:00:36 -0700

Does this tool only work with ec, or will it work with gec too? If not, can it be made to do so? Colin Adams

Prefixes for assemblies

ruihua — Mon, 07 Apr 2008 01:32:07 -0700

Thank you for your hint. I did not know about assembly-wide prefixes. I think it's a good alternative to resolve name clashes.

Looks Great

peter_gummer — Fri, 04 Apr 2008 14:58:58 -0700

One question, Ruihua. At step 7, instead of renaming individual classes, why didn't you just set assembly-wide prefixes DB4O_ and REFLECTOR_?

The various style have an

manus_eiffel — Thu, 20 Mar 2008 20:51:00 -0700

The various styles have an impact on how blurry it is but it still remains blurry to my eyes. This is similar to the effect setting that you can find on XP when for `Standard' vs `ClearType'.

With respect to Vision2, we simply follow the OS decision so the user gets what he wants.

Mac font smoothing style

peter_gummer — Thu, 20 Mar 2008 18:02:46 -0700

I used to have mild myopia, until I had laser surgery on my eyes five years ago. I don't think I had encountered font smoothing prior to then, but I do like the smoothing now: I don't perceive it as blurriness.

Mac OS X has a System Preferences option, under Appearances, called "Font smoothing style". Have you tried "Standard - best for CRT"? On my LCD screen, it appears to have the effect of turning font smoothing off, as far as I can tell: when I lost my myopia I also lost my ability to see fine details at close range. What I can see clearly is that there is big difference when I zoom (holding down the Control key while moving the mouse ball): "Standard - best for CRT" shows various shades of grey surrounding the text, whereas all of the other font smoothing styles show shades of blues and reds and oranges around the text. I don't know how much of this is an effect of the zooming, but the fact that there's a clear difference when zooming makes me suspect your eyes may like the "Standard - best for CRT" style.

Note that the change takes effect when you open an application.

So what happens in our Vision2 applications? Is font smoothing always switched off?

Abstract Side Effect

maverick — Thu, 06 Mar 2008 07:28:33 -0800

It seems a little vague to speak of abstract side effect without specifying a model. In this case, I think there is a model and a justification for each positions. In OOSC, Meyer introduce the random number generator as a traversable object. In this case, the corresponding model is composed of a sequence of numbers (about which the invariant may state that the numbers have certain probabilistic distribution) and an integer indicating what is the next number to be returned to the user. In this case, generating a random number is a side effect and, according to CQS principle, should be implemented as a command.

But another possible model may be only a set of possible numbers or a range of numbers. In this case, the specification of a routine that generate a random numbers may be non deterministic without ever changing the abstract state of an object.

An operation which returns a non-deterministic result is a common thing in B but one could argue that B does not have CQS and does not have a need for it since no operation invocation can be performed in expressions. Back to Eiffel, it certainly is arguable whether non deterministic specification is the right thing for a query but it certainly is legal even according to CQS.

Cheers!

Simon

While we are at mentions,

manus_eiffel — Wed, 05 Mar 2008 14:59:11 -0800

While we are at mentions, there is a mention of the EiffelStudio 6.1 release in the development section of Dr. Dobb's Journal .

The contract viewer's right-click issue

peter_gummer — Thu, 28 Feb 2008 04:12:39 -0800

Paul, you mention three possible fixes for the right-click issue seen in the sneak preview of the contract viewer.

The last would be sad, so let's not think about that.
The second would be disappointing: it's so neat that it pops up simply by hovering the mouse there.
The first is intriguing. You say that hovering the mouse over a feature would display a small beam. What would the user have to do, then, to open the contract viewer? Click on the beam? Move the mouse down a bit to hover over the beam? This sounds a bit disappointing too.

A fourth option would be to leave it as it is, but make sure that right-clicking works. Isn't this possible? If I try to right-click on a feature but the contract viewer has popped up unexpectedly, is there any reason why the right-click can't be forwarded to the feature stone underneath? (Not sure if I've got my pebble-drop metaphors mixed up there, but you know what I mean.)

Me, I'd want to activate it via a keyboard shortcut rather than a mouse-hover, of course ;-)

A few Notes

paulbates — Wed, 27 Feb 2008 16:47:14 -0800

We are aware of the right click issue and it will be addressed.

I put a preview of the contract viewer in the editor to ensure any annoyances are worked out before the release. I mentioned this in one of the 6.2 release notes, release 6.2.7.2075.

There are a few things that might happen with this:

The drop down is shrunk to a small beam under the feature name text, so it does not pop up accidentally or get in the way.
The pop up time out will be longer so it does not pop up too soon, with a key modifier to show it immediately.
It will be removed.

We need to get this right because in the future the mechanism will be used in various forms throughout EiffelStudio. As it stands, what you see probably wont be what is released. There is quite a bit of logic already there to determine when to show the token options. Any feedback is welcome, we want to get this right without being annoying.

In reference to Greg's remarks, it's not a tool tip. In the future you'll be editing contracts directly on the "assistance window". As I've said these types of windows will be placed through EiffelStudio in future releases, not just in the editor.

I like it if it works

peter_gummer — Wed, 27 Feb 2008 14:30:57 -0800

I have no problem with this innovation. Where I get annoyed as a user is when an innovation gets in the way of standard user interface conventions. (Pick and drop is the classic example of that. Until recently, it impeded the use of context menus, and even today there is no drag and drop.) In 6.2.7.2437, we have this nice preview of the contracts tooltip, and I like it, but a couple of times already it has popped up when I was attempting to right-click a feature.

The trouble with this sort of thing is that it's easy to prototype and get people saying "Wow!", but it's very difficult to get it right. So I'd be glad to see this in 6.2, as long as it's very thoroughly tested! I would expect to see an option in Preferences for turning it off.

I'm not sure if there is any

manus_eiffel — Mon, 25 Feb 2008 20:59:45 -0800

I'm not sure if there is any standard for tooltips, but if you look at Visual Studio they have something very similar. They do not have a button, but they have expandable tree views in the tool tip. Not exactly the same, but it looks like tooltips are not just messages anymore, you can interact with them.

Nice, but..

gcompestine — Mon, 25 Feb 2008 12:40:53 -0800

Shouldn't the "Edit Contracts..." button be in a popup menu instead of a tooltip?

This seems like a very non-standard add-on to tooltip functionality. I do think the tooltip is a good idea, and I also believe strongly that Eiffel Vision should be migrating closer to supporting standard behavior rather than adding more departures from it.

If it is documented as a standard for Windows or some other common user interface, could you please refer me to the document?

Thanks,

Greg

It definitely makes sense to

manus_eiffel — Tue, 19 Feb 2008 10:22:43 -0800

It definitely makes sense to use Precursor and we will go with it for now since it seems that people prefer it even though it is not used for implementation but for specification.

Precursor vs. Original

ericb — Tue, 19 Feb 2008 01:20:25 -0800

The keyword Precursor refers to the implementation, but the notion of precursor feature is implementation free, as defined in ECMA 367-2, section 8.10.27: "A precursor of an inherited feature is a version of the feature in the parent from which it is inherited." On the other hand, Original may be confused with the definition of Origin of a feature, section 8.5.1, which is the class where the feature was first introduced. Considering these two definitions, I clearly prefer Precursor because what we mean is the comment in the precursor feature (i.e. the version of the feature in the parent), not the comment that appeared when the feature was first introduced. In the example below:

class A

feature

   f

         -- Comment 1

     do

         ...

     end

end

class B

inherit

   A

      redefine

          f

      end

feature

   f

         -- Comment 2

     do

         ...

     end

end

class C

inherit

   B

      redefine

          f

      end

feature

   f

         -- <Precursor>

     do

         ...

     end

end

what we mean is -- Comment 2 and not -- Comment 1.