In jprofiler's CPU Views tab, the call graph typically displays the number of invocations of each method (ex, 214 inv.). However, on some of my methods, it shows "evt." instead (ex, 460 evt.). What does evt stand for, and how does it differ from number of invocations?
This depends on the thread status selection. For "All states" and "Runnable" JProfiler shows invocations, hence "inv.". For "Waiting", "Blocked" and "Net IO", it shows the cumulated number of events ("evt.") that are associated with the selected thread status. This is not necessarily the same as the number of times the methods in the call tree have been invoked.
Related
So I have my Q and E set to control a Camera that is fixed in 8 directions. The problem is when I call Input.is_action_just_pressed() it sets true two times, so it does its content twice.
This is what it does with the counter:
0 0 0 0 1 1 2 2 2 2
How can I fix thix?
if Input.is_action_just_pressed("camera_right", true):
if cardinal_count < cardinal_index.size() - 1:
cardinal_count += 1
else:
cardinal_count = 0
emit_signal("cardinal_count_changed", cardinal_count)
On _process or _physics_process
Your code should work correctly - without reporting twice - if it is running in _process or _physics_process.
This is because is_action_just_pressed will return if the action was pressed in the current frame. By default that means graphics frame, but the method actually detect if it is being called in the physics frame or graphic frame, as you can see in its source code. And by design you only get one call of _process per graphics frame, and one call of _physics_process per physics frame.
On _input
However, if you are running the code in _input, remember you will get a call of _input for every input event. And there can be multiple in a single frame. Thus, there can be multiple calls of _input where is_action_just_pressed. That is because they are in the same frame (graphics frame, which is the default).
Now, let us look at the proposed solution (from comments):
if event is InputEventKey:
if Input.is_action_just_pressed("camera_right", true) and not event.is_echo():
# whatever
pass
It is testing if the "camera_right" action was pressed in the current graphics frame. But it could be a different input event that one being currently processed (event).
Thus, you can fool this code. Press the key configured to "camera_right" and something else at the same time (or fast enough to be in the same frame), and the execution will enter there twice. Which is what we are trying to avoid.
To avoid it correctly, you need to check that the current event is the action you are interested in. Which you can do with event.is_action("camera_right"). Now, you have a choice. You can do this:
if event.is_action("camera_right") and event.is_pressed() and not event.is_echo():
# whatever
pass
Which is what I would suggest. It checks that it is the correct action, that it is a press (not a release) event, and it is not an echo (which are form keyboard repetition).
Or you could do this:
if event.is_action("camera_right") and Input.is_action_just_pressed("camera_right", true) and not event.is_echo():
# whatever
pass
Which I'm not suggesting because: first, it is longer; and second, is_action_just_pressed is really not meant to be used in _input. Since is_action_just_pressed is tied to the concept of a frame. The design of is_action_just_pressed is intended to work with _process or _physics_process, NOT _input.
So, apparently theres a built in method for echo detection:
is_echo()
Im closing this.
I've encountered the same issue and in my case it was down to the fact that my scene (the one containing the Input.is_action_just_pressed check) was placed in the scene tree, and was also autoloaded, which meant that the input was picked up from both locations and executed twice.
I took it out as an autoload and Input.is_action_just_pressed is now triggered once per input.
Event Aging
The process of aging resets status bit 3 – ConfirmedDTC when a sufficient amount of time
has elapsed so that the cause for the error entry is assumedly not relevant anymore. This
is often used as a trigger to also clear stored snapshots or extended data from the event
memory.
But I don't get the healing process. I couldn't find anything about it.
Aged counter
Aging Counter The Dem module provides the ability to remove a specific event from the event memory, if its fault conditions are not fulfilled for a certain period of time (operation cycles). This process is called as "aging" or "unlearning". The usage of this feature requires the maintaining of an additional NVRAM block
Healing counter
Available both in positive direction, counting up from 0 (healing not started), latching at 255;
and in reverse counting down from the healing threshold (healing not started) to 0. The
counter is incremented resp. decremented as soon as the healing conditions are fulfilled (at
the end of a ‘passed’ tested operation cycle without failed result), irrespective of the status
of the ‘ConfirmedDTC ‘ or ‘WarningIndicatorRequested’ status bit.
The up-counting data element corresponds to ‘Cycles Tested Since Last Failed’.
Both data elements are also calculated for events without indicator.
I found the following Diagram in AUTOSAR documentation, now It's clear
According to AUTOSAR DEM SWS Document :
Healing of diagnostic events
The Dem module provides the ability to activate and deactivate indicators per event
stored in the event memory. The process of deactivation is defined as healing of a
diagnostic event.
Aging of diagnostic events
The Dem module provides the ability to remove a specific event from the event memory, if its fault conditions are not fulfilled for a certain period of time (operation cycles).This process is called as "aging" or "unlearning".
Few points to notice ( According to my point of view ) :
1 - Each one of them has a separate counter and a separate threshold, When the counting value meets the provided threshold, corresponding action is being taken.
2 - Normally, healing comes before aging.
3 - Aging resets the confirmedDTC bit in the status byte of the DTC. Healing just means we have an operation cycle in which the event status byte never had the testFailedThisOperationCycle bit set before.
Using --debug-flags ExecAll tracing, I found that there is a bug at the Nth instruction, which happens at the Nth line of the log.
Is there an easy way to break specifically at that instruction to debug it in GDB and view gem5's internal state?
The simplest approach is to use --debug-break as shown at: schedBreak(<tick>) gdb debugging function not working
That makes gem5 raise a signal at a given simulation, which GDB stops at by default. You can determine what simulation time corresponds to your instruction by looking at an --debug-flags ExecAll trace beforehand.
You will want to break on the tick much more often than on the Nth instructions, in particular since gem5 simulates the instruction pipeline, and therefor there can be multiple instructions in flight at the same time.
Alternatively, from GDB your point of interest sees the ExecutionContext object, which if often called xc, you can just add a conditional breakpoint like:
b MyClass::myFunction if xc->numInsts.data()->value() == <n> - 2
The -2 is needed because this index is zero based, and because the tick increments after instruction execution.
You can also find the tick time rather than instruction count with:
p xc->cpu->tick
or from the other commonly available ThreadContext object with:
p tc->baseCpu->tick
You generally want to do this from the ::tick() function of your CPU model of interest.
For AtomicSimpleCPU::tick() you could also break just before the second instruction with:
b AtomicSimpleCPU::tick if (*threadInfo[curThread]).numInst == 1
Or to break at a given tick, say 1000 (500 is the one before it):
b AtomicSimpleCPU::tick if tick == 500
Two other important break locations are at the main event loop when an event is executed:
b EventQueue::serviceOne() if head->when() == 1000
and the event scheduling target point:
b EventQueue::schedule if when == <target-time>
b EventQueue::reschedule if when == <target-time>
or for the time of schedule itself:
b EventQueue::schedule if _curTick == 1000
b EventQueue::reschedule if _curTick == 1000
Together with reverse debugging and:
--debug-flags Event
these event breakpoints will actually allow you to understand what gem5 is doing.
Note however that conditional breakpoints significantly slow down simulation unfortunately... arghh.
Another useful technique to have in mind is that you can do a run that stops shortly after the point of interest with:
-m <tick>
and then reverse debug back to the exact point of interest, possibly conditionally since now you will be close the the point of interest, so the performance loss will not be a huge problem. You can then just continue going back to the root cause.
Tested in gem5 9f247403e558977738b5911a45e5776afff87b1a.
I am building a work-logging app which starts by showing a list of projects that I can select, and then when one is selected you get a collection of other buttons, to log data related to that selected project.
I decided to have a selected_project : Maybe Int in my model (projects are keyed off an integer id), which gets filled with Just 2 if you select project 2, for example.
The buttons that appear when a project is selected send messages like AddMinutes 10 (i.e. log 10 minutes of work to the selected project).
Obviously the update function will receive one of these types of messages only if a project has been selected but I still have to keep checking that selected_project is a Just p.
Is there any way to avoid this?
One idea I had was to have the buttons send a message which contains the project id, such as AddMinutes 2 10 (i.e. log 10 minutes of work to project 2). To some extent this works, but I now get a duplication -- the Just 2 in the model.selected_project and the AddMinutes 2 ... message that the button emits.
Update
As Simon notes, the repeated check that model.selected_project is a Just p has its upside: the model stays relatively more decoupled from the UI. For example, there might be other UI ways to update the projects and you might not need to have first selected a project.
To avoid having to check the Maybe each time you need a function which puts you into a context wherein the value "wrapped" by the Maybe is available. That function is Maybe.map.
In your case, to handle the AddMinutes Int message you can simply call: Maybe.map (functionWhichAddsMinutes minutes) model.selected_project.
Clearly, there's a little bit more to it since you have to produce a model, but the point is you can use Maybe.map to perform an operation if the value is available in the Maybe. And to handle the Maybe.Nothing case, you can use Maybe.withDefault.
At the end of the day is this any better than using a case expression? Maybe, maybe not (pun intended).
Personally, I have used the technique of providing the ID along with the message and I was satisfied with the result.
I am looking for a function to schedule a function call asynchronously, for example presenting an Image after 100ms, after 200ms and after 300ms and masking this image at 150ms 250ms and 350ms.
I am sure I can do this with delays, but I would prefer to do this asynchronously. I was able to do this in pyepl with timing.timedCall.
To be genuinely 'aysnchronous' would need threads and, as Jonas suggests, these aren't safe for use with OpenGL (your graphics card doesn't know which thread a command is coming from and if its commands are executed out of order because of two interleaved threads then the results are unpredictable and could lead to a crash).
I'd naturally handle this with a function like
def checkTimes(t, listOfPermissible):
for start,stop in listofPermissible:
if start < t < stop:
return True #we found a valid window
return False #if we got here there was no valid window
and then in my script I'd have:
targetTimes = [[0.1, 0.15], [0.2, 0.25]]
maskTimes = [[0.18, 0.2], [0.28, 0.3]]
while continueTrial:
t = trialClock.getTime()
#check if we need target
if checkTimes(t, targetTimes):
target.draw()
#check if we need mask
if checkTimes(t, maskTimes):
mask.draw()
#drawing complete so flip the window
win.flip()
#check for response
keys = event.getKeys()
if keys:
continueTrial = False
Jonas is also right though that you should use frame numbers instead of clock time if you have brief stimuli and care about them being precisely timed. As a cheeky example in the code above I've added some impossible times. For example 0.18 (180ms) which isn't possible with a 60Hz monitor. In the code above the 0.18 will effectively get rounded up to the next frame and the stimulus will appear at 183ms (11 frames into the block).
The rest of the logic above (checking in a list of start/stops) should still work just the same though.
Jon
I don't think that there's currently any way to do this. Previous attempts to run parts of psychopy stimulus presentation separate threads have failed, as far as I know. It's something about OpenGL not really being robust to this.
If there is a way to display stimuli asynchroniously, beware that visual stuff should really be timed in terms of number of frames rather than milliseconds for the durations you're considering. Presenting at e.g. 100 ms could just barely miss the 6th frame, thus shown the image on the 7th frame (after 116.7 ms). This is one of the points where I think many other stimulus presentation software packages mislead the user.
The ```psychopy.visual.Window.flip()`` method allows for timing using frames.