Editing code in the debugger 8.6

I have used the latest release until recently. Can anyone tell me why I can't amend code in the debugger. If I type new code in there, it is immediately discarded wheen I recommence stepping through the code.

Sorry if this is a stupid question but my little grey cells are getting bit stale :-)

David

funny I just had a discussion with a colleague a few days ago. We both had the feeling that sometimes, the debugger would act as if it saved a method change, but that change never made it to the place we thought we had changed. There even were no method editions in the library.

We both had our strange theories about what that might be caused by. Maybe we were changing code so deep down in some nested blocks, or that this was just some strange side effect of Seaside debugging which sometimes renders the ServerAdaptor unresponsive or whatever.

We both had not paid much attention the first few times, because when you are in the middle of fixing bugs, deep down in the debugger, you probably forget to press Ctrl-S before resuming. But once one of us started talking about it, we found out there was something to it.

Now we are three ;-)

So I can tell you I also see the effect that changes to code in the debugger get lost. But I never found a pattern that would tell me when it happens. So there was no point in filing a Case with Instantiations, because if you can't reproduce a problem, they have a hard time finding it.

I don't think it has anything do to with your way of working. It really happens from time to time, under not yet explainable circumstances. 

Maybe your post helps others be alarmed about this, so that they can look at a few things once they see that effect ( I usually didn't do anything, just make my changes again, thinking it was me):

* Does the change you made in the debugger show up in the Library as a new method edition?

* Did the change take effect on Resume-ing?

* What was loaded in the image?

So hopefully we can find the bug and have somebody hunt it ;-)

Joachim

Am Sonntag, 26. Oktober 2014 10:51:06 UTC+1 schrieb Totally Objects:

Hi everyone.

I have used the latest release until recently. Can anyone tell me why I can't amend code in the debugger. If I type new code in there, it is immediately discarded wheen I recommence stepping through the code.

Sorry if this is a stupid question but my little grey cells are getting bit stale :-)

David

there is a new fragment on the issue that is not really related to the Debugger, but might be the cause of all evil...

I just had this exact problem: I changed some code in the debugger, but the change never got anywhere, resuming code execution executed the old code, and no browser showed the changed method. There even was no newer edition of the method in the Library.

And here is what I found: the debugger didn't save the change at all, because it didn't compile. Some expression in the changed method was underlined in red.

The debugger, however, didn't indicate that it didn't save the code. It simply ignored it. Because the method doesn't compile.

It also turned out the same is true in Class Browsers (sometimes): A method that doesn't compile doesn't get saved. Unfortunately, the Browser won't tell you. It acts as if all is good. If you don't close the Browser or navigate to another method, you won't ever find out your change was never ever saved. But if you click on another method in the Browser, it will ask you if you want to save the changes. If you click on yes, it still won't but also won't let you go to this other method, because there are unsaved changes in your code pane.

This is a very bad bug and needs attention from Instantiations!

Joachim

Am Dienstag, 28. Oktober 2014 13:17:15 UTC+1 schrieb Joachim Tuchel:

Hi David,

funny I just had a discussion with a colleague a few days ago. We both had the feeling that sometimes, the debugger would act as if it saved a method change, but that change never made it to the place we thought we had changed. There even were no method editions in the library.

We both had our strange theories about what that might be caused by. Maybe we were changing code so deep down in some nested blocks, or that this was just some strange side effect of Seaside debugging which sometimes renders the ServerAdaptor unresponsive or whatever.

We both had not paid much attention the first few times, because when you are in the middle of fixing bugs, deep down in the debugger, you probably forget to press Ctrl-S before resuming. But once one of us started talking about it, we found out there was something to it.

Now we are three ;-)

So I can tell you I also see the effect that changes to code in the debugger get lost. But I never found a pattern that would tell me when it happens. So there was no point in filing a Case with Instantiations, because if you can't reproduce a problem, they have a hard time finding it.

I don't think it has anything do to with your way of working. It really happens from time to time, under not yet explainable circumstances. 

