I put in ~/.gdbinit
set logging on
set logging file /mnt/gdb_log.txt
But gdb doesn't save log to this file
Why is that ?
Why is that ?
Because set logging file will only take effect next time you set logging on.
The order of the two statements matters; you should reverse the two lines you have.
As-is, the logging is happening, but to $CWD/gdb.txt file, not the one you specified.
Related
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.
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.
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.
Is there a way to somehow trace importing of the views ? I want to find which one is broken and doesn't import in some situations (which leads to the fact that all url resolving schema in django stops working).
Pretty amazing that no one has suggested pdb. Place the following in a strategic point in your code:
import pdb;pdb.set_trace()
When execution reaches that point, the dev server will drop into a shell where you can check values of variables, trace the execution, etc.
It works like a standard shell (use any python commands you like), but there's also special commands that let you control the execution. For example next will go to the next line (processing the previous line). continue will continue execution until the next break point, etc. (full list of pdb commands)
Don't you get a stack trace? Is DEBUG set to True?
Ok, well it's possible to just write
python -v manage.py <whatevercommand>
and search for the error in the produced logs.
I'm assuming this means you're getting a 501 server error?
If you're using the Apache web server, you can set it to log python errors in the config for the site using the ErrorLog directive:
ErrorLog /tmp/django_errors.log
Then in the terminal (or via ssh):
tail -f /tmp/djanogo_errors.log
And then try to load the webpage in question. You should then be able to see what the error is and fix it.