Fragile Fences

[Chris Smith]

that cache must be pretty big if Eclipse can take you back to at least
two other versions. Unless it sometimes loses that ability, you can't
call its store a cache.

It looks as though the parse tree is a cache though, which it could
regenerate from hidden flat files.

Right, there are definitely two things at work here.

First, there's the local history, which Eclipse will keep for well-
defined periods of time. Local history is *not* stored in any kind of a
semantically meaningful form like a parse tree. It's in flat files, and
my previous response gave you the path where Eclipse keeps the files.

Second, there's the parse tree, which is definitely very transient, and
Eclipse is notorious for deciding to throw it away and rebuild things at
the most inopportune times (less so with recent builds, though).

In either case, it's not accurate to say that Eclipse uses a database as
the authoritative source on code. However, it's certainly true that
Eclipse does not start from scratch in parsing the code for every single
operation.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

FWIW, Eclipse's predecessor, VAJ, did keep its source in an internal
database as the primary representation. I suspect the DB in question was
essentially the Envy DB from VA Smalltalk, but I'm not certain of that.

Yes, it was Envy. It did not support files at all. If you had resources
for your project they had to be kept in the file system.

 

[Dale King]

Right, there are definitely two things at work here.

First, there's the local history, which Eclipse will keep for well-
defined periods of time. Local history is *not* stored in any kind of a
semantically meaningful form like a parse tree. It's in flat files, and
my previous response gave you the path where Eclipse keeps the files.

You can control the periods of time that is maintained under Windows >
Preferenced > General > Workspace > Local history.

The proof that the two are very separate is that local history works no
non-Java files and works even if you don't have the Java development tools.

Local history is just sort of an automatic version control system that
saves all your changes for you.

 

[Virgil Green]

Yes it does.

No it doesn't. It only means that it's available, not authoritative.

Clearly Eclipse maintains additional information, and clearly it is
not in the source files.

Never disputed.

Please just read again what I said and-or do the experiment and think
about what it means.

I'm still waiting for your exact steps to recreate the experiement. I've
done the experiement and informed you that my results did not match yours.
Where are the precise steps for replicating your experiment?

 

[Virgil Green]

Perhaps this experiment will be more convincing.

Ask Eclipse to delete some files. Shut down Eclipse, and notice they
truly have disappeared from the source files. Then wake up Eclipse
again and click the node where they used to be and select "restore
from local history". You can choose which files to bring back to life.
Bring some back to life to prove to yourself this is no empty promise.

Eclipse must be maintaining at least one entire duplicate copy of its
own.

And yet that doesn't make it authoritative. My experiments in my environment
have shown otherwise. I'm still waiting for instructions on how to make your
experiment work as you've described.

 

[Virgil Green]

I have a later version
Version: 3.1.0

Seems unlikely something so fundamental would change.

Then you're not very familiar with the Eclipse heritage....

Now... what settings are you talking about when discussing "Refresh"?

 

[Virgil Green]

I have a later version
Version: 3.1.0

Seems unlikely something so fundamental would change.

I have a machine with 3.1 installed at home. I'll try the same experiment I
reported on that machine and let you know of the results.

 

[Tim Tyler]

2. If you turn off auto-refresh, shut down Eclipse, modify one of the
source files in the project directory behind Eclipse's back, and start
up Eclipse, you will not see your changes.

That is not true here.

If I modify a source file while Eclipse is shut down, the changes appear
in Eclipse next time it is loaded. It's true even if the source files are
loaded in the editor.

I have "Refresh automatically" turned off.

Eclipse 3.1.

Eclipse has always worked that way.

I think you have got hold of the wrong end of the stick on this issue.

/Maybe/ what got you confused is that the changes don't show up
as warnings/errors/whatever in the compile tree until you refresh.

That's not because Eclipse has cached the files - it's because it's
not updated its project parse tree from them yet.

 

[Roedy Green]

And yet that doesn't make it authoritative. My experiments in my environment
have shown otherwise. I'm still waiting for instructions on how to make your
experiment work as you've described.

I have given you several experiments to try. You surely are capable as
anyone of thinking up experiments on your own.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

No it doesn't. It only means that it's available, not authoritative.

Then all you have to do is change the flat files and see what Eclipse
uses, the flat files or its internal state.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

Now... what settings are you talking about when discussing "Refresh"?

right click any file or directory in Eclipse. Click refresh.

There is a feature called Auto-refresh providers which I have not
used. I don't think you invoke it with a menu command. You have to
write a script.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

