I'm fairly new to OSX development. I'm currently writing an app which has its own (cross-platform) custom XML-based file type.
I want to write a quick look plugin so that things look good in the finder, and have found the tutorial on how this is supposed to work, but apparently I must be doing something wrong since I see in /var/log/system.log that I get a segfault when my Quick Look plugin is ran. I'd like to see where it's crashing, but I can't for the life of me figure out how to do that.
Where does OSX store core dumps (if it even does that)? Do I need to set some system option or something to enable that?
How do I get Xcode to look at these core dumps?
I'm lost.
EDIT SIP prevents you from debugging protected processes. Because of that, it is currently (at least since SIP was introduced, through Mojave) impossible to debug QuickLook plugins without turning off SIP, at least partially.
As you've probably discovered, since your QuickLook plugin is a plug-in instead of a standalone executable, you need to debug the process that hosts the plugin. To do that, you can hook yourself to the qlmanage executable.
The first step is to make your .qlgenerator plugin available to the Quick Look server. To do that, you need to copy it to ~/Library/QuickLook and run qlmanage -r. The first can be implemented as a post-build action, the second has to be specified in the debug options.
For the post-build action, you should follow these steps:
hit Alt+Cmd+R to open the run configuration window;
unfold the "Build" tab on the left and go to post-actions;
click the plus at the bottom of the window and select "New Run Script Action", and use the following code.
absolutely ensure the "Provide build settings from" is set to your QuickLook extension target.
rm -Rf "~/Library/QuickLook/$FULL_PRODUCT_NAME"
cp -R "$BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME" ~/Library/QuickLook
qlmanage -r
Then, you need to configure Xcode to launch qlmanage:
in the same window, go to the "Run" tab, and select "Info";
in the executable drop-down menu, pick "Other...";
hit Shift+Cmd+G to enter a path, put in "/usr/bin/qlmanage", and select that file;
check "Debug executable" if it isn't already;
move to the "Arguments" tab, add a "-p" argument, and then add arguments as you see fit for the files that you need to preview.
Now, when you use the Run action, you'll be able to debug your plugin through qlmanage.
I haven't tried this personally, but this page:
Debugging Quicklook Plugin in Xcode 4.6
has a description of how to debug your plugin in Xcode 4 - 6. That will probably be much more useful than trying to grub through the core file after the fact.
Related
IntelliJ IDEA 2020 can (finally!) simply open a file to be edited, without a project being involved. This is called LightEdit mode.
At this point in a JetBrains video, we see the host platform's file manager app opening a file via IntelliJ while noting that all such files should be opened using that same tool.
No "IntelliJ" application to choose
The problem for me is that I am a happy user of JetBrains Toolbox app to automatically install, upgrade, and open IntelliJ. So in my "Applications" folder on macOS, I have no "IntelliJ" application to choose in the Mac Finder when trying to open a file.
Is there some other way or trick to getting the Finder to know to open files with IntelliJ? And preferably with the latest version, as I believe Toolbox may keep around the older versions.
Basically, I am asking the same as this Question, How to make available “open this project in IntelliJ IDEA” option in Windows context menu, if IntelliJ IDEA has been installed via JetBrains Toolbox?, but for macOS instead of MS Windows. The Answer on that other Question is Windows-specific.
As a Toolbox user you still have access to the "generated shell scripts" (/usr/local/bin/idea, or things like /usr/local/bin/phpstorm, /usr/local/bin/pycharm, etc for individual applications).
But, these are shell scripts, and cannot be used for this because they lack the application identifiers needed by the OS for launching apps.
What you can do is wrap any of this with an Automator application. By wrapping the shell script directly, it should remain updated (since the shell script is itself a Toolbox generated wrapper that points to the latest installed version).
To do so:
Open Automator and click on the "new document" button.
Select "Application".
Add a "Run shell script" action from the library:
Change the "pass input" dropdown from "to stdin" to "as arguments".
Create a script similar to this this (replace phpstorm with idea or whatever IDE you have installed):
for file in "$#"
do
/usr/local/bin/phpstorm -e "$file"
done
Save the application somwhere, with a descriptive name:
Once that one is saved, you'll be able to use it to launch files from Finder, or even set it as default for a file type:
Use the app's menu: IntelliJ IDEA -> Preferences -> Editor -> File Types
Then press the Associate File Types with IntelliJ IDEA button.
A window will open with file groups you could choose from, and then press the OK button, then Apply and another OK.
After this, a MacOS restart is required.
I am trying out GoLand and hear that the debugger is supposedly awesome, but I can’t find any documentation explaining how to set it up (GoLand is in preview stage, so that’s not really surprising). My use case: I am writing a REST API to which I send requests using curl. Could someone please tell me, step by step, how to get started with the debugger ?
[edit 1] (moved from comment) When I click Run/Debug (or Run/Run), a window is displayed, asking me to edit configurations. I am given a choice of several kinds of configurations, I try to choose "Go application" but the Debug button never is grayed and I can't get it to become clickable. I am very new to GoLand, I may be missing something obvious, but I can’t find whatever settings are missing.
[edit 2] It turns out that my workspace did not conform to the Go specifications : my code was not in a directory named src. Now that it is the case, I can click Run/Debug and GoLand seems to be doing the right thing, except it doesn’t stop at breakpoints or otherwise behave like a debugger, my code just runs.
[edit 3] Tried again, and it works. Sort of. I have no idea why it works now, even though it didn’t previously and I didn’t change anything. Now breakpoints work at some lines, and not at others. Or the debugger stops at the breakpoint, but I wait forever for the list of variables to be loaded. Well, it is a preview, after all...
[edit 4] I was notified just today that a new version of GoLand was available. I upgraded, and debugging is working well for me now.
GoLand will not enable the debug action (although run is available) if your code does not reside inside src. There is no warning about this, so it might be really a pain to solve this.
Additionally, depending on your project’s structure it might be possible, that debugging is still not working. In that case, it might help to remove all run configurations and create a new one. There’s is a bug report about this behavior.
PS: Although the OP mentions the first part in an edit of the question, but it think it’s worth mentioning in an answer.
Things changed in goland since #Jamillo Santos added his reply.
To start with, there's no more "Go Application".
The easiest way is to locate the file containing the main() function.
There should be a small triangle pointing to it, like in the attached screenshot:
When you click on the small green triangle, you get a menu with Run/Debug options.
Each will create a go build configuration.
You can edit that go build configuration and add the program arguments for your application.
For example, if your program have a command line argument of --arg=value you can add it like this:
I was facing this same issue and I solved by using the "Go Application" configuration (at the Run/Debug Configurations window), instead of the "Go Single File" configuration.
So, go to the upper right corner of the Gogland and "Edit configurations".
Then, add a new configuration using the "Go Application" profile.
After saving, you should be able to debug your code. o/
An easy way to enable this configuration is to use the #user1793301 method and right click on the file you want to run and select "Debug 'go run .go'".
POSSIBLE EXPLANATION
NOTICE: I did not look any further details about it.
Fact: "Go Application" configuration does build the binary executable before running it.
Fact: I could see looking at the console output (inside of the Goglang) is that the IDE uses the DLV as debugging tool.
Fact: I found a dlv debug at the DLV documentation and it seems to compile and debug the code.
Hypothesis: The guys from Jetbrains did not implement it. Or at least not YET.
On version 2019.1.1 there's no more Go Application. Use Go Build instead. Here I am debugging a single script file, but if you have a server app or smth, just point to the main app file:
Notice that in the Files field you have to specify the actual file path. You can put more files (if you want to have more starting points) by separating them with a pipe |. For each file you want to be able to debug, you need to specify the full path.
Again, if you are debugging a server app or something else, that has a single starting point, you only need the startup file specified in the config. :)
I had this exact problem.
Deleted and recreated the Debug run configuration. Debugging then worked perfectly.
I followed the following procedure to start my golang server in debug mode. (You might want to use some other method than creating a makefile for starting your server maybe)
Create a makefile
Define your server/worker startup command in the file
Run it by creating a new configuration for Makefile
Go to Run -> Attach to process -> choose your running server
This will attach the debugger to your process.
Note:
You might need to restart your server for this to work.
The IDE will ask you to install gops, do install it. Without installing gops you won't see any running process.
I right click on project (main.go inside) and choose "Debug ..." and it work
I am currently trying to get the Haxe Debugger working with IntelliJ, using information from This video tutorial and This blog post.
At one point, the tutorial says that a DebugSocket object must be created in the "create" method of the main file. However, when I type this in, I get an unknown symbol error.
From what I understand, the DebugSocket object should be available from the hxcpp library (which I have included). However, the only options I am given if I type new hxcpp. are:
Builder
NekoInit
StaticMysql
StaticRegexp
StaticSqlite
StaticStd
StaticZlib
What am I doing wrong? Have I included the wrong library? Are these tutorials referencing an older version of the library? Is there anywhere I can find comprehensive documentation on how to use the hxcpp debug tools properly?
If this is easier with a flash build then I would consider this.
i haven't gotten hxcpp debugging to work (but i m sure it does). However, i find flash debugging to be easier. I assume you already have the project setup in idea (and isn't just using it as a simple text editor). This is the set of steps i took to get it to work:
Open the project structure (from the menu 'file', then 'project structure')
find the 'modules' section on the left, and select your module, then find the 'haxe' tab.
in the haxe tab, select compile with 'openfl', and target flash.
in the bottom part of the haxe tab, select a flex sdk.
if you don't have flex+air sdk installed, you can easily install it by going to http://www.adobe.com/devnet/flex/flex-sdk-download.html, and http://www.adobe.com/devnet/air/air-sdk-download.html. make sure you remember where you installed it. An alternative place you can find it is via flashdevelop's 'tools', 'install software' menu (which by default installs to your C:/Users/username/AppData/Local/FlashDevelop/Apps/flexairsdk/4.6.0+4.0.0/.
you can add the sdk to intellij by selecting 'SDKs' on the left, and click on the '+', and then select 'flex/air' sdk. You need the flex plugin installed (whcih should be by default).
once you got your debug SDK setup, you can create a run configuration, and debug like you normally do (click on the debug run menu item or toolbar button).
One complication is that on windows, you potentially have a deadlock with haxelib not starting your app, and intellij hanging to wait for it. See https://github.com/TiVo/intellij-haxe/issues/123 - i have outlined a solution in the issue comment if you find that you also have this problem.
use this website : http://raintomorrow.cc/post/48029438701/setup-idea-intellij-for-haxe-nme-development for some screenshots (it's an older version of intellij tho).
I am trying to debug a quicklook plugin in Xcode 4.6. I have created the executable in Edit Scheme.
Now, when I build the project the plugin is not installed to the "/Library/Quicklook" path.
Rather I didn't find it anywhere.
I want to run the plugin in debug mode and want to hit the breakpoints so that I can figure out where the plugin crashes on different files.
You can use brake points and NSLog function for debugging QL plugin. But first you need to configure environment.
Select your project on Project Navigator
Then select QL plugin target
Go to 'Build Phases' tab and add new phase 'Copy files'
Select 'Absolute Path' on destination drop down menu and set ~/Library/QuickLook as subpath
Open terminal and copy qlmanage to your project's root directory with command cp /usr/bin/qlmanage PROJECT_ROOT_DIR
Then select menu Product -> Scheme -> Edit Scheme...
Select 'Run' on schemes list
On info tab select executable drop down menu, then 'Other...' and select qlmanage binary you have copied to project's root directory
On arguments tab add row for 'Arguments Passed On Launch' and set value to -p FULL_PATH_TO_FILE_FOR_PREVIEW
After all steps you can run your project and debug your code.
Xcode 6 must be different somehow, because the instructions above didn't work for me. But here's a solution that I puzzled out today and that works. Hopefuly it will help someone else.
(Assume the name of your plugin is myplugin.qlgenerator)
First of all, if you tried the earlier solutions above, undo them.
Delete the Copy Phase that copies your binary to ~/Library/Quicklook and delete the copy of qlmanage you may have copied to your project's root.
Set the Executable to /usr/bin/qlmanage. "qlmanage" is the program that will load and run your plugin.
Edit your scheme.
Choose 'Run' from the list on the left, then the Info tab of the display on the right.
Choose 'Other...' from the Executable popup. A standard file sheet will appear.
Type cmd-shift-g. A 'Go to folder' sheet appears with a text field.
Enter /usr/bin/ and hit the Go button. The standard file sheet should now be showing the contents of /usr/bin.
Select the 'qlmanage' binary
Turn on the 'Debug executable' checkbox and click the Choose button.
Configure the Arguments Xcode passes to qlmanage
Select the Arguments tab in the Run section of the Edit Schemes sheet.
Remove any arguments that may be left over from previous attempts.
Add -c public.data as the first argument to be passed on launch. You may need to change this depending on the kind of UTIs your plugin supports.
Add -g $(BUILD_DIR)/Debug/myplugin.qlgenerator as the second argument. This resolves to a path to the debug version of your plugin.
Add -p '/fullpath/to/file/to/be/quicklooked as the third argument. This is a path to a file that should already exist. Your plugin will be asked to render previews of this file.
Close the Schemes sheet.
That's it. You should now be able to debug your pluging including setting (and hitting) breakpoints!
I've written this blog post describing how to debug Quick Look plugins which should work as of Xcode 8.2 / macOS 10.12.
Giving due credit, this is basically the steps given here by mlist0987 but with an extra step to get around the System Integrity Protection introduced in 10.11.
TLDR: you have to take a copy of the version of qlmanage, referenced by the link in /usr/bin (i.e. don't just copy the alias) and set that as the debugging executable.
I'm making an OSX screen saver in Xcode (Objective-C, ScreenSaverView class, etc.), and it runs within Xcode correctly. When I navigate to the build output folder and double-click on the the .saver file, it opens System Preferences/Desktop & Screen Saver and asks if I want to install it. All correct.
But when I email the .saver file to myself and open it, System Preferences opens but not to Desktop & Screen Saver and no option to install it is presented. I think it may have to do with the fact that when I build it (with, as far as I can tell, build settings specifying "Release" instead of "Debug"), the output file is still in /Users/Me/Library/Developer/Xcode/DerivedData/ScreenSaver/Build/Products/Debug/ rather than a release folder.
What am I missing here? I have very little experience with configuring build settings, compiler flags, etc.
Edit:
For what it's worth, it seems to work if I compress the output .saver file as a .zip and email that instead. Not a great solution though.
As described in the comment above, apparently it's being built correctly; email messes up binary file attachments so to have it work correctly it should be encoded (e.g. by zipping it) before attaching.