Fragile Fences

V

Virgil Green

Roedy said:
Try this experiment. Write some code in Eclipse. Shut down eclipse.
modify a source file with a text editor. Start up eclipse. Do not
"refresh". and notice that your changes are missing. It is showing you
something other than the flat files. It must have some other copy.
That might be a cvs like repository or an internal representation, but
it is not the flat files.

Nope. I changed my code with TextPad. Saved it. Opened up Eclipse. I
happened to have left that particular .java file open in Eclipse when I last
exited. It opened right up, showed me the changes and promptly informed me
that I had a compile error before I had touched the mouse or keyboard.

I've never had an externally initiated change to a source file fail to show
up in Eclipse. To expand on your experiment, I then opened the same file in
TextPad while I had it open in Eclipse. I removed the change via TextPad and
saved it. When I returned to Eclipse I was presented with a dialog
indicating that the file had been changed externally by another program and
it offered to reload it. TextPad will reciprocate with the same kind of
external change detection. I rely on that often in TextPad when watching
live log files.

I'm running a faily untweaked copy of Eclipse 3.0.2 build 200503110845 on a
Windows/2000 machine.
 
R

Roedy Green

Nope. I changed my code with TextPad. Saved it. Opened up Eclipse. I
happened to have left that particular .java file open in Eclipse when I last
exited. It opened right up, showed me the changes and promptly informed me
that I had a compile error before I had touched the mouse or keyboard.

do you have autorefresh from flat files turned on?

--
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
 
R

Roedy Green

I removed the change via TextPad and
saved it. When I returned to Eclipse I was presented with a dialog
indicating that the file had been changed externally by another program and
it offered to reload it.

That proves my point that Eclipse must have its own internal copy. If
it did not, how could it detect the change, and how could it offer to
carry on WITHOUT reloading.

--
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
 
R

Raymond DeCampo

Roedy said:
That proves my point that Eclipse must have its own internal copy. If
it did not, how could it detect the change, and how could it offer to
carry on WITHOUT reloading.

The same way all editors do this. They watch the file system, hopefully
with native code that does not require polling, to see if the time stamp
of the file changes from when they opened it.

Also, most editors keep a copy of the file while you are editing
partially in memory and/or on disk. Otherwise they would have to save
on each keystroke and implementing features such as undo would be
impossible.

Ray
 
L

Larry Barowski

Raymond DeCampo said:
The same way all editors do this. They watch the file system, hopefully
with native code that does not require polling, to see if the time stamp
of the file changes from when they opened it.

On Windows, most editors just check file mod times whenever
an application window gets focus. On an FFM system that would
be annoying though.
 
V

Virgil Green

Roedy said:
do you have autorefresh from flat files turned on?

I don't know. What is that and where do you find it?

Checking around I see a setting at "Window|Preferences|Workbench" that is
labeled "Refresh workspace automatically" and note that it is turned off.

Also, in "Windows|Preferences|Workbench|Startup and Shutdown" there is a
setting labeled "Refresh workspace on startup" and that is also turned off.

Anyway, if you want me to check a particular setting amongst Eclipse's
plethora of settings, you're going to have be more specific/exact.
 
V

Virgil Green

Roedy said:
That proves my point that Eclipse must have its own internal copy. If
it did not, how could it detect the change, and how could it offer to
carry on WITHOUT reloading.

Hardly. Using that logic I'd have to conclude that TextPad has the same
attributes you are assigning to Eclipse. Rather both have the file loaded
into memory because they have the file open in edit mode and they could
simply overwrite the detected changes on the next save. It's a bit of a
stretch to claim that this feature lends credence to the notion that there
is some internal, permanant data store in use.
 
R

Raymond DeCampo

Larry said:
On Windows, most editors just check file mod times whenever
an application window gets focus. On an FFM system that would
be annoying though.

Those editors will miss out on changes that happen via background
processes, by network file access, etc. that occur while the window has
focus.

I'm not sure what you mean by a FFM system.

Ray
 
L

Larry Barowski

Raymond DeCampo said:
Those editors will miss out on changes that happen via background
processes, by network file access, etc. that occur while the window has
focus.
True.

I'm not sure what you mean by a FFM system.

Focus-follows-mouse - systems where the keyboard focus
is on the window under the mouse, and where that is not
necessarily the "top" window.
 
R

Roedy Green

Hardly. Using that logic I'd have to conclude that TextPad has the same
attributes you are assigning to Eclipse. Rather both have the file loaded
into memory because they have the file open in edit mode and they could
simply overwrite the detected changes on the next save. It's a bit of a
stretch to claim that this feature lends credence to the notion that there
is some internal, permanant data store in use.

Text pad forgets its internal state when you shut it down. Eclipse
does not.

--
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
 
D

Dale King

Roedy said:
Text pad forgets its internal state when you shut it down. Eclipse
does not.

I don't think anyone disputes that Eclipse does maintain internal state
about your source files for doing things like showing you the outline of
the file, etc.

What is not true however is your notion that this is the master copy and
that the source file is generated from that.
 
R

Roedy Green

What is not true however is your notion that this is the master copy and
that the source file is generated from that.

Here is my evidence that Eclipse maintains the master copy internally
distinct from the source files in the project directory.

1. Eclipse has the ability to replace from local history and previous
local history. Clearly that local history is not present in the source
files themselves.

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. If you make another
different trivial mod and do a save, then shut down Eclipse and look
at the source files, you will see your change done behind Eclipse's
back has disappeared, but your second one done in Eclipse is still
there. That means Eclipse must have maintained the master copy
somewhere other than the project source files.

