Problem:
I'm running a script that includes an infinite loop and I would like to exit from this loop with user input. I don't want to use the standard "input" function because that pauses the execution of the loop while it waits for the user inputs. I want that the program keeps looping all the time (until some certain keyboard input is given). I don't want to exit from the loop with ctrl+c either because then the program shut down procedures that are located after the loop, are not executed.
Question:
In octave, when something is typed to the command window during execution of a script nothing is shown in the command window until the script has ended. From this it is clear that keyboard inputs that are given during the execution of a script are stored somewhere (is this right?). And now the big guestion is where? And how can I access this data?
I'm running Octave 4.0.0 in Win7
p.s. also other suggestions for stopping the loop are welcome
Use kbhit:
while (1)
if (kbhit (1) == 'x')
break
endif
sleep (0.2)
printf ("Loop is running...\n");
fflush (stdout);
endwhile
Or if you want to exit with ctrl-c and finalize your script use a unwind_protect, unwind_ptrotect_cleanup block
unwind_protect
while (1)
sleep (0.2)
printf ("Loop is running...\n");
fflush (stdout);
endwhile
unwind_protect_cleanup
disp ("doing my cleanup");
end_unwind_protect
In octave, when something is typed to the command window during execution of a script nothing is shown in the command window until the script has ended. From this it is clear that keyboard inputs that are given during the execution of a script are stored somewhere (is this right?). And now the big guestion is where? And how can I access this data?
This is called buffering and is a very common behaviour. The principle is simple. Instead of writing everything as it's ready, your system will keep it on a buffer and only write it when told to do so, or when the buffer is full. Many disks operations work like this, for example, when you copy a few small files into a USB stick (dependent on the mount options). Once the buffer is full, or when you click to eject the USB, stick, the system will then actually perform the write.
If you read the section Paging Screen Output of the Octave manual you will see:
Normally, no output is displayed by the pager until just before Octave is ready to print the top level prompt, or read from the standard input (for example, by using the fscanf or scanf functions). This means that there may be some delay before any output appears on your screen if you have asked Octave to perform a significant amount of work with a single command statement. The function fflush may be used to force output to be sent to the pager (or any other stream) immediately.
Alternatively, you can turn off this buffering with page_output_immediately():
Query or set the internal variable that controls whether Octave sends output to the pager as soon as it is available.
Otherwise, Octave buffers its output and waits until just before the prompt is printed to flush it to the pager.
Related
----------------- ORIGINAL QUESTION ------------------------
In Vulkan,
In order to begin issuing commands to secondary command buffers, is it mandatory to have already acquired the image and have called vkCmdBeginRenderPass() on the primary command buffer?
I'm a noob but that's what it seems like, to me.
------------------------ EDIT #2 --------------------------------
Yes, it is possible to do this:
Possibly asynchronously, process logic and record draw-calls in secondary command buffers.
Check if secondary command buffers have been recorded: if not, goto #1, else continue.
Acquire Image
Start primary command buffer; start renderpass.
Execute previously recorded secondary command buffers
Submit
Present
It depends on what do You mean by "issuing" commands to secondary command buffers and on commands You want to record in those secondary command buffers.
Not all commands can be recorded in secondary command buffers. But there are commands that can be recorded and which don't have anything to do with rendering (and thus with render passes) - data copy, timestamping (timer queries) these are examples. They are not connected in any way with render passes, so they don't require You to start a render pass.
But if You want to record drawing commands, and as You probably know, drawing can only be done from within render passes, then render pass needs to be started already (in the primary command buffer which calls this secondary command buffer).
As for vkAcquireNextImageKHR() function - this function is independent. If by "issuing" You mean recording, then You don't need to call this function. You can record any (valid) commands You want. Recording is just preparing commands for later use, for submission. The same applies to the title of Your question:
Possible to generate secondary command buffers before renderpass?
I know this is (hopefully) only a bad wording, but You can record any command buffer any time You want. It's the submission that counts and the order of commands recorded in the submitted command buffers. So how do You want to generate a command buffer before a render pass? If You want to record drawing commands and start a render pass, You need a render pass object. If You want to call a secondary command buffer from within a primary command buffer, and if this secondary command buffer draws something, then You need to record a render pass starting command first. After that You can call a secondary command buffer. But this secondary command buffer must be already recorded:
Each element of pCommandBuffers must be in the pending or executable
state.
So You need to record a secondary command buffer first, then You can record a primary command buffer which call this secondary command buffer.
But if You want to submit a command buffer which uses a swapchain image, then this image must be already acquired. As I (and others) have described in Your other question (trouble understanding cycling of framebuffers
), You cannot submit a command which uses a swapchain image, if this image is not yet acquired. But the submission and image acquiring has nothing to do with command buffer recording. You can record command buffers earlier. You can even pre-record various command buffers for various swapchain images. Again, recording is just preparing commands for later use. The actual usage occurs with submission. So You can only submit those command buffers that use swapchain images which were already acquired.
I hope this helps ;-).
Yes, it is possible to do what I was trying to do, which is to record draw commands to secondary command buffers before having to start recording the primary command buffer.
The problem was two-fold.
I wasn't setting the VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT on the 'flags' member of VkCommandBufferBeginInfo for the secondary buffer.
The error from the validation layer was misleading, which said: "No active render pass found at draw-time in Pipeline (0x12)!". This caused me to attempt wrong solutions.
In order to begin recording a secondary command buffer, you must call vkBeginCommandBuffer with a VkCommandBufferInheritanceInfo object. If you want to execute the secondary CB inside of a render pass, you must provide:
The VkRenderPass object for the pass it will be executed within. Note that this object is not the product of vkCmdBeginRenderPass.
The index of the subpass of the aforementioned VkRenderPass that this secondary CB will be executed within.
There is an optional VkFramebuffer, which specifies the images you would be rendering to. But as previously stated, this is optional. The specification says that providing this data may help performance, but it is optional nevertheless.
So no, there is nothing about secondary CBs that requires that there is an active render pass instance on the primary CB that it will be executed within.
I'm testing a real-time application on physical hardware via lauterbach-trace32 probe.
Trace32 documentation is too vast and very technical but I'm not able to find how to implement what I need. I would like to know if there is a method to execute a trace32 function every time a specific code line (under test) is reached in program execution.
What I need is something similar to trigger in database scenario, where an automatic event is raised every time a specific condition is satisfied.
Thank you all!
You can always set a breakpoint, which executes a PRACTICE command every time the breakpoints gets hit. E.g.
Break.Set myFunc /CMD "PRINT ""Hello World""" /RESUME
So this will stop your target CPU when functions myFunc() is reached. Then the PRACTICE command PRINT "Hello World" gets executed and finally your target CPU continues execution (thanks to the option /RESUME). (Consider that double quotes escape double quotes in strings)
Instead of a single command you can also execute more commands (by using option /CMD several times) or execute a PRACTICE script.
If you want to trigger debugger actions on a specific code line without stopping the CPU on that code line, you would need a real-time-trace with external trace interface. So e.g. you would need an ARM CPU with Embedded Trace Macro-cell (ETM) or a PowerPC with Nexus interface. Furthermore you would need Lauterbach hardware for trace-recording e.g. a PowerTrace, CombiProbe or uTrace.
If you have a real-time-trace you can set a "trigger-point" on the specific code line and a execute a command when the "trigger-point" triggers. It looks almost the same way than with breakpoints:
Break.Set myFunc /TraceTrigger /CMD "PRINT ""Hello World""" /RESUME
So the only difference is the option "/TraceTrigger". Of course you should ensure that the real-time-trace is actually working with your setup.
I have been researching for an answer for my question for a long while using Google and changing what words I use in-case I find my answer, I have had no luck.
What I want is to the read the output from a process in real-time, not when it finishes the command it has been given. I have a command that I use which doesn't end unless the user ends it manually, closes the form or an error occurs. So every timer interval I would like to read the output from the command prompt (process).
I use background workers to start the process so it doesn't interfere with the form if that is any help.
Thanks in advance.
I'm looking for a way to run a program when locking the screen in Fedora 15 (linux). Basically I want to start running a motion detection program when the screen locks, or I manually hit Ctrl+Alt+L, but I don't know what commands are being run or where to alias my own intermediate step in. I assume it's:
gnome-screensaver-command --lock
but am not sure how to go about this. Anybody know how, or a direction to start looking in?
Edit, since link was in a comment:
This is done with dbus-monitor and described here.
The dbus system advertises screen locking; monitor for ActiveChanged on org.gnome.ScreenSaver. (see http://people.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html )
e.g. (word-wrapped for clarity)
signal sender=:1.68 -> dest=(null destination)
serial=53 path=/org/gnome/ScreenSaver;
interface=org.gnome.ScreenSaver; member=ActiveChanged
boolean true
Unfortunately, this will require writing more code than just a shell script, I'm afraid; although I'd be curious if you could ask dbus to call your program as a handler for that signal, somehow; otherwise, I suppose you'd just start a daemon process and listen for that signal to be broadcast…
I have a routine that examines thousands of records looking for discrepancies. This can take upwards of 5 minutes to complete and although I provide a progress bar and elapsed time count, I'm not sure I want to encourage folk pressing ctrl-break to quit the report should it be taking longer than expected.
A button in the progress bar won't work as the form is non-modal, so is there any neat way of allowing users to quit in this situation?
You need DoEvents and a variable whose scope is greater than the scope of what you're running. That is, if it's just a procedure, you need a module level variable. If it's more than one module, you need a global variable. See here
Stopwatch at DDoE
Normally, the VB engine will tie up the processor until it's done. With DoEvents, however, VB allows the processor to work on whatever is next in the queue, then return to VB.
I don't think there is a way to do it like you would want it to work. VBA is a scripting language so when you start your procedure, it's gonna run until it's done. If you had another button somewhere that even WOULD let you click it while the original procedure was running, I'm not sure how you would reference that procedure and stop it.
You could do something like ask the user if they want to contine, but that would make it run even longer.
Also you could have your procedure check for a condition outside of Excel and keep running as long as it's true. Something easy might be check if a certain text file is in a folder. If you wanted the procedure to stop, open the folder and move the file. On your loop's next iteration, it wouldn't see the file and stop running. Cludgy, inefficient, and not elegant, but it would work. You could also have it check a cell, checkbox, radiobutton, basically any control in another Excel sheet running in another instance of Excel. Again cludgy.
CTRL+Break works. Accept it and move on. One neat trick about that though, is that if you password protect your code and they hit CTRL+Break, the debug option is unavailable and they will only get Continue or End.
If this is code that is run frequently, have you considered scripting something that runs it during times when a human is not using the computer? I used to run telnet screen scraping macros that would take hours to go through our widgets, but I always had them run either on a separate computer or when I wasn't there (nights/weekends).