Maybe your post helps others be alarmed about this, so that they can look at a few things once they see that effect ( I usually didn't do anything, just make my changes again, thinking it was me):

* Does the change you made in the debugger show up in the Library as a new method edition?

* Did the change take effect on Resume-ing?

* What was loaded in the image?

So hopefully we can find the bug and have somebody hunt it ;-)

Joachim

Am Sonntag, 26. Oktober 2014 10:51:06 UTC+1 schrieb Totally Objects:

Hi everyone.

I have used the latest release until recently. Can anyone tell me why I can't amend code in the debugger. If I type new code in there, it is immediately discarded wheen I recommence stepping through the code.

Sorry if this is a stupid question but my little grey cells are getting bit stale :-)

David

Start with a clean image.

Open a Class Browser on whatever class you want

implement a method like this:

doSomething

so let's start again:

Start with a clean image.

Open a Class Browser on whatever class you want

implement a method like this:

doSomething

Try to save the method. The Browser won't tell you it didn't save, it will just underline the non existing class name in red and ignore you.

So far I can tell that unimplemented method sends (purple underlines) do not behave this way - only red underlined unknown receivers.

I am quite sure this is not only true for class name typos, because I don't reference Classes too often in my code, but that is a scenario I know for sure shows the described behavior. I guess this behavior shows up for every situation where Code Assist will underline in red.

I'm not really sure what exact behavior I'd like to see. But I know it is sometimes strange that you think you've fixed code in the Debugger but the fix never gets saved.

Joachim

Old Policy: When you try to save a method with a compiler error, the compiler error description was injected into the source text around the location of the error.

New Policy: When you try to save a method with a Fatal Error (i.e. Compiler Error), then the first occurrence will be scrolled into view and the Red Squiggle will flash a few times to indicate that the fatal error instance is keeping the source from saving.

Red Squiggle =      Fatal Error  (something that should keep the source from saving like a compiler error)

Purple Squiggle = Error             (misspelled/missing system selector.  Does not keep the source from saving....could be a proxy method or some other situation)

Yellow Squiggle = Warning       (typically a result of some kind of code analysis....more of this in 8.6.1)
Gray Squiggle =    Info                (a suggestion based on some kind of code analysis...more of this in 8.6.1)

I'm trying to draw a conclusion from all the posts....is it that folks

1. Did not know the information I just provided?
2. Knew the information I just provided, but think the indications are too subtle?
3. Are talking about something else that is broken and I have missed the issue?

On Tuesday, November 11, 2014 9:01:52 AM UTC-5, Joachim Tuchel wrote:

Sorry, Google or Safari reacted a little strange to pressing ^

so let's start again:

Start with a clean image.

Open a Class Browser on whatever class you want

implement a method like this:

doSomething

        ^SomeNonExistingClass doSomething 

Try to save the method. The Browser won't tell you it didn't save, it will just underline the non existing class name in red and ignore you.

So far I can tell that unimplemented method sends (purple underlines) do not behave this way - only red underlined unknown receivers.

I am quite sure this is not only true for class name typos, because I don't reference Classes too often in my code, but that is a scenario I know for sure shows the described behavior. I guess this behavior shows up for every situation where Code Assist will underline in red.

I'm not really sure what exact behavior I'd like to see. But I know it is sometimes strange that you think you've fixed code in the Debugger but the fix never gets saved.

Joachim

I guess in my case it is a mix of 1 and 2, unlikely 3.

The problem I am describing is that the existing behavior leaves me (and obviously others as well) with the fact that we seem to loose code changes in the debugger.

It sure is debatable if the ability to save code that doesn't compile is of any use.

So far, all we knew was that there are situations in which we pressed Resume in the debugger and our code changes were lost. Maybe that is not a big deal, and maybe it can be fixed easily by deactivating "Resume" as long as there are changes and the method has Fatal Errors - I don't really know yet.

So with this new knowledge (or new perspective) , I will watch myself a bit more cautiously when I'm debugging. For now I tend to think the debugger should have kept me from pressing Resume as long as I have unsaved (non-compiling) changes, or it should have told me my changes cannot be compiled more obviously - I haven't decided yet.

