Background:
Working in eclipse, I have two function: do_something and perform_task. I know that do_something calls a number of other functions which in turn call others (and so on and so on) and somewhere down the line perform_task gets called as well.
Since this is a big project, lots of flows and so on, I've already found two different sequences where do_something activates perform_task through some other sequence of functions.
Actuall question:
Is there a way in eclipse to get the call hierarchy of a certain function, but only sequences that will include also a certain other function in the sequence?
Thinking of this in terms of graph paths, we have a directed graph, and instead of asking what are paths to node x, I want to know what are the paths to node x that include node y.
It's not exactly what you're asking for, but might be useful enough:
In the Call Hierarchy view, there's an option to show the callees of the selected method instead of the callers. Look at the view toolbar of Call Hiearchy for the two buttons that depict green dots connected with lines; those button toggle between the two modes.
If you select do_something and open the Call Hierarchy view on it, then set the mode to Show Callees you might be able to explore the various paths out of do_something that lead to perform_task.
Related
I've created a Pure Data abstraction which takes 5 MIDI controller IDs as arguments, and has two inlets (velocity and MIDI controller). I use spigot to output the input velocity at outlet i if the MIDI controller ID matches the i th argument to the abstraction.
I use this to control 5 sliders (volume, attack, decay, sustain, release) from my MIDI controller, which look like this:
As you can see, the abstraction is very repetitive, and ideally it would be able to take n arguments, outputting the slider value of the given MIDI slider at the i th outlet. Alternatively I could just use a single argument and use the abstraction anew for each slider, but that's a bit repetitive too.
Is there a way to take n arguments in my abstraction? Or, is there any other more elegant solution to control sliders from MIDI that I'm missing?
For core vanilla objects or externals it is a common feature to take a variable amount of arguments. Many objects like [trigger], [select], [pack] or [unpack] behave this way and create a number of xlets according to how many arguments they are given.
For abstractions however, there is no simple way to have a variable number of outputs depending on the number of arguments given. It's possible, but it's rather a hack.
Let's first look at some techniques to make the patches easier.
As you can see in the following screenshot the [expr] object in your patch can easily be substituted by a simple Pd object: [==]
Let's look at the MIDI messages. MIDI objects output the elements of the hierarchical tree: channel, controller, value in this order but from right to left (true for all objects in Pd, the rightmost outlet fires first). What you want is routing them according to the controller number, ignoring the channel number. For this you need to flip the order of the two first outlets so you can use the controller number as a selector in a list. One way to do this is to pack the numbers and then reorder them in a message using the dollar symbols (careful, dollar symbols in message objects operate on local messages, they have nothing to do with what dollar symbols do in object boxes). Another method would be to use the object [swap] (using [swap] in this case would reduce the number of objects by one in the patch, but the [pack] and [message( is more versatile, that's why I show it here).
Regarding the actual question of taking n arguments to change the number of outlets: This challenge are two separate problems:
How to detect the number of arguments
How to change the number of outlets dynamically
Until recently there hasn't been a way proper way to detect the existence of arguments. Since Pd 0.50 there is [pdcontrol] which allows exactly this.
Using [initbang] here because [loadbang] would fire too late for creating the outlets.
The second part of the challenge may be solved either through a technique called 'dynamic patching' or by outputting a list instead of creating additional outlets. However with a list output you'd need to route it afterwards and then you'll arrive quickly at the patch pictured above.
I want to know if it's possible to make first two lines (Titles and horizontal line in the image below) always show on top and to be unclickable, to make them something like a header of the current listbox.
I think that your approach is not feasible since this is just not how listboxes work (i.e. it's not a spreadsheet where you fix the top rows). Having said that, you might be able to create something that looks like what you're suggesting, by creating two listboxes one below the other, making the top one read-only or non-interactable (or better yet, make the top one a static text label or a text area).
Another thing I'd like to comment about is the structure of your listbox. In terms of UX, it's uncommon for a user to choose two things at the same time. So even if this makes sense in your context, I would advise to split it into two lists, and have them change each other within callbacks.
I would like to present the user with a variable number of scenes within the GUI (arranged say horizontally) composing different views of the data, depending on runtime conditions?
I really don't want to redefine the GUI, and a number of scene related traits for every use case. (i.e. bool_scene_1_viewable=Bool(), bool_scene_2_viewable=Bool()... )
It looks like I might be able to define a wildcard trait: scene_=Instance(Scene,()). But, if this is the best way to do it, how would I go about combining n traits into a View?
(A) I did not distinguish between "runtime" dependence, and merely depending on some number of traits that are declared after initialization (but before config_traits is called). As such, I can use default_traits_view to create a view that depends on the current state of the object and its members.
(B) I was also confused about how to turn this list_of_scenes into an object that could be viewed. After all, HGroup and VGroup don't take lists! I was missing that * could be used to unpack the list.
Steps:
1. init class instance
foo=Foo()
add scenes as you like
foo.add_trait(string_scene_name,scene)
foo.scene_name_list.append(string_scene_name)
foo.scene_list.append(scene)
Create group within default_traits_view()
items=[Item(name,style='custom') for name in self. scene_name_list]
scene_group=Group( *items)
I use (current-window-configuration) to save the size, layout etc of windows, and (set-window-configuration ...) to restore them, so that I can toggle between several window setups. However (current-window-configuration) also saves the current point in buffers, and I would like to only save the window sizes and which buffers they hold. I have tried two different ways to make this happen:
According to the function help of current-window-configuration, the variable window-persistent-parameters controls whats get saved. So now I only need a list of the available window-parameters. But when I look at this variable it's value is ((clone-of . t)), and I can't find a list of the available window parameters online.
I also tried looking at the object returned by current-window-configuration. It is a window configuration object, and gets printed as #<window-configuration>. Is there a way to get into this object, see whats inside and change stuff?
The parameters for window-persistent-parameters may be found in this manual page, though it does not seem to help with your question. A different set of parameters may be found by running (window-state-get nil).
The functions that deal with objects returned by (current-window-configuration) are listed here, but it also mentions:
Other primitives to look inside of window configurations would make sense, but are not implemented because we did not need them. See the file winner.el for some more operations on windows configurations.
At any rate, all these look like really low level stuff, so you might be better off just using winner.el rather than a custom made solution.
I am using the publishing functionality of MATLAB to generate a quick report of some analysis I'm running. Since the analysis is quite time-consuming, I've added a progress bar to keep track of how long is remaining. The problem is that I'd prefer this progress bar not to appear in my report.
Is there a way to keep MATLAB from introducing some content in a published document. Or, alternatively, is there a way I can know I'm currently in publish mode, so I can skip the progress bar in those cases?
Edit:
There's a couple of solutions already, but I'd prefer something automatic that doesn't require an extra step in the workspace before publication. Any other tricks?
AFAIK there is no way of excluding parts from published document.
Perhaps what you can do is to output a unique pattern (BEGIN/END) around the progress bar code, which you will then parse the html file and remove those sections using some script.
I'm assuming you're using the WAITBAR function to generate a progress bar, and you have only one of these waitbars in your function.
Before you publish the file pre-create the waitbar:
h = waitbar(0);
Then make the waitbar invisible to the PUBLISH function:
set(h,'HandleVisibility','off')
Where you use the waitbar in your code, you have to specify that you want to reuse the hidden waitbar by referring to it again, with the handle, h:
waitbar(newPercentage,h);
see the function reference page for waitbar for more help.
Another slightly more generic option (inspired by Mike Katz' response), which works for any kind of content you don't want (or explicitly want) to include in your report.
in your module/function
try
inPublishMode = evalin('base', 'inPublish');
catch
inPublishMode = false;
end
You can now set the inPublish variable from the workspace before running your test, and wrap your optional code in conditional statements.
if inPublishMode
% do something
end
Still not perfectly satisfactory, but it's another tool in the bag.