When I use ST build system, "built-in output pane" prints various things like expected build output, but also cmd executed, active dir and path variable. Now cmd and dir are just fine, but printing path variable is totally unnecessary for me and it distracts actual output content, as it's just very long string of paths, shadowing all other output.
How can I instruct ST not to print path variable on build?
By adding "quiet": true to the Build System configuration file (JSON), you can prevent all "debug text" from appearing on build failure. This will include:
shell_cmd
cmd
dir
path
To exclude only path, you would need to modify the Packages/Default/exec.py file. Under the ExecCommand class, run method, look for self.debug_text += "[path: " and comment the line out.
To get to this file in ST3, you can use PackageResourceViewer, and type PRV: in the Command Palette to find PackageResourceViewer: Open Resource.
However, note that doing this, will create a file that will override the one that ships with ST3. So it is recommended to delete your override (Preferences -> Browse Packages from the menu, Default folder, exec.py) when a new build of ST comes out, as the official version may change to fix bugs etc. You can then re-apply your changes following the same steps as above, if it is still necessary. (Maybe an option will be added to exclude the path from the output, sometime in the future.)
Related
I'm new to octave, and want to run a few commands on startup automatically every time it opens.
I typed "help startup" and saw "Octave uses the file ".octaverc". I did a bit of searching online at https://www.math.utah.edu/docs/info/octave_4.html, and saw the .octaverc file should be in the following path:
OCTAVE_HOME/lib/octave/VERSION/startup/octaverc
PROBLEM:
In that directory I don't have a startup folder, only "oct" and "site". I do see hidden files, which was my first thought since the file begins with "." character. So I then used Agent Ransack in the directory, and still nothing came up.
QUESTION:
1) Do I have to make the startup folder and octaverc file myself?
2) If so, does one, both or none have to be hidden?
3) Can it be a txt file, or does it have a special extension?
4) Do I just type the commands straight into the file or is there special formatting?
NOTE:
In case I'm going about this the wrong way, there are the operations I'd like to have run on startup:
PS1('>> '), addpath('D:\Users\Me\Desktop'), clc
Thanks ahead of time for the help!!
Possible locations (and their differences) for octaverc files are specified in the documentation.
In short, these are, from more general to specific:
octave-home/share/octave/site/m/startup/octaverc (most generic, for entire system)
octave-home/share/octave/version/m/startup/octaverc (to cover for more than one octave versions installed on the system, possibly requiring different startup scripts)
~/.octaverc (where ~ is unix-speak for a user's home directory -- covering for user-specific startup files)
.octaverc files in any directory, creating specific startup conditions for specific directories
octaverc files are effectively simple script files that are executed from most generic to most specific each time octave starts. Therefore, in the presence of conflicting commands, the more specific file can effectively be used to override the more generic behaviour.
Octave also supports (but does not recommend) the use of the startup.m file, for matlab compatibility.
You might also want to check out pathdef and savepath as well.
As a more general tip, if you ever want to search for a specific keyword from the documentation (e.g. octaverc), you can type this kind of search query in duckduckgo (or google):
octaverc site:https://octave.org/doc/interpreter/
(or just download the documentation as pdf and search the pdf)
Found the solution, the file was in the following path:
OCTAVE_HOME/share/octave/site/m/startup
to find out where OCTAVE_HOME is for you, just type "OCTAVE_HOME" into your Octave command line window.
ANSWERS:
1) You do not have to make a startup octaverc file yourself
2) The file is actually not hidden, so it should be easy to find given you're looking in the right place.
3) The file doesn't have an extension. It's just octaverc.
4) Under the last line of the existing file, you can just append commands as you would type them at the Octave command line window.
the last(7.3.0) octave version placed HERE:/ does not find the THERE:/openEMS/matlab directory even it is already loaded with octaverc or addpath. It keeps looking into the work dir where openEMS is not placed and does not recognize, for instance, the 'physical_constants.m' file.
I have a Nightwatch + BrowserStack configuration on my project and I'm trying to add custom commands to my project to compare 2 screenshots using resemble.js .
I configure my nightwatch.json file with this :
"custom_commands_path": "./node_modules/nightwatch/commands",
"custom_assertions_path": "./node_modules/nightwatch/assertions"
I put the commands file in the folder and I tried to run my test in every directory possible to see if it was a path problem. I've also tried with different commands, some of them I get online and even the default example one. Whatever I run it returns nameOfTheCommand is not a function. So I guess it does not even find the path to the customs commands in the nightwatch.json file.
Is there anything I'm missing here? I'm quite new so the answer could be very simple but I tried every .json file of my project in case there was a special configuration linked to BrowserStack.
Path to the custom commands should be analogous to the path to custom commands. You should point a folder where you added them.
I've found that if I put them in the suite configuration file, it picks them up:
nightwatch_config = {
src_folders: ["tests/suite/product/"],
page_objects_path: "pages/product",
custom_commands_path: "./custom_commands"
}
I am using HTMLPrettify with formatting set to "on save". Everytime I open and change the contents of a minified file, the package simply expands it and formats it the way it has to be, but that is not what I want. I want to exclude all files that have .min. in their extensions, so they can remain minified on save.
How can I do this?
SOLUTION: As MattDMo explained in his solution, there is no setting comming out of the box for this HTMLPrettify package.
There is no setting to do this. However, if you feel comfortable editing the plugin's code, you can do the following. Select Preferences → Browse Packages… to open your Packages folder in your operating system's file manager. Navigate to the HTMLPrettify folder and open HTMLPrettify.py in Sublime.
Go to line 22, which should be a comment on the very first line of the run method in the HtmlprettifyCommand class. Put your cursor just before the # symbol and hit Enter a few times to insert some blank lines. Then, go back to the very beginning of first blank line (not the indented beginning, the very beginning of the line) and insert the following code (the indentation should already be correct):
from os.path import split
try:
if ".min." in split(self.view.file_name())[1]:
return
except TypeError:
pass
Save the file, and the plugin should reload automatically. You can always restart Sublime to make sure. To explain the code: first we import os.path.split(), which separates the filename from the rest of the path. Next, we try to see if the string .min. is in the filename (os.path.split() returns a 2-part tuple containing the full path at the 0 index, and the filename at the 1 index). If it is, we return the method, ensuring that it does nothing else. If the string is not found, the code just continues on like normal. A TypeError exception may be raised by split() if self.view.file_name() doesn't contain anything, which would be the case if you're working in an unnamed buffer. If the TypeError does occur, we catch it and pass, as it means there is no .min. in the filename.
Warning
With this change, the plugin will no longer work on any minified file with .min. in the filename, even if you want to un-minify it. You'll either have to copy the contents to a blank buffer or rename the file first.
Good luck!
I want to set different hex file names for different configurations of a project. In detail I want to have a release configuration where compiler optimization is turned on and a debug configuration where optimization is turned off.
So far I have discovered the possibility to add a second configuration to the project, where I can set a different optimization level. The binary for the other configuration is automatically compiled to another directory but the name of the result hex file stays the same. I tried to change the macro "ImageName" under the "Building" options for the configuration but they are read only and the makefiles containing these macros seem to be automatically regenerated so manual changing is futile.
Is there any way to separate these two builds (one with optimization and one without) by name of the result file? I don't want to release a build without optimization by accident since this is really critical in my current project as I already have experienced.
Use the Execute this line after build option. It is right above the Macros section (Right Click > Properties > Conf:[name] > Building). Commands you type there will be inserted into the auto-generated makefile (nbproject/Makefile-$CONF.mk) and executed at the end of the build process.
Example:
To copy the output hex file to "out_dir" and tag it with the configuration, use this line:
${MKDIR} out_dir && ${CP} ${ImagePath} out_dir && ${MV} out_dir/${ImageName} out_dir/${ConfName}_${IMAGE_TYPE}.${OUTPUT_SUFFIX}
This line will create "out_dir/", copy the hexfile to the "out_dir" folder and then rename the hexfile to configuration-name_build-type.hex.
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.