Save Live Watch variable in IAR Workbench as LOG file - debugging

I don't know if it's possible as the IAR Workbench manual doesn't cite something like that but I would like to generate some sort of LOG from the LIVE Watch variables.
For istance, if I'm live watching var1 I would like to generate a formatted text file like:
16-05-2022 11:51:01 var1 120
16-05-2022 11:51:02 var1 122
16-05-2022 11:51:03 var1 116
16-05-2022 11:51:04 var1 102
Is there a way to do that? Or at least to read this kind of information somewhere so I can write some sort of code in python or something to read the values?
I'm using IAW Workbench 6.5

So it turned out there's no way to actually save the variables as LOG.
The only workaround is to use breakpoints and macros to dump the value but, unfortunately, this is not a solution on my end as the breakpoints need user intervention to start again the code

Related

How can I embed a test data set in my JMeter test plan?

At the moment, my JMeter test uses a CSV Data Set Config to iterate through a limited set of input data for each HTTP request that I do.
But I don't want to deal with the hassle of an external file (uploading it to my test runner, etc.) - I'd like to just embed the data into the jmx file itself.
I was hoping for something like a "test data" node, that would work similarly to a CSV data set (with Recycle on EOF especially) and I'd just copy/paste the data into the test plan instead of working with an external file.
I'm thinking I might be able to work around it with a JSR223 preprocessor - but is there a better built-in way?
Edit: As per comment: the data cannot be generated.
If you want to do this via JSR223 Test Elements and Groovy language correct syntax would be
vars.put("messageId", "wibble");
vars is a shorthand for JMeterVariables class instance, see the JavaDoc for available functions and properties.
Easier way would be going for User Defined Variables or User Parameters or even better Set Variables Action
You can create a text contains keys and values separated with tab, copy all text
Notice if you have property file you can replace = with tab
Add to JMeter GUI User Defined Variables and click Add from Clipboard
It'll load all your variables to JMeter without "do that by hand using JMeter's GUI"
.
This is my first go at a script based approach using a JSR223 preprocessor node:
// This is where the data is embedded. Up to a couple of hundred entries
// is probably fine, more than that will likely be a bad idea.
def messageIdList = ["graffle", "wibble", "wobble", "flobble", "gibble", ...]
def messageIndex = (vars.getIteration() -1) % (messageIdList.size() -1)
println "iteration ${vars.iteration}, size ${messageIdList.size()}, index: ${messageIndex}"
vars.put("messageId", messageIdList[messageIndex]);
messageIndex++
This appears to do what I want, even when run in a Thread Group with multiple threads.
I'm not sure exactly what the vars.getIteration() represents, and I'm not clear about the precise lifetime / scope of the variables. But it'll do for now.
Any better answers will cheerfully accepted, marked and upvoted.

Can I tell SPSS to run certain syntax lines using a syntax command?

So I was wondering if it was possible to write something up in the syntax which tells the program to run certain command lines. I'm not very good at explaining, so here's an example:
*Total sample frequency.
FREQUENCIES VARIABLES=Age Gender CigDay CO Min_last Day_abs Cigs_Monthly
/ORDER=ANALYSIS.
*6. Next, using the split-file function, perform the frequency analysis for each gender.
* Split file.
SORT CASES BY Gender.
SPLIT FILE LAYERED BY Gender.
*7 Run frequency again.
FREQUENCIES VARIABLES=Age Gender CigDay CO Min_last Day_abs Cigs_Monthly
/ORDER=ANALYSIS.
So, I was wondering whether it was possible to not have to copy/paste the Frequency command and simply include a line of command that told SPSS to re-run the syntax rows 37 to 38 (Which is where the first frequency command written).
A short answer is - no. There is not a command available that would allow to run a specific line of syntax. Certainly you can do it manually by selecting and running the lines you need.
But there are other options available for such tasks when you need to re-run a part of the code several time:
Insert command. Save the code you need to run several time in an external syntax file and insert it when needed in your main syntax file.
Define and End Define commands. Define the code you need to run several time as a macro command and call it when needed in your main syntax file.
I suggest not using INCLUDE as it is obsolete, although it is still supported. INSERT provides better functionality.
If you set out to build a macro library for your frequently used commands, think about parameterizing them so that, for example, you can pass in the specific variables to use as arguments. See the Command Syntax Reference entry for DEFINE via the Help menu for full details, but be prepared to spend some time studying it.

Rstudio difference between run and source

