Before I started, I want to make it clear that the 'debugging' here I mean is for programming debugging, while not vagrant itself debugging.
We all know, Vagrant is great to maintain a solid devlopment evnrionment among a team, and also tons of benefits from it as stated all over Vagrantup.com.
My question is: For instance of python programming, how can I keep using my favorite debugging tools coming along with Pycharm on Windows, but the python dependencies are installed in the Vagrant virtual machines?
I can easily do the deployment and testing with Vagrant command line, but I still can not get the point of how to enhance the developing stage, especially debugging on the development machine (Windows here).
As you have quoted Python and PyCharm as the language and IDE, I will build on the same example. PyCharm supports a feature called Remote Debugging, but this is available only on the professional edition of pycharm. Pycharm has documentation on setting up of a remote debugger. I am quoting the answer from this SO Post. To consolidate the steps required
Upload & install remote debugging helper egg on the remote server that is to be debugged (vagrant machine)
Setup remote debug server run configuration: click on the drop-down run configuration menu, select Edit configurations, Click on the + button, choose Python remote debug.
set Local host name to your laptop's IP address, set port to any free port that you can use on your laptop (e.g. 8888)
Now follow the remaining instructions in that dialog box: copy-paste the import and pydevd.settrace(...) statements into your code, specifically where you want your code to "hit a breakpoint". This is basically the PyCharm equivalent of import pdb; pdb.set_trace(). Make sure the changed code is sync'ed to your server.
Hit the bug button (next to play; this starts the PyCharm debug server), and run your Python script just like you'd normally do, under whatever user, environment etc. When the breakpoint is hit, PyCharm should drop into debug mode.
Related
When vscode remotely debugs the machine learning code, it will get stuck. I will choose to disconnect, I want to know why it is stuck
I is not only about vscode all are coding languages debug to machine language to work your code in your laptop or smartphone or desktop. You need to start your remote debugger after configure remote debugging to configure the firewall. When configuration is complete the remote debugger window appears. Then you can use the server name and port number shown to set the remote connection.
vscode remote development allows you to use container, remote machine or windows subsystem.
I've got 2 stations, one for development and another one for testing. I'd like to be able to run and debug targets that were built under release mode (the code is stripped) on the testing station.
Since the code may not be copied to the testing station for security reasons, I've tried remote debugging as described in the following link - http://lldb.llvm.org/remote.html.
Since both sides of the debugging runs OS X, the settings instructions specify that my local (development) station should run 'lldb-server' along with 'debugserver', and remote (testing) side should run 'platform'.
Unfortunately, I couldn't find all those tools inside the Xcode bundle. I also tried to download lldb source code and create those executable by myself, but I'm still missing the lldb-server target.
I wish I had some clear and comprehensive guide about how to do lldb remote debugging properly from A to Z.
Make sure that Xcode is installed on both machines. (Different versions are OK!)
On the remote machine (running the executable):
Start the app you want to debug
Start debugserver, attach to your app, and listen for connections from the other Mac:
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver development-mac.local:16000 --attach="Photo Booth"
On the development machine:
Start lldb by typing lldb
Connect to the debug server:
process connect connect://test-mac.local:16000
On the test machine, you should now see the message Waiting for debugger instructions for process 0. After a short while, the (lldb) prompt should appear on your development machine, and you can start debugging as normal.
Unfortunatly, I'm not sure how to connect from Xcode.
Please give feedback for Apple to update their documentation here
In the mean time, I'm getting more milage using hopperapp with app disassembly. http://hopperapp.com/ There's a free trial - and it has a remote debugger available.
I'm trying to automate the provisioning of our developer workspaces which are based on Linux running in a Virtualbox. We also run the IDE inside the Virtualbox. The host system is Windows 7.
The new solution will install the required dependencies (C libraries) and install + pre-configure the IDE (plugins, code formater).
I'm wondering if Vagrant would be the tool of choice for this task. I am irritated since the Vagrant philosophy seems to be: easy provisioning of a dev/test server but running the IDE on the host - not inside the guest. The latter is not an option for us.
What tooling would you recommend for our purposes?
This is the answer to my question. I eventually went for Vagrant.
This simple switch let the normally hidden Virtualbox GUI appear:
v.gui = true
More details here: https://docs.vagrantup.com/v2/virtualbox/configuration.html
My experience with the solution was generally ok. I got my recipes version controlled as wanted. However, the feedback loop was quite long. To build the box with all my customization it took me about 7 minutes which was usually wasted waiting time. When changing a little bit I could try to execute just the changed scripts but to see the whole thing I had to rebuild the box - another 7 minutes wasted waiting.
I am currently trying to understand how in the world of infrastructure as code you still get acceptable feedback loop (let's say below one minute). I assume this is where you enter the world of configuration management with tools like Ansible or Puppet.
I've got a Windows 7 machine set up on Paralells.
Everything is working fine. Can access internet from IE or other browsers on my Parallels.
However, when trying to debug a web application in Visual Studio 2010 (by pressing F5 for example) then my default browser in OSX launches, which is great, with localhost:4243 (or whatever port Cassini has allocated on my vm)
Naturally, this doesn't find anything...
What do I need to do to either my parallels vm, or the settings on OSX to get debugging working? ie- my mac talking to the vm?
Make sure you are on the same network.
Use IIS.
Like so:
Your Win-machine has a name, let's say it's called "myWin7machine". Change "localhost:4243" to "myWin7machine:4243" in the browser.
If this doesn't work (well... it shouldn't) you might have the firewall on or the network not bridged. Let's start with the bridging.
Time to check some basics - be on the same network
Check your IP address. It's "ipconfig" on the Win machine and "ifconfig" on the mac; both run from the command prompt. The IP address should be something like 10.4.... or 192.168... on both. The important thing is that only the last number is different. (this is technically not correct but works for 99% of the cases) If they are equal (except the last) you are bridged - which means both machines are on the same network. If they differ too much you had running the Win machine's network "inside" the Mac's. Go to the settings for Parallels (in windows: move your mouse to the top to show Parallel's menu and go to Devices->Network and something "(bridged)". Wait until the balloons disappear and check ipconfig again.
Check that you can ping the Win machine from the Mac. Ping functionality might be turned off in the Win machine but probably isn't.
Now we know we are on the same network.
Still doesn't work
Can you do http://myWin7machine:4243 from the mac? Well.. you shouldn't be able to.
Can you do it from the Win machine? You should.
IIRC Cassini doesn't talk to strangers. I.e. it doesn't talk to anything but localhost.
If I am wrong - just open port 4243 in the firewall on the win machine and you should be good to go.
But otherwise...
Time to change web server.
Install IIS on the win machine.
In the Mac: surf to http://myWin7machine and see the IIS7 logo show.
If you don't you have a firewall issue. Open port 80. Try again.
If you have come this far then you can surf from the Mac to the IIS on the Win machine.
Time to set up your VS solution
Open the IIS admin GUI. Create a new Site. Let's say you call it MyTestSite. (you can always rename it later) Point it to your VS solution's web. Typically the same folder as web.config resides in. On the win machine: try surfing to "http://localhost/MyTestSite". Your site should show up. You might get an Apppool error.
Now try http://myWin7machine/MyTestSite on the Mac. It should work.
ROCK!
Time to set up debugging in VS
For debugging in IIS you have to connect to the process. In Win7 it requires elevated privileges so either you restart VS as admin or you try to connect and VS will do it for you.
The menu in VS is Debug->Attach to process and you choose w3wp.exe.
This is how you debug faster anyway - by connecting. Restarting your web for every debugging session is a waste of time.
To make connecting faster - use ctrl-alt-p and the continue with using the keyboard.
To make connecting even faster use a macro.
There is more info in these 4 articles: http://www.selfelected.com/tag/iis/
Set a breakpoint. Refresh your browser and the breakpoint should be hit.
Time to hack some code
Good luck!
I'm using Windows 10, VS 2015, Parallels 11 on iMac with OS X El Capitan (10.11.5). The following are the steps that worked for me:
On Windows side:
Get the IP (run ipconfig command in command window)
Get the host name (run hostname command in command window)
In control panel look for Windows Firewall -> Advanced Settings and add a new inbound rule and a new outbound rule. For both make sure you select Port, Allow Connection, TCP and specific IPs. I added a range of IPs 45000 - 45999 but you can select the range you like.
In Visual Studio:
Look for project properties and under web section change Server settings to look something like this.
Instead of "winmac" you will use the host name found in "Windows Side - Step 2". The port can be any number inside the range you setup for your firewall rules.
On Mac OS side:
Update /etc/hosts file. At the end of the file add the IP and host name that we found on steps 1 and 2 of the "Windows side" section. When you finish this step the file should like something similar to this.
Ready to debug:
Now you can start debugging in your Mac from Visual Studio. Make sure that before start the debugging process you select "Open In Mac" option (instead of Chrome or IE in your debugging options in visual studio).
I have program that I want to test on clean Windows installation. For now I have image in VirtualBox and I start program from shared folder, but this is not comfortable and I can't debug.
For debugging I found that I can use Remote Debugging Monitor, but still I want to automate whole process, especially uploading application on virtual machine.
I thought that VirtualPC would be better then VirtualBox, because this application was created by Microsoft. Unfortunately I can't find any info how to connect them.
EDIT:
After research: only possibility is to treat virtual machine as remote computer. There is no easier way. Project need to be published to VM using shared folders. After configuring in Visual Studion new release type for remote debugging all triggers automaticly and working.
I would:
1.Place the program in a pre-defined shared directory, such that it is immediately visible to the virtual machine after redeployment.
2.Remote debugger invokation can be automated - all the parameters, such as users allowed to debug can be passed on the command line.
VirtualBox is quite OK for this task, as it allows you to replace only the disk image with clean one, while leaving the setup, including shared directories intact. I am sure VirtualPC also allows such a thing, but choosing it just because it's also written by Microsoft does not seem like a valid consideration here.