The commands in ~/.lldbinit that gets imported before each debugging session.
I have a bunch of command script imports in the ~/.lldbinit file.
At some point I don't want those commands. Is this possible while continuing the same debugging session?
That wasn't possible till quite recently. In the current TOT version of lldb you can put commands into "containers" - in the same way built-in commands like process launch etc. can. That's reduces the motivation to remove the commands, since they don't clutter up the command namespace. The new feature allows you to delete parts of your container hierarchy as well. I don't think this has made it to the major distro's yet, however.
The new command that does this is command container.
Related
Let's say I have a bunch of conda virtual envs and a much larger bunch of python projects.
Most of the time I reuse the same conda virtual env for multiple projects, because the environments are relatively widely scoped (e.g.: one for Spark, one for deep learning, one for data exploration, etc...).
When inside the directory of a project, I would like to be able to run conda activate and have the virtual env that I used to work on that project to automatically activate, without having to specify which one.
The reason for this is that with dozens of different projects, sometimes I forget which env belongs to which specific one.
I know that I can create the virtual environment inside the project directory, but it's a non solution for me, as I would end up having multiple clones of the same environment everywhere in my system, which is pretty redundant.
Any idea besides having a readme.MD that says "Activate THIS specific env" ?
It kind of depends on the nature of your projects and how you interact with them. For example, IDE's, like PyCharm, let you set an interpreter on a per project basis, which sounds like exactly what you want. For those working in Jupyter, each notebook stores the kernel information, but I don't know of a way to set a default kernel within a folder such that every notebook file opens to that.
As for the BASH script suggestion, that should work with a simple script like
activate_conda_env.sh
conda activate envname
but note that one has to source it in the current shell
source activate_conda_env.sh
for it to work as intended. Otherwise, doing bash -l activate_conda_env.sh would simply launch a subprocess, run the activate in there, and then exit the subprocess, having no effect on the current shell process.
Admittedly, this isn't very automated. However, one can set up scripts to run whenever a particular pattern of directory is entered, some tricks for which can be found in this thread.
I am currently trying to make a script that will take any number of arguments and create files for them. I have some registers saved in vi that I already have loaded with generic things I want in each file type.
So, I know that my shell can enter a file by typing vi "filename" but I am wondering if there is a way I could execute a register and then close the file, I suppose I could use my shell to append things I want to but it seems much more tedious which I am happy to do if you guys don't have any hints.
P.S. I have been looking online for way to open multiple tabs in the same terminal with only having generic Ubuntu without having to open a new terminal. But I think the only way to make this possibly happen is through programs I have to install, correct? Thank you for your time.
If you're trying to open files in an already-open execution of vim, then I think that'd have to be two processes:
outside process: to create the files (the one you planned to create)
inside process: (in your already opened vim) to load newly-appeared files (eg: like an automated :e new/file.txt)
wrt your PS: multiple files (buffers) is doable by default; a quickstart:
you can watch or read this screencast more about "buffers"
definitely shouldn't need new software
try this out yourself: vim ./foo ./bar (in a terminal)
:ls to see buffers you've opened (you'll see "foo" and "bar)
:buffer N to jump to one of said buffers
wrt "tabs" -- is that so that you can click? If so, maybe reconsider using vi (but if you're sticking to vi: you can find documentation to get tab-like UI if you really want, and again: no extra software).
I'm working on a plugin for a very niche CAD application that our company uses. The development environment is entirely based on Emacs and everything should be done through it.
In this case, code should be edited, navigated, compiled and debugged using Emacs. There is no separation from Emacs and the actual language compiler (from what we know so far - there is no compiler.exe).
Since my team is not a fan of Emacs we are trying to get rid of this dependency so we can use whatever editor we want an compile/interact with the application without Emacs, but looks like this is very hard because everything is built inside it, even go-to definition, find all references all and sorts of commands.
These are all defined in hundreds of .el files (LISP) that are called using custom commands from Emacs.
However, when calling "Run this file" for example, said file is ran inside the application and correctly executed so my question is: what mechanisms could be used used for this to happen? I don't expect precise answers as I can't share the name of the actual CAD application or anything else, but it would be really helpful to understand what options are possible so I can investigate them.
In summary, whenever I "Run this file" the actual application is started by Emacs by calling the command line and the actual file gets executed inside the application. Looks like the contents of the Emacs buffer are passed to the application somehow. This "how" is what I'm trying to find.
Thanks for any help.
I work on software that requires access to DLLs, usually wants environment variables set a certain way, and can take command line parameters. I'm generally opposed to setting/modifying system-wide environment variables for the purpose of launching these apps, since I might want to use different dependencies (different dlls), etc. and I don't want to accidentally get the wrong DLL loaded.
Up until now, I've been generating the visual studio .vcproj.user files and matching batch files from cmake ( see here for my script ) that extends the path to include the path to my dlls, sets any other environment variables as needed, and launches the application, forwarding all the command line arguments. (I do the same on Linux, but it's simpler because of RPATH). When we want to launch with a command line argument that wasn't just a file we could drop on the batch file, what we did is copy the batch file and edit the command to add our argument. (It's all GUI applications, but config files/flags can be passed on the command line)
This has become quite a hassle for me and my colleagues, and we end up with a ton of batch files, named similarly and difficult to maintain. It's not really a great interface for starting but there's a lot of apps we either use or develop that are like this, so it's a common task.
My question is this: I'd like a nicer way to configure dynamic library search paths, process-local environment variables, working directory, executable, and arguments for starting a program than hand-editing a batch file every time. I've done some digging to try to find one, but haven't been successful - "launcher" tends to bring me to "search-as-you-type" tools for frequently-used apps, and "command line argument" tends to find recommendations to use batch files. (It's not a windows-specific issue, either, but the dynamic library path stuff is less problematic during the code/compile/run cycle)
I've made a quick mockup of what I'm envisioning: it seems like the kind of thing that has to exist somewhere. Do you know of a tool similar to this (preferably cross-platform, and open source is even better)? It doesn't need all bells and whistles I put in the mockup, but that's what I'd build if I had time to build it myself. Thanks!
I have an automated build process that runs when no one in is in the office, and it pushes builds, deploys IIS web sites, and various other tasks. The problem is that if someone leaves a file open in one of these applications (like say they were looking at the web.config in a text editor), the build fails because it can't delete the files. I've seen people propose a solution as using Unlocker to release the file handles, but I don't want an interactive program - I want a command line application that I can call from the build process to release any open handles in the directory automatically.
Microsoft provide handle.exe which is a command-line tool. You'd need to do some ninja parsing to interpret the output, though. Also be aware that forcing a handle closed can have very unwelcome side-effects, it might actually be safer to kill the offending process.
Build from a separate copy of the source code. Leave the original copy for developers to inspect.