Community
Participate
Working Groups
Build Identifier: Select some code that spans over more than one line. E.g. a = (100 * myVar1 + 200 * myVar2) * (100 * myVar3 + 200 * myVar4); Choose "Add watch expression" from the context menu or drag'n drop the selected expression to the the Expression View. The line endings confuse the debugger backend (gdb) and must be removed manually afterwards. These line endings should be remove automatically. Reproducible: Always
Created attachment 191588 [details] remove line endings This patch removes the line endings (\n and \r) when you use the editor's context menu or use drag'n drop.
Re-assigning to GDB. Since it's a back end problem, it should be handled in the back-end specific way.
I think the fix for the "Add watch expression..." context menu makes sense, I am not sure about the other change which should probably cover the DnD case. Maybe this should be split into two bugs. Could you move the code from the dialog to the action delegate (AddExpressionEditorActionDelegate) and replace all whitespace by a single space, like e.g. text.replaceAll("(\\r\\n|\\n|\t| )+", " ").trim(). Thanks!
(In reply to comment #3) > I think the fix for the "Add watch expression..." context menu makes sense, I > am not sure about the other change which should probably cover the DnD case. > Maybe this should be split into two bugs. You're right. The other change is necessary for Drag'n Drop and when you click the plus icon in the Expressions View. The Add Watch Expression window is from the platform so I cannot change it. > > Could you move the code from the dialog to the action delegate > (AddExpressionEditorActionDelegate) and replace all whitespace by a single > space, like e.g. text.replaceAll("(\\r\\n|\\n|\t| )+", " ").trim(). > > Thanks! I will submit a new patch with your suggestions.
Created attachment 195666 [details] Remove whitespace "Add watch expression..." context menu moved to AddExpressionEditorActionDelegate
Created attachment 195667 [details] Remove whitespace for GDB DSF This covers drag'n drop and Add Expression icon from expressions for GDB DSF implementation.
(In reply to comment #5) > Created attachment 195666 [details] > Remove whitespace "Add watch expression..." context menu > > moved to AddExpressionEditorActionDelegate Thanks, I committed this patch to HEAD.
*** cdt cvs genie on behalf of aleherbau *** Bug 340526 - Create watch expression: line endings should be removed Patch by Axel Mueller [*] AddExpressionEditorActionDelegate.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/actions/AddExpressionEditorActionDelegate.java?root=Tools_Project&r1=1.4&r2=1.5
(In reply to comment #7) > (In reply to comment #5) > > Created attachment 195666 [details] [details] > > Remove whitespace "Add watch expression..." context menu > > > > moved to AddExpressionEditorActionDelegate > > Thanks, I committed this patch to HEAD. Thanks for committing. What do you think about the second patch?
(In reply to comment #9) > Thanks for committing. What do you think about the second patch? I guess it works, but modifying the expression text on the fly looks a little "hacky". And as this is DSF-GDB specific I'll leave it to Marc.
(In reply to comment #6) > Created attachment 195667 [details] > Remove whitespace for GDB DSF > > This covers drag'n drop and Add Expression icon from expressions for GDB DSF > implementation. I played around with this and I wonder what is the right thing to do. If you add an expression before starting a DSF-GDB launch, then it is the platforms's ExpressionManagerModelProxy that adds the expression and it keeps the special characters. Once you start a DSF-GDB session, the existing expressions stay the same (so will still cause a problem), but new expressions have the special characters removed thanks to the patch. Not much we can do about this besides changing ExpressionManagerModelProxy also. But that made me think that if the platform allows for special characters, it is probably that in some cases it makes sense. So, I'm guessing the platform should not change ExpressionManagerModelProxy. So, we're back to changing it just for DSF-GDB. Now, I also noticed that because of bug 345476, it seems that the GdbExpressionVMProvider of DSF-GDB, does not get cleaned-up when we change the debug context. That seems to mean that all new expression, no matter what type of debug session is in focus, will go through GdbExpressionVMProvider. Suddenly, the default platform behavior is lost, even if you don't actually use DSF-GDB anymore. So, if I understand correctly, I think we should fix bug 345476, before changing expressions automatically. Even then, does it make sense to remove the special chars for expressions created while using DSF-GDB, but keep the special chars for expressions created while using other debuggers? All those expressions remain in the expressions view, even when we change debuggers, and will affect each other. I guess I don't understand how the platform means for us to use this ExpressionProvider functionality.
(In reply to comment #11) > If you add an expression before starting a DSF-GDB launch, then it is the > platforms's ExpressionManagerModelProxy that adds the expression and it keeps > the special characters. I did not notice. How would you add expressions before starting DSF-GDB? Do you think about a mixed session with Java or CDI-GDB? > But that made me think that if the platform allows for special characters, it > is probably that in some cases it makes sense. So, I'm guessing the platform > should not change ExpressionManagerModelProxy. So, we're back to changing it > just for DSF-GDB. I came to the same conclusion. I think the Java debugger does not care about the line endings. A look at the Add Expression Window which is not limited to one liners supports this. Otherwise I would change the expression string directly in the Drag'n drop class of the platform before an IExpression is created. > Even then, does it make sense to remove the special chars for expressions > created while using DSF-GDB, but keep the special chars for expressions created > while using other debuggers? All those expressions remain in the expressions > view, even when we change debuggers, and will affect each other. I don't know if other debuggers have problems with special characters (but it would not surprise me). GDB clearly has a problem with them. > So, if I understand correctly, I think we should fix bug > 345476, before changing expressions automatically. Sounds reasonable.
Java debugger does support multi-line expressions, and other debuggers may as well. So IMO we should not do anything to change that, even when DSF-GDB is the active debugging, because it would create an inconsistent behavior and lead to confusion. Stripping out line endings when sending commands to GDB sounds reasonable. Or just returning a nice, informative error message for expressions with newlines would be perfectly acceptable as well, IMO.
(In reply to comment #13) > Stripping out line endings when sending commands to GDB sounds reasonable. +1 > just returning a nice, informative error message for expressions with newlines > would be perfectly acceptable as well, IMO. -1 I don't want to see an error message when I drag'n drop an expression like the one in comment #0 . In case of GDB the newline characters should be removed automatically (that's the point of this bug report).
(In reply to comment #12) > (In reply to comment #11) > > If you add an expression before starting a DSF-GDB launch, then it is the > > platforms's ExpressionManagerModelProxy that adds the expression and it keeps > > the special characters. > I did not notice. How would you add expressions before starting DSF-GDB? Do you > think about a mixed session with Java or CDI-GDB? I drag&dropped the expression right after starting my eclipse. (In reply to comment #14) > (In reply to comment #13) > > Stripping out line endings when sending commands to GDB sounds reasonable. > +1 That sounds good to me.
