When I hit MOD-p in XMonad, I used to get a list of commands. Now I just get an empty menu. If I type the name of an executable on my path and hit the carriage return, the command executes as expected. But why aren't any programs listed in the menu? Solution is posted below.
By default, XMonad maps MOD-p to dmenu_run. (You can see the default key bindings in the source code on github.) So I tried launching dmenu_run from the command line and saw the same behaviour; a blank menu that allows me to type the name of an executable in my path.
The problem was that the file ~/.cache/dmenu_run was empty. When I deleted this file and ran dmenu_run again, it worked perfectly (and created a new, non-empty ~/.cache/dmenu_run). I think the problem happened when I added a definition of $XDG_CACHE_HOME to my .zshrc file and the cache somehow got blanked out.
Related
The problem:
I'm currently working on a programming language, which uses a simple python interpreter. The interpreter loops over every line with a bunch of if-statements.
The file extension I'd like to use is .ccp.
So far my progress. I want the computer to recognise .ccp files as a CalcScript file, and open it with the script.
I don't want to have a default filename which I can open using text = open("filename.idk","r").read(), I want to open a file like a 'normal' file. You double-click on the file in explorer, and it opens it in the python script. Regardless of the filename.
What I've tried:
Tinkering with the default applications in settings
Tinkering in regedit
Converting my .py file to .exe
Scouering the internet
My code:
https://github.com/AnonymousPixel/CalcScript
Sorry for bad English if there was any.
Summarizing my comments on the question, you can follow the steps below to achieve what you are asking:
Use sys.argv to access the command line arguments. For example the following script will just print all the arguments given to it:
import sys
print("Given arguments: ", str(sys.argv))
Let's name it myprogram.py.
You can then call it (I think) with: python myprogram.py arg1 arg2 arg3 and it will run and print the command line arguments.
Notice that the first argument (sys.argv[0]) is the script's path. So arg1 would be sys.argv[1], arg2 would be sys.argv[2] and so on.
I am saying to use sys.argv because as far as I remember double clicking a file with an extension which has a default opening program, will open that program with the file path as an argument.
Next step is to package your python script to an executable. This has been already asked and answered for example here (which is a duplicate, where you can follow the question which came before it to see even more examples). I used PyInstaller to test it (and on Windows OS). My command was like:
pyinstaller myprogram.py
... and it generated some folders and files. Specifically the folder dist\myprogram contained the executable along with its dependencies. You can then run your program by double clicking on it in the dist\myprogram folder. It should pop a CLI window, printing the arguments (ie only the program's path, since we called it without any other) and immediately exit. Or you can open a CLI window and run it with a command like:
myprogram argument1 argument2 argumentN
(supposing your current working directory is dist\myprogram) and it will indeed print the arguments.
Finally you have to set it up as the program which by default opens files with .ccp extension. On Windows 10, you can do this via:
Open up File Explorer.
Find a file with .ccp extension (or create one).
Right click on it.
Click on Properties on the dialog that pops up.
Go to General tab (if you are not already there) on the dialog that pops up.
On the Open with: section there is a button which reads Change. Click it.
Select More apps at the bottom of the dialog.
Make sure you have the Always use this app to open .ccp files checkbox selected.
Scroll to the bottom of the dialog and click on the blue text which prompts for manually selecting the default app, which in turn pops up a file chooser. I am not running on English language so it is a bit difficult to translate it exactly (I followed some online pages to actually see the default translation for the previous steps).
Select your executable as the default.
Confirm your choices by selecting Ok, Apply or anything else required.
Then you will also be able I think to change this extention later via:
Settings --> Apps --> Default Apps --> Choose default apps by file type.
Some references:
PyInstaller website and introductory manual.
Official page for step 3.
Unofficial page for step 3, a lot more detailed.
A breakpoint in my Mocha test works when set on the exact same line in one VS Code tab but not in another.
The difference: If the full path appears in the tab, then breakpoints work. (Second item in screenshot.)
But if the filename, without path, appears in the tab header, then breakpoints all become Unverified (gray) during execution.
Repro steps:
If you open files from the Explorer view, the bug occurs.
If you open files using CTRL-P, as in the screenshot, then both
variants are usually available, and choosing the one with/without
path gives the different behaviors.
How can I avoid this without continually checking which path variant is appearing?
(Here is a GitHub ticket that I opened.)
Answer (figured out on the GitHub thread):
My workspace path was under a symbolic link (Ubuntu).
VS Code apparently dereferences symbolic links to give Node a path that it can work with, to support breakpoints.
VS Code also shows the file at the correctly referenced path in my workspace folder as I defined it (under the symbolic link).
I'm revisiting an old Chrome App project and have all the SDKs (Pepper 49) installed and Python etc.
My previous project folder is accepted by Chrome in Dev mode and runs.
However, I now need to add to the project and the build/make process is showing the error below:
The directory tree I used last has changed, which is why I've highlighted the full directory my project is in.
Is this as simple as Make.exe not supporting string gaps in the directory names? The error implies this could be the case.
That's a quoting problem. The spaces aren't quoted on the command line so they are being seen as significant by the shell and STAMPDIR is being set to only V:/Code while Repositories/BCS and Chrome/BCS are being seen as additional command line arguments to make and make assumes they are targets to build (and can't do so).
You'll need to quote the argument in the makefile so that it gets put on the command line correctly.
I just installed WinGHCi. When I try to load an .hs file with Ctrl+L, it opens the file browser in C:\Program Files (x86)\Haskell Platform\2012.2.0.0\winghci which is where I installed this. I don't want it to go there by default, I keep my code files in a different directory on a different drive and I don't want to have to navigate to D:\MyPath\Haskell every time I load a file.
I tried to set the "Start in" field of the shortcut I use to launch WinGHCi but it changed nothing.
How can I make WinGHCi look in my own directory by default?
It opens in the last directory you opened a .hs or .lhs from.
Try opening something from the folder you want, exit, restart.
Did it restart where you were?
Try working like that for a while, and if you like it (I do) then you're fine.
If you really do want to go to the same place every time, perhaps there's a way.
I can't find any setting to control this, but the information is stored in the registy.
Mine is at
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Haskell\WinGHCi 1.0.6]
"WorkingDir"="D:\\Files\\Andrew\\prog\\haskell"
You can save your version of that as resetghci.reg:
To make your own, open regedit and first try the same location. If not, search for WinGHCi.
You can export that subtree but you get the whole lot including recent expressions etc, which I don't think you should reset. Save that as ghcioriginal.reg just in case. Edit away all the lines except WorkingDir and save as resetghci.reg
When you double-click it it will ask you if you're sure you want to add that info to the registry. Yes you are.
Untested:
What follows works on older versions, but Microsoft seem to be going off .pif files and the start command, and I'm not able to test this in Windows 7.
Make a text file called ghci.bat in the same folder as the .reg you made. In it put
#echo off
regedit resetghci.reg
start WinGHCi
You might need to specify the full path to WinGHCi.
The start command is the windows equivalent of making a background process from a shell prompt, so this should terminate immediately.
Make a shortcut to ghci.bat (it will be called ghci.pif) and set it to open minimised and put a nice lambda icon on it (nick it from the winghci executable).
Pop that on your desktop, start menu or shortcut bar, and when you use it, you'll be popped back to your standard location.
I'm trying to get OmniCppcomplete to work and I'm running into trouble. I've followed the steps on this page (including the things to add to the .vimrc file). I downloaded and extracted the zip file to ~/.vim, I ran the commands it says, I did everything there and it still doesn't work. I also tried downloading the modified stl for the __STD_NAMESPACE_BEGIN fix. I ran ctags on the directory and placed the tags file in ~/.vim/tags/cpp.
Whenever I type a class name or namespace name followed by a . or :: or whatever, I only get an error saying Omni completion (^O^N^P) Pattern not found. I've run tselect TestClass to see that the tags were actually being generated and they are, so I'm at a loss as to what's happening.
I think I figured it out. I had been placing my tags in a directory called ~/.vim/tags/cpp/, rather than making a file called cpp and placing it in the tags directory. It seems to work now.