Joachim

 

Am Dienstag, 11. November 2014 16:08:06 UTC+1 schrieb Seth Berman:

All,

Old Policy: When you try to save a method with a compiler error, the compiler error description was injected into the source text around the location of the error.

New Policy: When you try to save a method with a Fatal Error (i.e. Compiler Error), then the first occurrence will be scrolled into view and the Red Squiggle will flash a few times to indicate that the fatal error instance is keeping the source from saving.

Red Squiggle =      Fatal Error  (something that should keep the source from saving like a compiler error)

Purple Squiggle = Error             (misspelled/missing system selector.  Does not keep the source from saving....could be a proxy method or some other situation)

Yellow Squiggle = Warning       (typically a result of some kind of code analysis....more of this in 8.6.1)
Gray Squiggle =    Info                (a suggestion based on some kind of code analysis...more of this in 8.6.1)

I'm trying to draw a conclusion from all the posts....is it that folks

1. Did not know the information I just provided?
2. Knew the information I just provided, but think the indications are too subtle?
3. Are talking about something else that is broken and I have missed the issue?

-- Seth

On Tuesday, November 11, 2014 9:01:52 AM UTC-5, Joachim Tuchel wrote:

Sorry, Google or Safari reacted a little strange to pressing ^

so let's start again:

Start with a clean image.

Open a Class Browser on whatever class you want

implement a method like this:

doSomething

        ^SomeNonExistingClass doSomething 

Try to save the method. The Browser won't tell you it didn't save, it will just underline the non existing class name in red and ignore you.

So far I can tell that unimplemented method sends (purple underlines) do not behave this way - only red underlined unknown receivers.

I am quite sure this is not only true for class name typos, because I don't reference Classes too often in my code, but that is a scenario I know for sure shows the described behavior. I guess this behavior shows up for every situation where Code Assist will underline in red.

I'm not really sure what exact behavior I'd like to see. But I know it is sometimes strange that you think you've fixed code in the Debugger but the fix never gets saved.

Joachim

Loading in code I understand since you are taking external, possibly incompatible, code and want to get far enough so you can get it into the system so you can fix it.

But when modifying or creating new code in the editor, under what conditions would you want to allow saving code that does not compile?

I'm not having success replicating this issue, so I guess I'll prod a little more.
If I'm in a debugger session, the first time I type anything, valid or not, it should come up with a dialog box saying "Text has been modified...." and you accept or reject.

I'm assuming if you press over, into, resume or whatever, that you are going to see this first....Correct?

If there is a compiler error in the source, and I select the option to save the text from the dialog box, then the compiler error flashes which is the analog to source being injected into the editor (the old way of doing things).  Is this Correct?

When I hear the source is lost...I'm thinking of some situation where I type some source in the debugger, press resume, and it happily moves forward without any indication that it didn't save.  No Dialog box, no flashing red squiggle...it just continues.  

Is this what is happening?

On Tuesday, November 11, 2014 12:02:55 PM UTC-5, Joachim Tuchel wrote:

Hi Seth,

I guess in my case it is a mix of 1 and 2, unlikely 3.

The problem I am describing is that the existing behavior leaves me (and obviously others as well) with the fact that we seem to loose code changes in the debugger.

It sure is debatable if the ability to save code that doesn't compile is of any use.

So far, all we knew was that there are situations in which we pressed Resume in the debugger and our code changes were lost. Maybe that is not a big deal, and maybe it can be fixed easily by deactivating "Resume" as long as there are changes and the method has Fatal Errors - I don't really know yet.

So with this new knowledge (or new perspective) , I will watch myself a bit more cautiously when I'm debugging. For now I tend to think the debugger should have kept me from pressing Resume as long as I have unsaved (non-compiling) changes, or it should have told me my changes cannot be compiled more obviously - I haven't decided yet.

Joachim

 

Am Dienstag, 11. November 2014 16:08:06 UTC+1 schrieb Seth Berman:

All,

Old Policy: When you try to save a method with a compiler error, the compiler error description was injected into the source text around the location of the error.

