I tried to enable the debug syntax into estudio without afording it. In this case it is from a library and it doesnt enter into the
debug
io.put_string ("any debug statement here")
end
What's wrong with my configuration?
Debug statements can be enabled and disabled by the associated key. Provided that there is no key in the example, the statement can be turned on by setting the value for Unnamed Debugs to True.
Edit. Named debug statements look like
debug ("foo")
...
end
debug ("foo", "bar")
...
end
where foo and bar are debug keys that are used to select which statements to enable. Here, if foo is selected, both statements are enabled at run-time. If bar is selected, only the second statement is enabled.
Related
[At first, I'm Korean. And I'm not good at English. So plz understand my terrible English.]
VSCode has these two settings.
"editor.parameterHints.enabled": false
"C_Cpp.autocompleteAddParentheses": true
The question is, How can I use those two settings together?
When I write a message in parentheses in printf() at C, it shows parameter hint int printf(const char *const _Format, ...) by pop-up.
I don't wanna see that hint pop-up because it covers the code I wrote.
So I added that setting "editor.parameterHints.enabled": false.
But it didn't work!
And finally I realized why it didn't work.
The reason why is "C_Cpp.autocompleteAddParentheses": true.
If I change that into false, parameter hint is turned off normally.
But I want to use both of those settings together.
Why can't I use the two settings together?
Sometimes the checks and contract constructions need an elaboration which wants to be avoided when assertions removed to improve performances and avoid doing useless things with the "only" work of the compiler. I refer for ex. to job in loops checks or other things. Sometimes having to build a function or having to think how to build it without being executed when assertions are on goes away of the intuitive way of the contract and its sense. I refer particularly to the check structure
Is there a way to do something such as
if checks_are_enabled then
do check stuff here
end
do_some_normal_job
if checks_are_enabled then
do other check stuff here
end
Assertions can be turned on and off on a class-by-class basis, with different levels: preconditions, postconditions, invariants, etc. As a result, it would be tricky and unreliable to report when they are enabled or not (consider, for example, inherited code: the checks might be on in one case and off in another). On a methodological level it would also break the idea that a correct program works the same way regardless of assertion monitoring.
What are workarounds?
If assertions are complex, they can be factored out to dedicated queries and look like
check
is_valid: complex_query
end
An alternative is to use debug statements:
debug ("check_this", "check_that")
... some complex code, including assertions
end
where "check_this" and "check_that" are debug keys that can be turned on when compiling for debugging.
There are hacks that could work now, but not in the future:
If a complex state needs to be computed and then checked after some operation, it can be saved in an object passed to some function with complex calculations and used later again:
check
is_valid_before: valid_pre (state) -- The state is computed by `valid_pre`.
end
code_that_does_the_work
check
is_valid_after: valid_post (state) -- The state is checked by `valid_post`.
end
Some global flag can be used to keep track about assertion monitoring:
check
is_monitoring_checks
end
where query is_monitoring_checks has side effects:
is_monitoring_checks: BOOLEAN
-- Record whether assertion checks are turned on.
do
is_check_on := True
Result := True
end
Then, subsequent code could be written as asked in the question:
if is_check_on then
... -- Do some complex calculations when assertions are turned on.
end
In SSMS (SQL Server Management Studio) debugger shows question mark for substring's return value when called from a function
I have a query with these two lines
SELECT SUBSTRING(N'אאא',1,1);
SELECT dbo.testsubstring5(N'א');
I put a breakpoint on the first and hit debug.
As you can see SUBSTRING works fine so far. That's when outside of the function call.
Now we when we go inside dbo.testsubstring5 then for some reason SUBSTRING doesn't output the correct result in the debugger, though it does still work correctly outside of the debugger.
Look at the watch window of the debugger in the picture below
Notice the problem, that
SUBSTRING(#str,1,1) fails, it gives the result of ?
Also as you see in that watch window, UNICODE(SUBSTRING(#str,1,1)) gives the value of 63 which is the ASCII value of question mark.
The correct values are returned in the program though, for example, the watch window shows the correct values for #zzz, #zzz1, and #zzz2
So it seems to be an issue with the debugger window , for substring, when substring is called within a function. I must be missing something though I don't know what.
SQL Server seems to have some issues displaying UNICODE characters in grid (result or watch). If you try to print output to TEXT (CTRL + T) rather that debugging, it should print correct value.
Edited with image of result for the guy who voted the answer down.
Result in watch windows while debugging
Result when printed to TEXT
Seems that problem with result grid is resolved. I am using SSMS version 2012 and don's see this issue now. I remember having this issue in older version of SSMS. But this is still an issue with debug.
I'm creating an application that requires me to post a lot of data into tables as well as changing values within the table.
Whenever I write applications most of my time seems to be stopping errors such as:
'Cannot perform this method on a closed dataset'`
or
'tblName not in edit or insert mode'`
I seemingly get these every time and they aren't easy to debug and find out what's going wrong where.
I'm just looking for some guidance on how I can stop this from happening, I know it's something I am doing. For example, at the moment I am getting:
'Cannot perform this operation on a closed dataset'
somewhere within this code:
procedure TfrmMain.FormClose(Sender: TObject; var Action: TCloseAction);
begin
if not tblSystem.Active then
tblSystem.Open;
if not tblSpecs.Active then
tblSpecs.Open;
tblSpecs.Edit;
tblSpecs.Post;
tblSpecs.Close;
// Post changes to the notes on exit
tblSystem.Edit;
tblsystem.Post;
tblSystem.Close;
end;
and
procedure TfrmMain.chkAutoUpdateClick(Sender: TObject);
begin
tblSystem.Edit;
if chkAutoUpdate.Checked then
chkInstUpdates.Enabled := True
else
begin
chkInstUpdates.Enabled := False;
tblSystemAutoUpdate.AsBoolean := False;
end;
end;
I'm going to assume right away that this is bad code for pushing/pulling data from a table, any help would be appreciated. Also any debugging help would be amazing.
If I were to guess, I'd say that it's this line:
tblSystemAutoUpdate.AsBoolean := False;
You're trying to edit the value of a dataset field without its dataset actually being open.
WRT debugging help, when you get the exception message and it asks you to Break or Continue, choose Break. The stack trace view (upper-left pane in the standard layout) will show you the function call stack of the current thread, and that should be able to lead you right to it. Also, make sure you build developer builds of your code with the "Use Debug DCUs" project option enabled. That will let you trace into RTL and VCL units in the debugger.
I have a try-catch block like this:
Try
Listbox1.RemoveRow(Listbox1.ListIndex)
Catch err As OutOfBoundsException
MsgBox("Derp")
End Try
When I run my project in the debugger I get an OutOfBoundsException on the exact line I was trying to catch! Why doesn't this work?!?
Seems to me like the debugger will break at that line and show you the exception. But if you hit resume, it will continue, catch the exception, and then display the message.
Maybe they changed the behavior of the debugger with this release.
Update: You can go to Project > Break on exception to change this
The debugger will break as soon as the exception is encountered, before any other code gets executed. This includes any exception handling code you may have put in like a Try...Catch block.
If you have a bit of code that raises a lot of exceptions and you'd rather not have to step through it every single time you debug, you have two options: nuclear and surgical.
The nuclear option is to tell the debugger to NOT break on any exceptions at all, which has the unfortunate side effect of applying to your entire project instead of the small portion of it you're excepting on.
The surgical option is to use pragma directives to toggle breaking on exceptions off and on around the troublesome code:
#Pragma BreakOnExceptions Off
try
Listbox1.RemoveRow Listbox1.ListIndex
catch err As OutOfBoundsException
MsgBox "Derp"
End
#Pragma BreakOnExceptions On
This is much more preferable then simply turning off part of the debugger altogether. Note: the BreakOnExepctions directive will revert to you global setting (on or off) as soon as the function returns and is local to the code it surrounds.