Just what does this master copy look like?

It could be a parse tree, given Eclipse's ancestry.

It could be a miniature CVS repository.

It could be some ordinary or compressed copies filed under
unrecognizable names.

To answer that question, we need to ask someone familiar with Eclipse
internals, or do some sniffing about through all of Eclipse's internal
files to see what is there.

--
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
 
V

Virgil Green

Roedy said:
Here is my evidence that Eclipse maintains the master copy internally
distinct from the source files in the project directory.

1. Eclipse has the ability to replace from local history and previous
local history. Clearly that local history is not present in the source
files themselves.

But that does not prove that there is an authoritative copy kept outside the
traditional source files.
2. If you turn off auto-refresh, shut down Eclipse, modify one of the

What auto-refresh setting are you talking about? Please be specific because
I don't think anyone else in this thread has been able to find it.
source files in the project directory behind Eclipse's back, and start
up Eclipse, you will not see your changes.

You have yet to provide the instructions for reproducing this. Be specific
because no one else in this thread seems to be experiencing this.
If you make another
different trivial mod and do a save, then shut down Eclipse and look
at the source files, you will see your change done behind Eclipse's
back has disappeared, but your second one done in Eclipse is still
there. That means Eclipse must have maintained the master copy
somewhere other than the project source files.

We can't say that is the case until your experiement is documented well
enought to be reproduced... and is then reproduced reliably.

<snip speculation about an unproved theory>
 
C

Chris Smith

Roedy Green said:
Here is my evidence that Eclipse maintains the master copy internally
distinct from the source files in the project directory.

1. Eclipse has the ability to replace from local history and previous
local history. Clearly that local history is not present in the source
files themselves.

Take a look at
${workspace_loc}/.metadata/.plugins/org.eclipse.core.resources/.history

Despite the unusual file names, that doesn't look much like anything but
flat text storage to me. When you request a diff against local history,
it is performed on the fly between the two flat-file representations.

In any case, all the comments I'm about to make about point #2 apply
here as well.
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.

I haven't verified this, but unlike some other people in this thread I
do understand what you're saying. However, this only proves that
another copy -- possibly in another format -- may exist of *some* files,
*somewhere* in the workspace. I wonder if you'd have similar
experiences with a file that you haven't touched recently from within
Eclipse.

What I'm saying is that Eclipse definitely keeps state about the
resources it manages, but that state is used as a *cache*, not as an
authoritative source. It is calculated lazily, as needed, on the fly...
and when you modify something behind Eclipse's back, Eclipse just needs
to be prodded a bit to completely discard this state and recalculate it
from scratch. Good luck doing anything like that if you deleted your
actual source files!

Because of this, it's misleading to describe Eclipse as keeping source
code in a database, and its flat files as an export. Instead, Eclipse
keeps source code in text files, and it shadows them with a transient
semantic representation that only contains what information it's
convenient to keep there. BY doing this, it's able to do a lot of the
things you described in your SCID essay, but without the disadvantages
of losing the familiar source file representation with which development
has evolved for most of a century.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
V

Virgil Green

Roedy said:
On Sat, 16 Jul 2005 16:42:05 GMT, Dale King

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. If you make another

Reviewing the Eclipse Plug-in Platform Guide, I find the following in the
documenation of the org.eclipse.core.resources.refreshProviders:

**** quote ****
Description:
The workspace supports a mode where changes that occur in the file system
are automatically detected and reconciled with the workspace in memory. By
default, this is accomplished by creating a monitor that polls the file
system and periodically searching for changes. The monitor factories
extension point allows clients to create more efficient monitors, typically
by hooking into some native file system facility for change callbacks.
*** end quote ****

I suspect that this is the auto-refresh you are talking about... but the
description above clearly states that it is about the version in memory.

Also, if you are going to provide instructions on how to reproduce the
scenario you present as proof of an authoritative internal version of the
source code, please include the exact build of Eclipse you are using. I, for
instance, am using Version 3.0.2 with a Build ID of 200503110845

<snip other stuff not relevant to this reply>
 
C

Chris Uppal

Chris said:
Because of this, it's misleading to describe Eclipse as keeping source
code in a database, and its flat files as an export. Instead, Eclipse
keeps source code in text files, and it shadows them with a transient
semantic representation that only contains what information it's
convenient to keep there.

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.
BY doing this, it's able to do a lot of the
things you described in your SCID essay, but without the disadvantages
of losing the familiar source file representation with which development
has evolved for most of a century.

I have never been convinced by Eclipse's compromise between a full database and
real files. Both have advantages, but Eclipse's workspace concept has always
seemed a hacky, confusing, and inconvenient, middle ground which manages to
aggregate the minuses rather better than the plusses. Of course, as with so
much else, Eclipse has improved in this area over the years, but I still don't
find myself comfortable with (this aspect of) the way it works

-- chris
 
R

Roedy Green

But that does not prove that there is an authoritative copy kept outside the
traditional source files.

Yes it does.

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

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

--
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
 
R

Roedy Green

What I'm saying is that Eclipse definitely keeps state about the
resources it manages, but that state is used as a *cache*, not as an
authoritative source

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.


--
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
 
R

Roedy Green

Also, if you are going to provide instructions on how to reproduce the
scenario you present as proof of an authoritative internal version of the
source code, please include the exact build of Eclipse you are using. I, for
instance, am using Version 3.0.2 with a Build ID of 200503110845

<snip other stuff not relevant to this reply>

I have a later version
Version: 3.1.0

Seems unlikely something so fundamental would change.

--
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
 
R

Roedy Green

Yes it does.

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

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

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.

--
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top