New Policy: When you try to save a method with a Fatal Error (i.e. Compiler Error), then the first occurrence will be scrolled into view and the Red Squiggle will flash a few times to indicate that the fatal error instance is keeping the source from saving.

Red Squiggle =      Fatal Error  (something that should keep the source from saving like a compiler error)

Purple Squiggle = Error             (misspelled/missing system selector.  Does not keep the source from saving....could be a proxy method or some other situation)

Yellow Squiggle = Warning       (typically a result of some kind of code analysis....more of this in 8.6.1)
Gray Squiggle =    Info                (a suggestion based on some kind of code analysis...more of this in 8.6.1)

I'm trying to draw a conclusion from all the posts....is it that folks

1. Did not know the information I just provided?
2. Knew the information I just provided, but think the indications are too subtle?
3. Are talking about something else that is broken and I have missed the issue?

-- Seth

On Tuesday, November 11, 2014 9:01:52 AM UTC-5, Joachim Tuchel wrote:

Sorry, Google or Safari reacted a little strange to pressing ^

so let's start again:

Start with a clean image.

Open a Class Browser on whatever class you want

implement a method like this:

doSomething

        ^SomeNonExistingClass doSomething 

Try to save the method. The Browser won't tell you it didn't save, it will just underline the non existing class name in red and ignore you.

So far I can tell that unimplemented method sends (purple underlines) do not behave this way - only red underlined unknown receivers.

I am quite sure this is not only true for class name typos, because I don't reference Classes too often in my code, but that is a scenario I know for sure shows the described behavior. I guess this behavior shows up for every situation where Code Assist will underline in red.

I'm not really sure what exact behavior I'd like to see. But I know it is sometimes strange that you think you've fixed code in the Debugger but the fix never gets saved.

Joachim

Hi Seth, I have not seen this problem, so my opinion may not match others.
1) is definitely the case for me and one I disagree with.

If there is an error, please continue inserting the compiler error information at the correct point. Enclose it in double quotes to make it a comment, so it doesn't add any further errors to the source code.
 

first of all, I just want to make clear that I cannot definitely say that the one and only reason for the "lost code changes" problem is the existence of Compiler Errors in the changed code. I just stumbled across that effect of unsaved method changes in a Class Browser and thought that this might be the or at least one of the possible reasons. So this is probably just one piece in a mosaic where several people now ended up with their changes in the debugger being "lost".

More comments below

Am Dienstag, 11. November 2014 18:53:10 UTC+1 schrieb Seth Berman:

Hi Joachim,

Saving code that does not compile.

Loading in code I understand since you are taking external, possibly incompatible, code and want to get far enough so you can get it into the system so you can fix it.

But when modifying or creating new code in the editor, under what conditions would you want to allow saving code that does not compile?

Debugger issue

I'm not having success replicating this issue, so I guess I'll prod a little more.

If I'm in a debugger session, the first time I type anything, valid or not, it should come up with a dialog box saying "Text has been modified...." and you accept or reject.

I'm assuming if you press over, into, resume or whatever, that you are going to see this first....Correct?

If there is a compiler error in the source, and I select the option to save the text from the dialog box, then the compiler error flashes which is the analog to source being injected into the editor (the old way of doing things).  Is this Correct?

When I hear the source is lost...I'm thinking of some situation where I type some source in the debugger, press resume, and it happily moves forward without any indication that it didn't save.  No Dialog box, no flashing red squiggle...it just continues.  

David

Totally Objects.

On Tuesday, November 11, 2014 5:53:10 PM UTC, Seth Berman wrote:

Hi Joachim,

Saving code that does not compile.

Loading in code I understand since you are taking external, possibly incompatible, code and want to get far enough so you can get it into the system so you can fix it.

But when modifying or creating new code in the editor, under what conditions would you want to allow saving code that does not compile?

Debugger issue

I'm not having success replicating this issue, so I guess I'll prod a little more.
If I'm in a debugger session, the first time I type anything, valid or not, it should come up with a dialog box saying "Text has been modified...." and you accept or reject.

