Non-constant constant strings

[Rick C. Hodgin]

So it is a running system on your developer machine, just not a running
system on John Smith's computer. The simplest way to modify your
statement to mean what you intended would be to change "somebody's" to
"somebody else's", or perhaps "an end user's".

I was using "somebody's" as a way to to differentiate from "your own."
It stands to reason that your own computer is also somebody's computer,
but I think the distinction is clear enough in context. For example,
other people understood it.

Now that it's clear what you meant, let's get back to the context in
which you said it. BartC raised a bunch of issues. You dismissed those
issues with the explanation:

But the issues he raised are just as relevant to a program running on
the developer's system as on "John Smith's" system. Therefore, with
corrected wording, your dismissal changes from nonsense into a comment
that is meaningful but irrelevant. That's a bit of improvement, but not
much.

Was there a question in here somewhere? I thought that I answered BartC's
questions with my replies. If there's something I missed, I'm happy to
explain further so you can understand. If you don't care to press the
issue, I'm content to leave it here as well. I think most people who
care to do so fully understand at this point.

Best regards,
Rick C. Hodgin

 

[Kenny McCormack]

It's perfectly obvious to anyone that isn't a complete cretin. Don't
let this guy drag you down. I'm at a loss to understand why he is being
so pedantic and destructive.[/QUOTE]

Do remember that this is the same guy who took the time and the trouble to
post a response insisting that it is important to distinguish between an
error and an error message (as if anyone here doesn't already know and can
keep it straight all by themselves).

--
"The smart way to keep people passive and obedient is to strictly limit the
spectrum of acceptable opinion, but allow very lively debate within that
spectrum...."

- Noam Chomsky, The Common Good -

 

[Kenny McCormack]

"The smart way to keep people passive and obedient is to strictly limit the
spectrum of acceptable opinion, but allow very lively debate within that
spectrum...."

- Noam Chomsky, The Common Good -

The above (randomly selected) sig quote is very good, very apropos of this
newsgroup. Sometimes it just works out that way...

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

 

[Keith Thompson]

On 02/03/2014 08:19 AM, Rick C. Hodgin wrote: [...]

So, when I had said previously, "a running system on somebody's computer,"
I was referring to the process (your application) running on John Smith's
computer.

So it is a running system on your developer machine, just not a running
system on John Smith's computer. The simplest way to modify your
statement to mean what you intended would be to change "somebody's" to
"somebody else's", or perhaps "an end user's".

I was using "somebody's" as a way to to differentiate from "your own."
It stands to reason that your own computer is also somebody's computer,
but I think the distinction is clear enough in context. For example,
other people understood it.

[...]

I understood what you wrote. I also understood what you meant.
And I understood that those were two quite different things.
That was a discrepancy worth clearing up, and you could have done
so much more quickly than you did, with much less wasted bandwidth.

I'm not criticizing you (much) for the initial use of "somebody's"
when "somebody else's" would have expressed your intent much more
clearly; I've certainly been guilty of unclear wording myself.
But I suggest that simple errors call for simple corrections.

 

[James Kuyper]

I was using "somebody's" as a way to to differentiate from "your own."

It doesn't have that meaning without adding the word "else". Also, as I
pointed out above, with that meaning, it's not relevant to BartC's
question. The issues he raised are just as much of a problem if the
debugger is running on his own computer, rather than somebody else's.

Was there a question in here somewhere? ...

Yes, BartC's message included the question:

And if do you make some changes to a running
program (which will have a certain state including the contents of hundreds
of megabytes of memory, full of pointers to every other part, a few dozen
open files on disk, a part-finished video display etc etc) who decides
whether a continue operation is going to be viable, you or the debug
program?

... I thought that I answered BartC's
questions with my replies. ...

Not as far as I could tell. Your response seemed to consist entirely of
dismissal of the question for reasons that seemed irrelevant, as
explained above, followed by additional comments about what
"edit-and-continue" is, and how it works - comments that did not answer
his question. It was his question, and it's up to him whether he's
satisfied with your response. I was not particularly interested in the
question, only in resolving the nonsense in your response. When BartC
responded to your message, he did so only to comment on other issues,
and not to address your non-answer to his question, which suggests that
he might be satisfied with it.

 

