Using VIM I want to execute current sql file and see results. I've tried the following (./manage.py dbshell is a Django wrapper over psql)
nmap <silent> <Leader>r :make<CR>
autocmd FileType sql set makeprg=cat\ %\\\|./manage.py\ dbshell
It works fine. But after Press ENTER or type command to continue VIM always shows me empty buffer (maybe it is error list). How to skip its opening?
If I run the same in command mode it will be as I've expected (without annoying buffers)
:!cat %|./manage.py dbshell
My SQL script contains a single select statement. And the magic buffer looks like:
It is likely to be wrong 'errorformat' option. Try doing
:make!
(with bang!) and see whether this window appears. If it does not, this is true and you should read :h 'errorformat' and also set it in addition to 'make'. Or just never use plain :make without bang and forget about jumping to errors (if that script is able to output information about errors).
Another idea: Could you show the output of
:au ShellCmdPost,QuickFixCmdPre,QuickFixCmdPost
? It may also be a problem of some plugin or vimrc code that is launched on one of these three events.
By the way, you have two things in commands you posted that may be improved. First, mapping should be written as nnoremap. You don’t need remapping here and it may save your time when you add some other mapping to your vimrc.
Second, use setlocal in autocmd, not set. With set you set default 'makeprg' for all buffers that will be opened after sql one.
Related
I tried pprofile to profile Python code line by line.
import pprofile
profiler = pprofile.Profile()
I printed the statistics to the Ipython console using
profiler.print_stats()
This works, however, the plotted table has a lot of rows and the upper part is cut away by IPython. Since those are the data I'm interested in I need to see those.
Is there any basic IPython setting that enlarges the number of rows to display?
Obviously the profiler.print_stats() command can't be modified to exclude unneeded data from being displayed.
There are other methods you could call instead of print_stats(), like
profiler.dump_stats(filename)
which dumps the same output to filename.
Or if you know the name of the file you are insterested in, you could call the method underlying dump_* methods:
profiler.annotate(sys.stdout, source_filename)
which dumps an annotated version of just given filename.
See the module/class documentation for more information:
help(pprofile)
Running some random code I found on the internet a few weeks ago has changed the pagesize and linesize defaults of my SAS output window. I don't remember what code it was though unfortunately. The current default pagesize is 15, which is generally way too small.
Does anyone know how to change the default?
I can change this using "options pagesize=80" or something but that only lasts for the current session. I can also change it in the GUI from Tools>Options>Output>Display but any changes won't save to my next session.
Any tips would be much appreciated! This is kind of excruciating. Thanks!
Your editor preferences are stored in a SAS catalog. Only 1 SAS session can open/write to this catalog at a single time. You can find out the location of the catalog that your SAS session is using by running this code:
proc options;run;
... And then search for SASUSER in the log.
If you launch SAS and it tries to use a SASUSER catalog that is already in use by another session, it will give you the message:
WARNING: Unable to copy SASUSER registry to WORK registry. Because of this,
WARNING: you will not see registry customizations during this session.
Are you seeing this message when you launch SAS? If so, it means that you have another instance of SAS open on your machine that has that catalog open. You have 2 options:
Close all instances of sas.exe on your machine (via task manager, be sure to check process names, not just the applications tab) then try making the change again.
Setup another shortcut to launch sas.exe. On this shortcut, specify a different SASUSER location like so:
sas.exe -SASUSER "d:\sas\profile2.cfg"
Also, I'm assuming you have the option to 'Save settings on exit' checked. Or if this isn't the case you can save your current settings by typing the command save into the command bar.
EDIT :
Some additional places to check that may override any profile settings:
Your sasv9.cfg file. Again, run proc options;run; and search for sasv9.cfg. It will give you the location of this file. If the file simply contains a list of other filenames, be sure to open up those 'included' files and check those.
Your autoexec file. If your SAS environment is specifying an autoexec file to load at launch, make sure it's not adjusting them there. Also if it is using an autoexec file, make sure you have all the loggin options turned on as the first thing that happens when SAS loads: option mprint notes source source2;.
Try right-clicking on SAS and choose 'Launch as Admininstrator'. If your profile is in a read-only location due to priveleges, perhaps your settings aren't being saved.
Look in your windows event log to see if SAS is loggin any errors there.
According to the SAS for Windows documentation, pagesize is controlled in part by the default printer. 15 is the minimum value, so it's possible that there is something wrong with your default printer and/or SAS is doing something odd (such as not finding one). If 'some random code' changed your default printer, you could simply try changing it back (see your SYSPRINT option).
I believe you can override this in your sasv9.cfg, commonly located in a path like C:\Program Files\SAS\SAS Foundation\9.4\nls\en\sasv9.cfg (varying based on what language version of SAS you use and your version, plus installation details), by simply adding -pagesize=80 or whatever you wish the default to be. You also can add options pagesize=80; to your autoexec.sas (or a new autoexec.sas if you don't have one already); see this paper or the documentation for more details on that.
I forgot to printto my log and it filled up. I tried to choose the 'save' option from the popup window. I entered a name+path for the log and it didn't accept it. I tried entering just a name and it accepted it, but I have no idea where it saved to.
I've searched around and found many answers on how to avoid this situation, but no answers on where the save option puts your log.
It is saved as a catalog entry in SASUSER.PROFILE with whatever name you gave it. FILE is the way to get it saved as a text file rather than a catalog entry.
Note, this only works if you have write access to SASUSER; if you regularly run SAS with rsasuser or if you share user profiles for whatever reason (or if you're running a second+ copy of the same SAS session), the save option will not work at all (and should give you an error).
You can also specify -altlog="<path to log>" on the SAS exe invocation/shortcut. This writes the entire session log to file as you go along.
Can anyone direct me to a tutorial on writing plugins for Jedit? I have a pipedream of using Jedit as an editor for SAS. Currently, it does syntax highlighting, but I feel it is or could be made better by fleshing out the ideas better.
A couple questions:
Can you enable tab completion in Jedit?
Can you specify "environments" that begin and end with certain syntax? (For instance, the word "keep" makes sense between the lines data xxx; and run; but not between proc sort data=xxx; and run; So highlighting it there would be counter-instructive to inexperienced coders.
Can you store variables in a work place and reference them from a drop down menu (such as variable names in a dataset)
Can you execute code from the shell/terminal and pipe .log files back into the Jedit message window?
Are you talking about something like Microsoft's Intellisense or autocomplete? If so, a poor-man's approximation to auto-complete is to use the keyboard shortcut ctrl+b after typing in part of the word. It will complete the word based on all the words from all buffers that are open. See this questions for more on autocomplete.
In your syntax highlighting, you can create delegate syntax for different chunks of code so that it will be highlighted according to different rules. grep in your jedit's mode directory for "delegate".
Not exactly sure what you want, but jedit does keep track of a bunch of your latest copies from the text. Emacs calls this a "kill ring". For my jedit setup, I have Paste Previous... bound to ctrl+e ctrl+v. I believe that is the default shortcut binding. This will show you your last ~20 copies of text chunks and you can select which copy text chunk you want to use.
Yes, you can execute tasks in the shell and pipe them back into jedit. See this question. The following is how I do bk edit and reload a buffer. It doesn't get output from the shell, but it does execute a shell command:
import javax.swing.JOptionPane;
import java.io.File;
File f = new File(buffer.getPath());
String SCCS_path = f.getParent()+"/SCCS";
String bk_path = "/usr/local/bin/bk";
if ( !new File(SCCS_path).exists()) {
bk_path = "/usr/bin/bk";
}
Runtime.getRuntime().exec(
bk_path+ " edit "+
buffer.getPath());
Thread.currentThread().sleep(2000);
buffer.reload(view);
Btw, macros are very powerful in jedit. You can record what you are doing in jedit with Macros->Record Macro...and it will generate the equivalent script.
Attempting to submit a changelist with no files is considered by Perforce to be an error (p4 submit ... returns exit code 1). This causes a periodic integration build to fail on our build server (we're using Zutubi's Pulse system); in this case I would rather have the build succeed, possibly with a warning.
Pulse has exit code remapping functionality, but Perforce does not appear to disambiguate between a failure to submit an empty changelist and any other submit failure (such a validation trigger failure, which I do want to fail the build).
The immediately obvious (but, in my mind, inelegant) solution that comes to mind is to wrap execution of p4 submit in a batch file that first checks to see if the target changelist is empty by counting lines of output from p4 opened -- or just parsing the output of p4 submit for the "no files" message and returning successfully from the batch file.
Are there better techniques for handling this that I'm not seeing?
Before attempting to submit a changelist, you could first attempt to delete it.
p4 change -d ###
This operation will only succeed if the changelist is empty, so don't submit it (you have just deleted it). If it fails, there are files in the changelist, so go ahead and submit them.
However, if you use jobs, this won't work for you because you can't delete a changelist that has a job attached to it, even if it's empty.
There are probably no good techniques just with Perforce, if I am understanding your problem correctly. The issue, as you have seen, is that the return codes from perforce command line runs are, well, ambiguous. Is a submission of an empty changelist really an error? Maybe, maybe not - might depend on who you ask.
It's is not really that advisable to look at return codes from 'p4' commands. Your best bet as you have suggested is to parse the output of the command and then do what you need to from there.
Most commands now support the -ztag option (see 'p4 help usage'), which will could make parsing the output a bit easier, depending on what you want to do. If your case, it is probably sufficient enough to just look for the text in the output and then decide what to do from there.
I did ultimately end up parsing the output in a batch file, using something like this:
for /f "delims=" %%I in ('p4 submit -d "<message>" 2^>^&1 1^>NUL') do
set SUBMIT_OUTPUT=%%I
if "%SUBMIT_OUTPUT%"=="No files to submit from the default changelist." exit /b 0
This is necessary since p4's "no files" message is actually writting to stderr normally. If the output is the message I consider "safe" I exit with a zero exit code, otherwise the script will continue with whatever error level was set by the p4 command.
Note that the "no files" message for a numbered changelist is slightly different, if you're using that.