I'm assuming if you press over, into, resume or whatever, that you are going to see this first....Correct?

If there is a compiler error in the source, and I select the option to save the text from the dialog box, then the compiler error flashes which is the analog to source being injected into the editor (the old way of doing things).  Is this Correct?

When I hear the source is lost...I'm thinking of some situation where I type some source in the debugger, press resume, and it happily moves forward without any indication that it didn't save.  No Dialog box, no flashing red squiggle...it just continues.  

Is this what is happening?

On Tuesday, November 11, 2014 12:02:55 PM UTC-5, Joachim Tuchel wrote:

Hi Seth,

I guess in my case it is a mix of 1 and 2, unlikely 3.

The problem I am describing is that the existing behavior leaves me (and obviously others as well) with the fact that we seem to loose code changes in the debugger.

It sure is debatable if the ability to save code that doesn't compile is of any use.

So far, all we knew was that there are situations in which we pressed Resume in the debugger and our code changes were lost. Maybe that is not a big deal, and maybe it can be fixed easily by deactivating "Resume" as long as there are changes and the method has Fatal Errors - I don't really know yet.

So with this new knowledge (or new perspective) , I will watch myself a bit more cautiously when I'm debugging. For now I tend to think the debugger should have kept me from pressing Resume as long as I have unsaved (non-compiling) changes, or it should have told me my changes cannot be compiled more obviously - I haven't decided yet.

Joachim

 

Am Dienstag, 11. November 2014 16:08:06 UTC+1 schrieb Seth Berman:

All,

Old Policy: When you try to save a method with a compiler error, the compiler error description was injected into the source text around the location of the error.

New Policy: When you try to save a method with a Fatal Error (i.e. Compiler Error), then the first occurrence will be scrolled into view and the Red Squiggle will flash a few times to indicate that the fatal error instance is keeping the source from saving.

Red Squiggle =      Fatal Error  (something that should keep the source from saving like a compiler error)

Purple Squiggle = Error             (misspelled/missing system selector.  Does not keep the source from saving....could be a proxy method or some other situation)

Yellow Squiggle = Warning       (typically a result of some kind of code analysis....more of this in 8.6.1)
Gray Squiggle =    Info                (a suggestion based on some kind of code analysis...more of this in 8.6.1)

I'm trying to draw a conclusion from all the posts....is it that folks

1. Did not know the information I just provided?
2. Knew the information I just provided, but think the indications are too subtle?
3. Are talking about something else that is broken and I have missed the issue?

-- Seth

On Tuesday, November 11, 2014 9:01:52 AM UTC-5, Joachim Tuchel wrote:

Sorry, Google or Safari reacted a little strange to pressing ^

so let's start again:

Start with a clean image.

Open a Class Browser on whatever class you want

implement a method like this:

doSomething

        ^SomeNonExistingClass doSomething 

Try to save the method. The Browser won't tell you it didn't save, it will just underline the non existing class name in red and ignore you.

So far I can tell that unimplemented method sends (purple underlines) do not behave this way - only red underlined unknown receivers.

I am quite sure this is not only true for class name typos, because I don't reference Classes too often in my code, but that is a scenario I know for sure shows the described behavior. I guess this behavior shows up for every situation where Code Assist will underline in red.

I'm not really sure what exact behavior I'd like to see. But I know it is sometimes strange that you think you've fixed code in the Debugger but the fix never gets saved.

Joachim

David

Totally Objects.

On Wednesday, November 12, 2014 6:58:22 AM UTC, Joachim Tuchel wrote:

Hi Seth,

first of all, I just want to make clear that I cannot definitely say that the one and only reason for the "lost code changes" problem is the existence of Compiler Errors in the changed code. I just stumbled across that effect of unsaved method changes in a Class Browser and thought that this might be the or at least one of the possible reasons. So this is probably just one piece in a mosaic where several people now ended up with their changes in the debugger being "lost".

More comments below

Am Dienstag, 11. November 2014 18:53:10 UTC+1 schrieb Seth Berman:

Hi Joachim,

Saving code that does not compile.