I am using Rstudio and not sure how options "run" and "source" are different.
I tried googling these terms but 'source' is a very common word and wasn't able to get good search results :(
Run and source have subtly different meanings. According to the RStudio documentation,
The difference between running lines from a selection and invoking
Source is that when running a selection all lines are inserted
directly into the console whereas for Source the file is saved to a
temporary location and then sourced into the console from there
(thereby creating less clutter in the console).
Something to be aware of, is that sourcing functions in files makes them available for scripts to use. What does this mean? Imagine you are trying to troubleshoot a function that is called from a script. You need to source the file containing the function, to make the changes available in the function be used when that line in the script is then run.
A further aspect of this is that you can source functions from your scripts. I use this code to automatically source all of the functions in a directory, which makes it easy to run a long script with a single run:
# source our functions
code.dir <- "c:\temp"
code.files = dir(code.dir, pattern = "[.r]")
for (file in code.files){
source(file = file.path(code.dir,file))
}
Sometimes, for reasons I don't understand, you will get different behavior depending on whether you select all the lines of code and press the run the button or go to code menu and chose 'source.' For example, in one specific case, writing a gplot to a png file worked when I selected all my lines of code but the write failed to when I went to the code menu and chose 'source.' However, if I choose 'Source with Echo,' I'm able to print to a png file again.
I'm simply reporting a difference here that I've seen between the selecting and running all your lines and code and going to code menu and choosing 'source,' at least in the case when trying to print a gplot to a png file.
An important implication of #AndyClifton's answer is:
Rstudio breakpoints work in source (Ctrl-Shift-S) but not in run (Ctrl-Enter)
Presumably the reason is that with run, the code is getting passed straight into the console with no support for a partial submission.
You can still use browser() though with run though.
print() to console is supported in debugSource (Ctrl-Shift-S) as well as run.
The "run" button simply executes the selected line or lines. The "source" button will execute the entire active document. But why not just try them and see the difference?
I also just discovered that the encoding used to read the function sourced can also be different if you source the file or if you add the function of the source file to your environment with Ctrl+Enter!
In my case there was a regex with a special character (ยต) in my function. When I imported the function directly (Ctrl+Enter) everything would work, while I had an error when sourcing the file containing this function.
To solve this issue I specified the encoding of the sourced file in the source function (source("utils.R", encoding = "UTF-8")).
Run will run each line of code, which means that it hits enter at the beginning of each line, which prints the output to the console. Source won't print anything unless you source with echo, which means that ggplot won't print to pngs, as another posted mentioned.
A big practical difference between run and source is that if you get an unaccounted for error in source it'll break you out of the code without finishing, whereas run will just pass the next line to the console and keep going. This has been the main practical difference I've seen working on cleaning up other people's scripts.
When using RSTudio u can press the run button in the script section - it will run the selected line.
Next to it you have the re - run button, to run the line again. and the source button next to it will run entire chuncks of code.
I found a video about this topic:
http://www.youtube.com/watch?v=5YmcEYTSN7k
Source/Source with echo is used to execute the whole file whereas Run as far as my personal experience goes executes the line in which your cursor is present.
Thus, Run helps you to debug your code. Watch out for the environment. It will display what's happening in the stack.
To those saying plots do not show. They won't show in Plots console. But you can definitely save the plot to disc using Source in RStudio. Using this snippet:
png(filename)
print(p)
dev.off()
I can confirm plots are written to disc. Furthermore print statements are also outputted to the console

haxe - How to create clean terminal application in cpp environment?

I'd like to create utility that should be able to listen standard input and stream to standard output. Moreover I'd like to get command line arguments passed to utility. Is it possible to do with haxe/cpp environment?
What "trace()" exactly do? Can I override it's auto CR/LF with some ascii control characters to print pseudographical activity gauges?
I think that the trace function is inteded to be used only for debug, i think that's why it prints the file and the row from which you called it.
What I think you really want is Lib.print() and Lib.printl() to write something to the console.
For reading I didn't find a function as easy as that, but it's still easy enough, here's an example:
var stdin = Sys.stdin();
var string : String = stdin.readLine();
If you want to look more into console development in haxe I'd suggest you to look into some projects that uses them, for example to write this question I've read this file https://github.com/ianxm/ihx/blob/master/src/ihx/ConsoleReader.hx

Save the contents of a variable in Xcode Debugger

Running the debugger in Xcode when you set a breakpoint you get a view a variable and can see all of the fantastically interesting values associated with it.
Is there any way to save/export this data to a file?
I am of course having an issue where something is wrong but there is a ton of variables and I want to just compare one run of the program to the next easily.
You can use gdb for this. The following gdb commands are useful:
set log file <filename>
set logging on
... do interesting stuff ...
set logging off
This will log the section "do interesting stuff" to as a text file.
If you want to get really fancy and have a fixed set of commands/variables you want to dump, you can make a function and stick it in $HOME/.gdbinit. Then get to a breakpoint and just issue dumplog (if using the example below) at the gdb prompt.
# Example that just does some random stuff
define dumplog
set logging file foo.txt
b main
c
set logging on
po var1
po var2
set logging off
end
Another approach which I just learned is issuing the following from a terminal. It has the benefit of no manual intervention, but I just tried it and you get quite a bit of extra garbage in that file.
defaults write com.apple.Xcode PBXGDBDebuggerLogToFile YES
defaults write com.apple.Xcode PBXGDBDebuggerLogFileName <filename>
When you hover over a value, click on the double-headed arrows and you get a pop-up menu with a lot of options:
alt text http://idisk.mac.com/cdespinosa/Public/Print%20Description.png
Print Description will dump the information about the object to the gdb console, from which you can copy and paste it.

Resources