[Rick C. Hodgin]

I understood what you wrote. I also understood what you meant.
And I understood that those were two quite different things.
Excellent.

That was a discrepancy worth clearing up, and you could have done
so much more quickly than you did, with much less wasted bandwidth.

FWIW, I did not understand there was a discrepancy in understanding until
James pointed it out directly. I was confused by the misunderstanding,
and assumed it came from something else.

I'm not criticizing you (much) for the initial use of "somebody's"
when "somebody else's" would have expressed your intent much more
clearly; I've certainly been guilty of unclear wording myself.
But I suggest that simple errors call for simple corrections.

Wow.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

It doesn't have that meaning without adding the word "else".

Noted. I apologize for not being more clear.

Also, as
I pointed out above, with that meaning, it's not relevant to BartC's
question. The issues he raised are just as much of a problem if the
debugger is running on his own computer, rather than somebody else's.

I'll summarize the answer I've given in this thread many times:

The developer has to be cognizant of what's going on.
The developer has to be aware of what the change in source code does
to the data environment.

The developer is the one who holds ultimate responsibility because there
are times edit-and-continue will allow changes which compile without error,
yet categorically introduce issues which now exist at runtime because stale
data now exists, or a logic condition expected on previous passes does not
now match the current logic condition as per the recent change to source
code. It requires a reasoning human mind to know for sure what changes
have been made.

I don't know how to be more clear on this.

I will try to answer by quoting Microsoft's Ballmer:

"Developers! Developers! Developers! Developers! Developers!
Developers! Developers! Developers! Developers! Developers!"

You can see the hard working man here:

Yes, BartC's message included the question:

The developer.

Not as far as I could tell. Your response seemed to consist entirely of
dismissal of the question for reasons that seemed irrelevant, as
explained above, followed by additional comments about what
"edit-and-continue" is, and how it works - comments that did not answer
his question.

My response was an attempt to convey how it works so people could translate
what takes place into their own understanding and answer the myriad of
questions without having to ask each one specifically.

It was his question, and it's up to him whether he's
satisfied with your response. I was not particularly interested in the
question, only in resolving the nonsense in your response.

Which "nonsense" was that, James?

When BartC
responded to your message, he did so only to comment on other issues,
and not to address your non-answer to his question, which suggests that
he might be satisfied with it.

Yes. I believe he understood what I said, what I was saying, and had a
grasp which allowed him to move on. I had presumed that if he needed more
he would ask more questions.

Best regards,
Rick C. Hodgin

 

[James Kuyper]

Noted. I apologize for not being more clear. ....
The developer has to be cognizant of what's going on.
The developer has to be aware of what the change in source code does
to the data environment.

The developer is the one who holds ultimate responsibility because there
are times edit-and-continue will allow changes which compile without error,
yet categorically introduce issues which now exist at runtime because stale
data now exists, or a logic condition expected on previous passes does not
now match the current logic condition as per the recent change to source
code. It requires a reasoning human mind to know for sure what changes
have been made.

I don't know how to be more clear on this.

Well, it seems to me that more than that is required.
"edit-and-continue" is a phrase that could be used to describe a wide
range of possible features. I think that the fact that C is a compiled
language, its static type system, and it's heavy use of pointers, among
other things, would make edit-and-continue well-nigh impossible to
implement fully. Therefore, a key issue any user needs to know is "how
far does this particular debugger fall short of fully implementing
edit-and-continue?". Which changes can safely be made will depend upon
the answer to that question, and no amount of reasoning based solely
upon a knowledge of C can answer that question.

....

Which "nonsense" was that, James?

The nonsense that resulted from leaving out the word "else". A single
word can often radically change the meaning of a sentence, and that was
one example.

 

[Kenny McCormack]

