Lets say you are debugging a make file and you only want to run the second half.
So, for example, you do not have code to make the file: vertex.cpp (you have commented this out in the code, but indeed vertext.cpp does exist in the directory). But vertex.cpp is required for targets to be built downstream.
How would you go about running the make file in those conditions?
Related
My goal is to be able to reasonably debug any R-based code, even code from libraries (from install.packages, by placing breakpoints or debug statements (i.e., browser) at any line. I haven't been able to figure out how to reliably edit the source of any library function yet (assuming it is not compiled, e.g., editing a S3 method). However, I put a breakpoint in my main function and then used the debugger to step into the code for the library of interest. In RStudio, the file says "Debug location is approximate because the source is not available." That's fine, but I would like to be able to put additional breakpoints into this "virtual file" so that I don't have to step line by line until I get to the line of interest. Placing these breakpoints does not seem to be possible.
I also can't figure out how to edit the file (which would presumably then support breakpoints). Perhaps I need to install the source locally but it is not clear how to do that. Also, I don't know what the implications of using the source code is. Would I need to manually compile any parts of the library that are actually compiled? My preference would be to have an installation option that allows for editing anything that is interpreted but that doesn't force me to compile everything that the standard installation method typically compiles on its own.
Try:
trace(Fun_name, edit = T)
I've written an Extension that, among many other things, renames files based on the Types they contain.
This works fine for files in the directory-tree under the csproj-file -- I find the ProjectItem entry for the file and change its name.
For 'linked'-files (those not in the directory-tree) I can rename the file (via File.Move()) but haven't found a way to programatically modify the csproj-file (after the rename the csproj-file has to be modified manually).
If this is something that can be done I'd appreciate a pointer to the docs showing how to implement the functionality.
The easiest solution for me was to modify the csproj-file.
Open, read whole file, close.
Verify that file I want to rename (e.g. xxx.cs) only occurs in 1 directory
(if it occurs in multiple directories the change has to be done manually.)
Make change
Open, write whole file, close
For an SDK project the change is applied immediately.
For a non-SDK project the change is applied after responding to the prompt that the csproj-file has been modified.
I recently have encountered an issue in debugging package code in RStudio. Suppose I have a function in source file, say foo.R, and set a breakpoint in the body of that function. Then when I run something in the console that reaches that breakpoint, a second copy of foo.R shows up in the code panel, and it pops to the foreground. The line where I had set the breakpoint is highlighted in the new view, but the red dot shows up in the first copy. This is driving me crazy because it happens with every single source file and makes a mess out of my code window.
Moreover, if I make changes in the first copy of the file, rebuild, and don't close the debug copy, then the changes are not shown in the debug copy if I still have active breakpoints. This is very confusing.
Here's an illustration of what I see after I entered a call. The first version of the file has the red dot; and you can see the tab for the second copy:
The second copy of the file is where debugging is displayed:
And this is what I had entered in the console:
I had the idea that this might v\have something to do with its immediately going from Browse[1] to Browse[2]. However, I tried debuggingState(on = FALSE) and that doesn't make a difference.
This is not a bug I am able to reproduce. If I switch to a different project, this doesn't happen. It's apparently some setting in my project that got messed-up.
I figured this out. My setup maps a drive letter H: to a path I treat as my home directory. That means there are two different versions of the file path for any file in that mapped directory. The duplicate files were created in the other version of its path. I re-loaded the project from the path it wanted to use, and that solves the problem!
When I synthesize a design using Xilinx ISE, the output file is named untitled.mcs. I would like to configure the project to use an output filename more appropriate to the project I am synthesizing.
I have examined all the properties easily reachable by right clicking the the implementation panel in the tool, but I can't find a configuration option to change output file names. I have also searched the help, but couldn't find anything useful. Can anyone suggest where I need to configure the output filename or tell me where or what to search?
I am aware of at least two things I could be doing wrong and would appreciate comments. First, I am not using TCL to synthesize my project. I just right click in the implementation panel and choose run. Perhaps if I create a TCL script to I would have finer control or output file naming. Second, I can see several files named untitled.x where x is [cfi|mcs|prm|sig]. I guess these are a sequence of files processed from one format to another, and if I understood the process, I could configure the name of the first and see all the derived files change their names to follow.
The answer to my question is that you don't use ISE to configure output PROM file names, you do it in the iMPACT tool. When it is properly configured, ISE will run iMPACT to create the programming file.
If anyone needs the precise details on configuring iMPACT, the built in help has the details. See the section entitled "Creating Xilinx Flash/PROM Files". During the setup of the programming file, you get to choose the output file name.
One extra pointer from me: The help says you double click to open a wizard. For me that didn't work, but there is an icon (or tool bar button) to launch the PROM file formatter wizard when Create PROM File is highlighted in the iMPACT Flows panel.
When you have created an saved an iMPACT project file, you select it in ISE and ISE will create a PROM programming file at the last step of the synthesize process.
I have an unusual environment in a project where I have many files that are each independent standalone scripts. All of the code required by the script must be in the one file and I can't reference outside files with includes etc.
There is a common function in all of these files that does authorization that is the last function in each file. If this function changes at all (as it does now and then) it has to changed in all the files and there are plenty of them.
Initially I was thinking of keeping the authorization function in a separate file and running a batch process that produced the final files by combining the auth file with each of the others. However, this is extremely cumbersome when debugging because the auth function needs to be in the main file for this purpose. So I'd always be testing and debugging in the folder with the combined file and then have to copy changes back to the uncombined files.
Can anyone think of a way to solve this problem? i.e. maintain an identical fragment of code in multiple files.
I'm not sure what you mean by "the auth function needs to be in the main file for this purpose", but a typical Unix solution might be to use make(1) and cpp(1) here.
Not sure what environment/editor your using but one thing you can do is to use prebuild events. create a start-tag/end-tag which defines the import region, and then in the prebuild event copy the common code between the tags and then compile...
//$start-tag-common-auth
..... code here .....
//$end-tag-common-auth
In your prebuild event just find those tags, and replace them with the import code and then finish compiling.
VS supports pre-post build events which can call external processes, but do not directly interact with the environment (like batch files or scripts).
Instead of keeping the authentication code in a separate file, designate one of your existing scripts as the primary or master script. Use this one to edit/debug/work on the authentication code. Then add a build/batch process like you are talking about that copies the authentication code from the master script into all of the other scripts.
That way you can still debug and work with the master script at any time, you don't have to worry about one more file, and your build/deploy process keeps everything in sync.
You can use a technique like #Priyank Bolia suggested to make it easy to find/replace the required bit of code.
I ugly way I can think of:
have the original code in all the files, and surround it with markers like:
///To be replaced automatically by the build process to the latest code
String str = "my code copy that can be old";
///Marker end.
This code block can be replaced automatically by the build process, from one common code file.