Loading in code I understand since you are taking external, possibly incompatible, code and want to get far enough so you can get it into the system so you can fix it.

But when modifying or creating new code in the editor, under what conditions would you want to allow saving code that does not compile?

Well, sometimes I wish I could save the code, like when I just found out during my code edit that I want to use a new Class that I'll just implement right now. Of course I can switch to another Browser and just create the Class and come back and save my method once the reference can be resolved.

Since I have no idea whether saving code that doesn't compile will open a can of worms, I would clearly like to revoke my request to save such method.

 

Debugger issue

I'm not having success replicating this issue, so I guess I'll prod a little more.

I don't have the issue very often. Can't say how often the others see it. So maybe this is because most of my edits don't lead to Compiler Errors, or because the problem lies somewhere completely different...

 

If I'm in a debugger session, the first time I type anything, valid or not, it should come up with a dialog box saying "Text has been modified...." and you accept or reject.

I'm assuming if you press over, into, resume or whatever, that you are going to see this first....Correct?

If there is a compiler error in the source, and I select the option to save the text from the dialog box, then the compiler error flashes which is the analog to source being injected into the editor (the old way of doing things).  Is this Correct?

Yes, it is correct.

When I hear the source is lost...I'm thinking of some situation where I type some source in the debugger, press resume, and it happily moves forward without any indication that it didn't save.  No Dialog box, no flashing red squiggle...it just continues.  

Not sure about the Squiggle. But sure no Dialog box or anything. You can simply Resume or step Over/Into and will find the source code is not changed.

So this may possibly boil down to me having to train myself in looking for Squiggle and being more careful ;-)

I can't tell you if the old debugger behavior was different, it is just that me and at least two other people seem to realize this more recently. So either there is some deeper problem than this, or the indication of Compiler Errors is not "loud" enough for us and we just never Resumed back in the days before the red squiggle.

 

Joachim 

I'm definitely looking into it.  I saw in another post you tried 8.6.1, so please let me know if you are still experiencing this issue in the new release.  In the meantime, I will drop back to 8.6 and try and see how this happens.  Thanks.

-- Seth

On Friday, November 14, 2014 2:49:11 PM UTC-5, Totally Objects wrote:

I have seen this too much. I am now calling up the editions of the method. Making my changes there to the latest (same as the debugger) version and then loading the new edition into the debugger. I didn't ever have to do this before 8.6 and I have been using VAST since 3.0!

David

Totally Objects.

On Wednesday, November 12, 2014 6:58:22 AM UTC, Joachim Tuchel wrote:

Hi Seth,

first of all, I just want to make clear that I cannot definitely say that the one and only reason for the "lost code changes" problem is the existence of Compiler Errors in the changed code. I just stumbled across that effect of unsaved method changes in a Class Browser and thought that this might be the or at least one of the possible reasons. So this is probably just one piece in a mosaic where several people now ended up with their changes in the debugger being "lost".

More comments below

Am Dienstag, 11. November 2014 18:53:10 UTC+1 schrieb Seth Berman:

Hi Joachim,

Saving code that does not compile.

Loading in code I understand since you are taking external, possibly incompatible, code and want to get far enough so you can get it into the system so you can fix it.

But when modifying or creating new code in the editor, under what conditions would you want to allow saving code that does not compile?

Well, sometimes I wish I could save the code, like when I just found out during my code edit that I want to use a new Class that I'll just implement right now. Of course I can switch to another Browser and just create the Class and come back and save my method once the reference can be resolved.

Since I have no idea whether saving code that doesn't compile will open a can of worms, I would clearly like to revoke my request to save such method.

 

Debugger issue

I'm not having success replicating this issue, so I guess I'll prod a little more.

I don't have the issue very often. Can't say how often the others see it. So maybe this is because most of my edits don't lead to Compiler Errors, or because the problem lies somewhere completely different...

 

If I'm in a debugger session, the first time I type anything, valid or not, it should come up with a dialog box saying "Text has been modified...." and you accept or reject.

I'm assuming if you press over, into, resume or whatever, that you are going to see this first....Correct?