/Maybe/ what got you confused is that the changes don't show up
as warnings/errors/whatever in the compile tree until you refresh.

That's not because Eclipse has cached the files - it's because it's
not updated its project parse tree from them yet.

This may be a matter of semantics.

What if you never hit refresh and then hit save? This is treating
Eclipse's copy as the master.

If you hit refresh first, you are treating the flat files as the
master copy.

You could think of refresh as like "import from the standard place".

However, in either case, the copy that counts for Eclipse is its
internal copy, not the flat files.

I think I have shown that:

1. Eclipse internally maintains a CVS like master copy.

2. If you don't do a refresh, Eclipse has an internal copy it uses
oblivious to any changes you made externally to the flat files.

Some people have suggested from indirect evidence the Eclipse caches a
parse tree for only some files. The start up time for editing a file
seems to vary wildly. That is further evidence.

open questions:

1. does Eclipse ever refresh without being asked? If it does, that is
a case for calling the flat files the authorative ones.

2. While you are editing, in what form is the file? Is this like
traditional file editing with some extra tables or like a SCID that is
exported when you hit save? This is a question for curiosity.
Everything works the same externally either way.



--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

No it doesn't. It only means that it's available, not authoritative.

Just what do you mean by "authorative"? Consider the traditional
non-eclipse way of coding. What is authorative?

1. the latest CVS checking, the latest CVS release checkin, the flat
files on your machine. The text in RAM you are editing?

You can choose to take any version the one to work on.

the flat files are authorative is the sense if Javac came knocking,
those are the ones it would take.

Authorative might mean -- the latest version you can expect to have in
the event of a power failure.

In which case that would be the flat files.

I contend that with Eclipse, by that last definition the flat files
are not authorative. The internal files in Eclipse are what it will
display on screen after a power failure. It only uses the flat files
if you ask it to with a refresh -- which is like a restore from first
level backup.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Raymond DeCampo]

This may be a matter of semantics.

What if you never hit refresh and then hit save? This is treating
Eclipse's copy as the master.

If you hit refresh first, you are treating the flat files as the
master copy.

You could think of refresh as like "import from the standard place".

However, in either case, the copy that counts for Eclipse is its
internal copy, not the flat files.

I think I have shown that:

1. Eclipse internally maintains a CVS like master copy.

2. If you don't do a refresh, Eclipse has an internal copy it uses
oblivious to any changes you made externally to the flat files.

Some people have suggested from indirect evidence the Eclipse caches a
parse tree for only some files. The start up time for editing a file
seems to vary wildly. That is further evidence.

open questions:

1. does Eclipse ever refresh without being asked? If it does, that is
a case for calling the flat files the authorative ones.

2. While you are editing, in what form is the file? Is this like
traditional file editing with some extra tables or like a SCID that is
exported when you hit save? This is a question for curiosity.
Everything works the same externally either way.

Last time I checked, Eclipse was open source. Why don't you take a look
under the hood instead of this constant speculation and attempts to
reverse engineer it?

Ray

 

[Dale King]

That is not true here.

If I modify a source file while Eclipse is shut down, the changes appear
in Eclipse next time it is loaded. It's true even if the source files are
loaded in the editor.

I have "Refresh automatically" turned off.

Eclipse 3.1.

Eclipse has always worked that way.

I think you have got hold of the wrong end of the stick on this issue.

/Maybe/ what got you confused is that the changes don't show up
as warnings/errors/whatever in the compile tree until you refresh.

That's not because Eclipse has cached the files - it's because it's
not updated its project parse tree from them yet.

Another thing that works as Roedy says is the directory tree. If you add
files and directories or remove files or directories outside of Eclipse
then Eclipse won't see it until you refresh.

Of course what's in the filesystem is still the authoritative version.

 

[Virgil Green]

right click any file or directory in Eclipse. Click refresh.

My error... I have repeatedly asked you to identify specifically the
"auto-refresh" feature to which you continually allude. I meant to ask for
the setting for that feature. Since I requested the "setting" above, I
assumed it would be clear that I was repeating that question.

<snip>

 

[Virgil Green]

This may be a matter of semantics.

What if you never hit refresh and then hit save? This is treating
Eclipse's copy as the master.

You still haven't provided the steps and settings to reproduce your
experiment showing that changes made outside Eclipse are not picked inside
Eclipse without doinga refresh. Others have tried your experiment and have
not experienced this behavior you describe. Precisely describe the
parameters of your experiment.

If you hit refresh first, you are treating the flat files as the
master copy.

Only if your unproved hypothesis holds true... and at least two people have
reported to you that it does not.