Do remember that this is the same guy who took the time and the trouble to
post a response insisting that it is important to distinguish between an
error and an error message (as if anyone here doesn't already know and can
keep it straight all by themselves).

I haven't forgotten. I commented on it. I was astonished. A new low
point in c.l.c pedantry. Is this guy for real?[/QUOTE]

Mr. Spoons...

 

[Kenny McCormack]

FWIW, I did not understand there was a discrepancy in understanding until
James pointed it out directly. I was confused by the misunderstanding,
and assumed it came from something else.


Wow.

Yeah. Wow.

That's pretty much my reaction to every one of Kiki's posts.

The mental picture that his posts brings up is just, well, so far beyond
creepy, as to blow your mind.

 

[Rick C. Hodgin]

Well, it seems to me that more than that is required.
"edit-and-continue" is a phrase that could be used to describe a wide
range of possible features. I think that the fact that C is a compiled
language, its static type system, and it's heavy use of pointers, among
other things, would make edit-and-continue well-nigh impossible to
implement fully. Therefore, a key issue any user needs to know is "how
far does this particular debugger fall short of fully implementing
edit-and-continue?". Which changes can safely be made will depend upon
the answer to that question, and no amount of reasoning based solely
upon a knowledge of C can answer that question.

For my money, James, the two are inexorably linked. Edit-and-continue
is designed, by design, with the purposeful design in mind, from inception
on through, to be systematically and categorically linked to the debugger
environment of a running instance of the application. Were the program not
running it would not be called edit-and-continue. It would be called
compiling and linking. As it is, it's part of the overall mechanism which
allows the developer, developer, developer, to create and modify code.

There are separate issues at work here as well. These are the mechanics
of data already computed using a prior version of the software (data which
may reside in memory and may now be stale (as compared to the current state
of the running software)), compared to the requirements of the new version
of software now running. They may not link up.

Even with this potential discrepancy, the two are not in disparity, nor
is there a lack of well-defined behavior at work. If, for example,
nothing is changed in the new version of the program as it relates to
prior computed data, then there is no issue. If, however, something new
is added which systematically breaks something in use, then it requires
the data be manually ported over (as through a function which migrates it
from its old style to the new current style), or for the program to be
restarted.

The nonsense that resulted from leaving out the word "else". A single
word can often radically change the meaning of a sentence, and that was
one example.

I disagree that my leaving out the word "else" was nonsense.

Best regards,
Rick C. Hodgin

 

[Ian Collins]

Even with this potential discrepancy, the two are not in disparity, nor
is there a lack of well-defined behavior at work. If, for example,
nothing is changed in the new version of the program as it relates to
prior computed data, then there is no issue. If, however, something new
is added which systematically breaks something in use, then it requires
the data be manually ported over (as through a function which migrates it
from its old style to the new current style), or for the program to be
restarted.

That's a very big if which limits the utility of edit and continue. As
I've said before, the debugger I use (dbx) supports what they call fix
and continue. I've used it occasionally, but only for small things like
changing a logic condition. If a change alters the stack layout, the
fix will fail, which is a good thing.

 

[Rick C. Hodgin]

That's a very big if which limits the utility of edit and continue. As
I've said before, the debugger I use (dbx) supports what they call fix
and continue. I've used it occasionally, but only for small things like
changing a logic condition. If a change alters the stack layout, the
fix will fail, which is a good thing.

So long as the code is syntactically correct, and there was enough room to
allow any changes made to local variables, global variables, etc., and the
code compiled without error in that way, then Microsoft's debugger will
not fail simply because the data on the stack might now be invalid. It
will allow you to continue debugging the current function, for example,
to find additional errors, and then when you hit a condition where it
returns, then it will fail.

This allows you to continue working on a block of code, being able to
temporarily manually populate some variable if need be (such as if new
local variables were added which do not currently have an assigned value),
and you can continue through the rest of the function, even calling sub-
functions, and so on.