If there is a compiler error in the source, and I select the option to save the text from the dialog box, then the compiler error flashes which is the analog to source being injected into the editor (the old way of doing things).  Is this Correct?

Yes, it is correct.

When I hear the source is lost...I'm thinking of some situation where I type some source in the debugger, press resume, and it happily moves forward without any indication that it didn't save.  No Dialog box, no flashing red squiggle...it just continues.  

Not sure about the Squiggle. But sure no Dialog box or anything. You can simply Resume or step Over/Into and will find the source code is not changed.

So this may possibly boil down to me having to train myself in looking for Squiggle and being more careful ;-)

I can't tell you if the old debugger behavior was different, it is just that me and at least two other people seem to realize this more recently. So either there is some deeper problem than this, or the indication of Compiler Errors is not "loud" enough for us and we just never Resumed back in the days before the red squiggle.

 

Joachim 

David

On Friday, November 14, 2014 8:32:42 PM UTC, Seth Berman wrote:

Hello David,

I'm definitely looking into it.  I saw in another post you tried 8.6.1, so please let me know if you are still experiencing this issue in the new release.  In the meantime, I will drop back to 8.6 and try and see how this happens.  Thanks.

-- Seth

On Friday, November 14, 2014 2:49:11 PM UTC-5, Totally Objects wrote:

I have seen this too much. I am now calling up the editions of the method. Making my changes there to the latest (same as the debugger) version and then loading the new edition into the debugger. I didn't ever have to do this before 8.6 and I have been using VAST since 3.0!

David

Totally Objects.

On Wednesday, November 12, 2014 6:58:22 AM UTC, Joachim Tuchel wrote:

Hi Seth,

first of all, I just want to make clear that I cannot definitely say that the one and only reason for the "lost code changes" problem is the existence of Compiler Errors in the changed code. I just stumbled across that effect of unsaved method changes in a Class Browser and thought that this might be the or at least one of the possible reasons. So this is probably just one piece in a mosaic where several people now ended up with their changes in the debugger being "lost".

More comments below

Am Dienstag, 11. November 2014 18:53:10 UTC+1 schrieb Seth Berman:

Hi Joachim,

Saving code that does not compile.

Loading in code I understand since you are taking external, possibly incompatible, code and want to get far enough so you can get it into the system so you can fix it.

But when modifying or creating new code in the editor, under what conditions would you want to allow saving code that does not compile?

Well, sometimes I wish I could save the code, like when I just found out during my code edit that I want to use a new Class that I'll just implement right now. Of course I can switch to another Browser and just create the Class and come back and save my method once the reference can be resolved.

Since I have no idea whether saving code that doesn't compile will open a can of worms, I would clearly like to revoke my request to save such method.

 

Debugger issue

I'm not having success replicating this issue, so I guess I'll prod a little more.

I don't have the issue very often. Can't say how often the others see it. So maybe this is because most of my edits don't lead to Compiler Errors, or because the problem lies somewhere completely different...

 

If I'm in a debugger session, the first time I type anything, valid or not, it should come up with a dialog box saying "Text has been modified...." and you accept or reject.

I'm assuming if you press over, into, resume or whatever, that you are going to see this first....Correct?

If there is a compiler error in the source, and I select the option to save the text from the dialog box, then the compiler error flashes which is the analog to source being injected into the editor (the old way of doing things).  Is this Correct?

Yes, it is correct.

When I hear the source is lost...I'm thinking of some situation where I type some source in the debugger, press resume, and it happily moves forward without any indication that it didn't save.  No Dialog box, no flashing red squiggle...it just continues.  

Not sure about the Squiggle. But sure no Dialog box or anything. You can simply Resume or step Over/Into and will find the source code is not changed.

So this may possibly boil down to me having to train myself in looking for Squiggle and being more careful ;-)

I can't tell you if the old debugger behavior was different, it is just that me and at least two other people seem to realize this more recently. So either there is some deeper problem than this, or the indication of Compiler Errors is not "loud" enough for us and we just never Resumed back in the days before the red squiggle.

 

Joachim