You could think of refresh as like "import from the standard place".

However, in either case, the copy that counts for Eclipse is its
internal copy, not the flat files.

I think I have shown that:
Nope...

1. Eclipse internally maintains a CVS like master copy.
Nope...

2. If you don't do a refresh, Eclipse has an internal copy it uses
oblivious to any changes you made externally to the flat files.
Nope...

Some people have suggested from indirect evidence the Eclipse caches a
parse tree for only some files. The start up time for editing a file
seems to vary wildly. That is further evidence.

open questions:

1. does Eclipse ever refresh without being asked? If it does, that is
a case for calling the flat files the authorative ones.

At least two people in this thread have reported that it does.

2. While you are editing, in what form is the file? Is this like
traditional file editing with some extra tables or like a SCID that is
exported when you hit save? This is a question for curiosity.
Everything works the same externally either way.

If it's a question for curiosity... go look it up, rather than endlessly
speculating and failing to provide a reproducible, fully described
experiment. Read the source.

 

[Virgil Green]

I have given you several experiments to try. You surely are capable as
anyone of thinking up experiments on your own.

I've done every one you've described (however loosely), reported to you that
the results you described did not occur, and asked you to provide the exact
parameters to cause your results to be realized. Please do it. I'm sure your
capable of doing so... but for some reason must not want to. I've presented
the exact steps I used in my experiment and reported the results. Others
have done the same reported the same results I have. You really do seem to
be the odd man out here.

 

[Virgil Green]

Then all you have to do is change the flat files and see what Eclipse
uses, the flat files or its internal state.

Done it. Reported it. Confirmed that the behavior you described did *not*
occur. Did you read it?

 

[Virgil Green]

Just what do you mean by "authorative"? Consider the traditional
non-eclipse way of coding. What is authorative?

Since the discussion thus far has been whether the flat file being edited or
some version squirrelled away in the bowels of Eclipse is the "master" copy,
then the "authoritative" copy I've referred to is the "master copy. Several
of us have pointed out and demonstrated that the flat files are the "master"
copy. Other than you, no one I've seen in this thread has yet confirmed or
experienced the behavior your describe. Rather they have confirmed and
experienced exactly the opposite.

1. the latest CVS checking, the latest CVS release checkin, the flat
files on your machine. The text in RAM you are editing?

Let's not expand this to dev versus prod. Editing is done on dev versions
and that's where the discussion should be kept. The text in RAM? That's
getting a bit ridiculous... but, if you must, the authoritative version is
the version about to be typed and housed only in the mind of the developer.

You can choose to take any version the one to work on.

the flat files are authorative is the sense if Javac came knocking,
those are the ones it would take.

Authorative might mean -- the latest version you can expect to have in
the event of a power failure.

In which case that would be the flat files.

I contend that with Eclipse, by that last definition the flat files
are not authorative. The internal files in Eclipse are what it will
display on screen after a power failure. It only uses the flat files
if you ask it to with a refresh -- which is like a restore from first
level backup.

No. Several of us have reported the opposite and you continue to posit that
this behavior exists in Eclipse but none of us have been able to reproduce
the behavior you describe.

And, for your information, I just recreated the experiment you continue to
suggest and it did exactly what I expected it to do.

I create a new Project called Playland.
I added a new class called MyClass. It contained no code other than the
public class declaration.
I saved this new class.
I closed the editor.
I closed Eclipse.
I started Textpad and opened c:\eclipse\workspace\Playland\MyClass.java.
I added one line of code - "System.out.println("This is a test");"
I saved the file in Textpad and closed Textpad.
I started Eclipse.
I set focus on the Package Explorer.
I expanded the project Playland.
I expanded the src directory.
I expanded the package I put my class in.
I double-clicked on MyClass.java.
I observed that the code entered via TextPad while Eclipse was closed was
present in the editor in Eclipse.
I left the editor open for the class in Eclipse.
I closed Eclipse.
I started Notepad and opened the same file.
I placed the code I previously added into a proper main method (having
failed to do so the first time).
I save the file in Textpad.
I closed Textpad.
I stared Eclipse.
The editor I left open when Eclipse was close was opened automatically and
it contained the new code changes I just made in Eclipse.

So, there you have a complete set of instructions. The only auto-refresh
options I can find in Eclipse (using version 3.1.0 Build ID 200411050810)
are turned off. Code changes made outside of Eclipse were never ignored by
Eclipse despite your claims that Eclipse will do so.

Now, please tell me how the experiment described above differs from the one
you've asked us to repeat.