The utility is there. It's just not going to work in all cases as per
Microsoft's current design. It will let you continue with program logic,
and you can do some manual fixups if they're simple enough (and even some
very complex ones if you want to take the time), but it will not re-adjust
existing data, and it will fail upon return from a function.

Best regards,
Rick C. Hodgin

 

[James Kuyper]

On 02/01/2014 09:08 PM, Rick C. Hodgin wrote:
....

You do not do this on a running system on somebody's computer.



I disagree that my leaving out the word "else" was nonsense.

Leaving out the word "else" meant that the developer's machine was not
excluded. Without that exclusion, what you said means that there's no
computer anywhere, that belongs to anybody, running the debugger that
implements this feature. I exaggerated - that's not complete nonsense.
In principle, it could refer to a debugger running on a machine that
didn't belong to anybody - but that makes even less sense than what you
actually meant to say.

 

[Rick C. Hodgin]

Leaving out the word "else" meant that the developer's machine was not
excluded. Without that exclusion, what you said means that there's no
computer anywhere, that belongs to anybody, running the debugger that
implements this feature. I exaggerated - that's not complete nonsense.

It's completely obvious that the developer would be using his machine,
and that my comment meant somebody's computer ... you know ... out
there ... in the world.

In principle, it could refer to a debugger running on a machine that
didn't belong to anybody - but that makes even less sense than what you
actually meant to say.

Exactly! It makes even less sense ... so that's not what I would've meant.

As my mother would say to me, "C'mon, man ... figure it out."

Best regards,
Rick C. Hodgin

 

[glen herrmannsfeldt]

On 02/03/2014 12:40 PM, Rick C. Hodgin wrote:
(snip)

I once used a BASIC interpreter that allowed edit and continue.
(But for some changes it wouldn't allow you to continue.)

It seems to me it makes more sense for an intepreter, where
variables can exist separate from compilation.

I once edited a csh script while it was running, and noticed
(while not planning for) the change to take effect immediately.
Seems that sometimes csh will reload from disk on loop iterations,
though I don't know that you can predict that.

Well, it seems to me that more than that is required.
"edit-and-continue" is a phrase that could be used to describe a wide
range of possible features. I think that the fact that C is a compiled
language, its static type system, and it's heavy use of pointers, among
other things, would make edit-and-continue well-nigh impossible to
implement fully.

Well, one could implement C as an interpreter. Many interpreted
languages are difficult to compile, though.

I notice that Rick seems to expect variables to exist in memory
in the order they are declared. I don't believe that C requires
that, and don't know how many compilers do that. Also, you probably
want a system that keeps code and data in separate address spaces.
Locations in code could move around, such that function returns
could easily fail.

Therefore, a key issue any user needs to know is "how
far does this particular debugger fall short of fully implementing
edit-and-continue?". Which changes can safely be made will depend upon
the answer to that question, and no amount of reasoning based solely
upon a knowledge of C can answer that question.

Seems to me more important when debugging programs that might have
to run for at least minutes, if not hours, before a bug appears.
If only seconds, much easier to restart. Now, it is nice to keep
breakpoints and other debugger settings. I wouldn't complain if
a debugger did that, but often having it read a script file is
about as easy.

In the days of slow compilation, I used to try not to recompile
everything when one change was made. That change might be in a
struct visible in many files, but that I would know only changed
anything in a few. When debugging, I might just recompile those
files. Not quite edit-and-continue, but has similar problems
(data might move). Still might be true for some very large
programs.

-- glen

 

[Rick C. Hodgin]

As my mother would say to me, "C'mon, man ... figure it out."

Actually, to be completely true to the expression, the members of my
family would say:

"Then put some food in the boat!"

It's a reference to a scene in the movie Hot Shots! with the exasperated
look on the Admiral's face when people around him aren't figuring out
the blatantly obvious.

Best regards,
Rick C. Hodgin

 

[glen herrmannsfeldt]

(snip)

So long as the code is syntactically correct, and there was enough room to
allow any changes made to local variables, global variables, etc., and the
code compiled without error in that way, then Microsoft's debugger will
not fail simply because the data on the stack might now be invalid. It
will allow you to continue debugging the current function, for example,
to find additional errors, and then when you hit a condition where it
returns, then it will fail.

I was remembering in earlier posts, about compilers that used to
try harder to complete compilation of programs with bugs in them.

Leave out a semicolon, and the compiler could figure out what you
most likely meant. When turnaround times were hours or days, that
helped much in getting programs running faster. Now, few will do
even that much.

This allows you to continue working on a block of code, being able to
temporarily manually populate some variable if need be (such as if new
local variables were added which do not currently have an assigned value),
and you can continue through the rest of the function, even calling sub-
functions, and so on.

But adding new variables can move around existing variables.
As they won't be in the place that pointers are pointing, things
can get bad pretty fast.

Consider other than the first call to a recursive routine.
It might know where variables are in the current instance, but
that will be wrong for others.

-- glen

 

[Kenny McCormack]

It's completely obvious that the developer would be using his machine,
and that my comment meant somebody's computer ... you know ... out
there ... in the world.

You need to understand that they are not trying to understand you. That's
not their goal. That is, they aren't treating you like a peer having a
discussion; rather, they are treating you like a student that they would
desperately like to flunk for any possible reason. Essentially, as your
grader, they require absolute precision - no possibility of misunderstanding -
as a condition of your receiving a passing grade on your exam.

That - and a host of other things - like properly prototyping main(), not
casting the return value of malloc, etc, etc.

Literally, they sit and read your posts - looking for any possible way to
misinterpret them. If they find it, they pounce.

Here, they made a big deal out of deliberately misinterpreting your
somewhat slangy use of the word "somebody".

Exactly! It makes even less sense ... so that's not what I would've meant.

As my mother would say to me, "C'mon, man ... figure it out."

Your mother would *love* this newsgroup.

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)

 

