I had ran my script and unable to see the buffer values in Buffer viewer. Can anyone please suggest if there is any settings to be changes
Ran my script to check for buffer values, but when i open the buffer viewer i dont see anything in the list but my script has passed successfully
Related
I'm trying to figure out the SIM7080G module. An error occurs with some queries. To see the error code, send the command AT+CMEE = 1.
The problem is that I send this command and I get the answer OK. Next, I check if the value was written and see that it remains the same, equal to “0”.
Some commands have the same behavior. For example, with the command AT + CNMP = 13 I want to select the operating mode “GSM”, but the value remains equal to 38 - “LTE”.
But for example, with the command AT + IPR = 115200 I change the baudrate and it is correctly set.
Please tell me what could be the reason.
Thanks in advance.
A reboot probably occurred between the set command and the subsequent read command.
Commands parameters can be designed with three different behaviors:
Never saved after reboot
Always saved after reboot
Saved in a specific profile section (this is usually the case for ETSI standard commands)
Apparently SIM7080G module don't support profile sections. Anyway, for every command, "Parameter Saving Mode" is specified in the AT command guide.
The options are:
NO_SAVE: never saved through reboot.
AUTO_SAVE: The parameter of the current AT command is saved in NVRAM
automatically, it takes effect immediately, and it won't be lost if module is rebooted.
AUTO_SAVE_REBOOT: The parameter of the current AT command is saved in NVRAM
automatically, it takes effect immediately, and it won't be lost if module is rebooted.
-: "-" this AT command doesn’t care the parameter saving mode
I am new to Tosca tool. There are some scripts already created earlier.
While running Template Instance, Error in loginfo says "Buffer with name 'WaitTime_S' was not found" and script failed.
In Tosca a Buffer is a value that has been set at a previous point in time either dynamically or statically.
Most likely your TestCase requires a Buffer to be set in a previous step or manually.
More information on Buffers can be found in the Tosca documentation
I'm running using oh-my-zsh. I was writing a fairly long commit message on the command line, and I hit something on the keyboard that caused it to disappear. I pushed the up key, hoping it would remain in the history, but it was not there.
So, I grumbled, rewrote the commit message, and as soon as I executed that command, the command I was writing before populated the command line, ready for editing.
This seems like a handy feature occasionally, to stash a command to run something else first. How do I do this on purpose?
You probably typed Esc-q, which is bound by default to the push-line command documented in man zshzle:
push-line (^Q ESC-Q ESC-q) (unbound) (unbound)
Push the current buffer onto the buffer stack and clear the
buffer. Next time the editor starts up, the buffer will be
popped off the top of the buffer stack and loaded into the edit-
ing buffer.
I'm building a simple talker/listener app that receives OSC data through UDP. I'm using OSCKit pod which itself uses CocoaAsyncSocket library for the internal UDP communication.
When I'm listening to a particular port to receive data from another OSC capable software, I log the received commands to a NSTextView. The problem is that sometimes, I receive thousands of messages in a very short period of time (EDIT: I just added a counter to see how many messages I'm receiving. I got over 14000 in just a few seconds and that is only a single moving object in my software). There is no way to predict when this is gonna happen so I cannot lock the textStorage object of the NSTextView to keep it from sending all its notifications to update the UI. The data is processed through a delegate callback function.
So how would you go around that limitation?
///Handle incoming OSC messages
func handle(_ message: OSCMessage!) {
print("OSC Message: \(message)")
let targetPath = message.address
let args = message.arguments
let msgAsString = "Path: \"\(targetPath)\"\nArguments: \n\(args)\n\n"
print(msgAsString)
oscLogView.string?.append(msgAsString)
oscLogView.scrollToEndOfDocument(self)
}
As you can see here (this is the callback function) I'm updating the TextView directly from the callback (both adding data and scrolling to the end), every time a message is received. This is where Instruments tell me the slow down happens and the append is the slowest one. I didn't go further than that in the analysis, but it certainly is due to the fact that it tries to do a visual update, which takes a lot more time than parsing 32bits of data, and when it's finished it receives another update right away from the server's buffer.
Could I send that call to the background thread? I don't feel like filling up the background thread with visual updates is such a great idea. Maybe growing my own string buffer and flushing it to the TextView every now and then with a timer?
I want to give this a console feel, but a console that freezes is not a console.
Here is a link to the project on github. the pods are all there and configured with cocoapods, so just open the workspace. You guys might not have anything to generate that much OSC traffic, but if you really feel like digging in, you can get IanniX, which is an open-source sequencer/trajectory automator that can generate OSC and a lot of it. I've just downloaded it and I'll build a quick project that should send enough data to freeze the app and I'll add it to the repo if anybody want to give it a shot.
I append the incoming data to a buffer variable and I use a timer that flushes that buffer to the textview every 0.2 seconds. The update cycle of the textview is way too slow to handle the amount of incoming data so unloding the network callback to a timer let the server process the data instead of being stopped every 32bits.
If anybody come up with a more elegant method, I'm open minded.
I tried to write an test application to capture the text from stdout of an 3rd console application.
I studied from many articles to use the CreatePipe API and have INDEED obtained the text AFTER the console application HAD FINISHED running.
I tried to make the console application keep printing something for more than 60 seconds, and the ReadFile funcion didn't return during this 60 seconds at all.
For the same purpose, I tried popen and fread, and everything went fine except the black console window created by popen.
Although the ReadFileEx and something about the overlapped I/O seems to be able to solve this problem but it's actually not.
Because the ReadFileEx required the file handle to be created to support overlapping, and this is always impossilbe because the file handle is created by the 3rd console application. It won't be under control unless we develop the console application by ourselves.
So is there any way to capture stdout from a 3rd console application whose life cycle is very long by CreatePipe?
Thanks in advance!
I finaly figured out the problem is the 3rd console application "MAC.EXE" doesn't invoke "fflush" after each progress output....
I manually append the fflush operation in the source code of mac.exe and the problem gets resolved.
So a new question is:
If the child process never call fflush and seldom print during running, how to read the content correctly?