[Rick C. Hodgin]

I notice that Rick seems to expect variables to exist in memory
in the order they are declared.
Nope.

I don't believe that C requires
that, and don't know how many compilers do that. Also, you probably
want a system that keeps code and data in separate address spaces.
Locations in code could move around, such that function returns
could easily fail.

The purpose of edit-and-continue is to work with what is already there.
Microsoft uses what they call an "incremental linker" which is able to
link to the previously constructed ABI. It will not reorder things
unless they no longer fit where they used to. It will adjust function
references in classes because the edit-and-continue ABI uses indirection
for its function call destination. It calls a static location that
never changes, with only that one portion being updated to point to the
new location of the function (if it changes more than can be compiled
into the reserved space set aside for it by the edit-and-continue ABI).

It is a protocol which allows things to be modified properly in a running
environment.

Seems to me more important when debugging programs that might have
to run for at least minutes, if not hours, before a bug appears.
If only seconds, much easier to restart. Now, it is nice to keep
breakpoints and other debugger settings. I wouldn't complain if
a debugger did that, but often having it read a script file is
about as easy.

Edit-and-continue allows you to make simple program logic fixes on any
system that's been running for any length of time, local or remote. It
allows you also to do your development from inside of the debugger, so
you don't have to stop, edit, recompile, restart, get back to where you
were, and then debug. It makes it a continuous operation: you are
simply "debugging" (with the word "debugging" in this new context of
having the edit-and-continue abilities, meaning not just finding bugs,
but also correcting them as you find them, as well as writing new code,
modifying existing code, and deleting existing code if you so desire).

In the days of slow compilation, I used to try not to recompile
everything when one change was made. That change might be in a
struct visible in many files, but that I would know only changed
anything in a few. When debugging, I might just recompile those
files. Not quite edit-and-continue, but has similar problems
(data might move). Still might be true for some very large
programs.

I use it on my current project. It is by no means huge, but if you design
your system to use multiple DLLs, then you're only debugging one DLL at
a time typically ... and you only need that one to support the edit-and-
continue ABI protocol. The rest can be created outside of that format,
using the standard release mode with full optimization.

Best regards,
Rick C. Hodgin