-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xcode 10 seems to brake the plugin completely #93
Comments
No, no luck whatsoever. usigning Xcode and adding the uuid in the plugin worked on Xcode9. |
Yes, the same issue here, with unsigned Xcode 10 Release version. 💔 |
me too Xcode Version 10.0 (10A255) |
actually it's still working in the Report navigator > debug session , but less useful than directly in the console :/ |
I wonder whether the console view's base class has changed. I spent a little time playing with this tonight, and can't get the new console to trigger the method [NSTextStorage fixAttributesInRange:]. From digging through the class-dump'ed source for a variety of the frameworks. The most obvious (found in IDEKit.framework) is this:
I've played a little with setting breakpoints and trying to inject the xc_fixAttributesInRange: method into this class, and neither seems to have any success. Further, printing the contents of this view suggests it's empty. There's a second ivar of the consoleArea (of type IDEConsoleArea), _consoleViewSwift, which returns a Swift class IDEConsoleEditorView (found in PlugIns/IDESourceEditor.framework). Printing the -string method of this class into the console gives the correct output. It's full path is given as:
And we can confirm that this the new console view:
So I suspect this is the starting point for the Xcode 10 version of this implementation. My attempts to go any further here are hampered by my lack of Swift experience, such as an inability to access the ivars of the IDESourceEditorView. I'll keep hacking tonight, but I don't suspect I'll get much further... Edit: |
Can someone confirm that other plugins still work and it's just this one. |
I think they work fine (including this one), only the console has been changed, and XcodeColors cannot patch it the old way. |
yep, exactly |
Except it also looks like the editor view has been rewritten in Swift as well — perusing the view hierarchy shows that there's now a IDESourceEditor.SourceCodeEditorContainerView_ControlledBy_IDESourceEditor.SourceCodeEditor view, which could mean that many other plugins are likely to be affected... |
I made a dump of the view hierarchy of Xcode10: https://gist.github.com/basvankuijck/32693fd517c641f94c13295344f9620e |
I've had a little more of a dig, now that I have figured out how to set breakpoints on these system Swift classes ( The line layers are created by SourceEditorLayoutManager.makeLineLayerForLine(..). Early in the disassembly, it calls SourceEditor.SourceEditorLayoutManager.attributedStringAndImagesForLine(..). |
Some further exploration. My class-dump'ed version of SourceEditor doesn't include any methods inside the SourceEditorLayoutManager class — though I'd wager that it may be due to the fact that this method returns a tuple instead of a single value, and hence class-dump can't interpret it properly. But I can find the IMP for this method:
That
I'm not certain we can necessarily work backwards from here though, nor how to go about swizzling this method. So I think I'll pause here, remove my XcodeColor bits from my current logger for now, and hopefully somebody Swiftier than I will be able to take this from here... |
For those concerning, here is a class dump of |
I'm afraid I can't offer much help with this (other than emotional support), but I don't want to live without my colors... It's so puzzling that they wouldn't just add this as a feature. Seems like I need to learn Swift after all? Please do tell if anyone solves this first. |
@sbwilson @basvankuijck Your investigations in trying to get plugins working is very hopeful. I (and perhaps others) might even be inclined to support your efforts by tipping a patreon account. As this type of visual logging is still far superior then anything Apple has delivered. |
You need to stop saying all these encouraging words — I spent another few hours playing this morning when I shouldn't have... The one success I can report is that one can add methods to SourceEditorLayoutManager using class_addMethod, and they can be called from both objc and Swift:
At my trusty breakpoint (attributedStringAndImagesForLine), I can call
It is possible to access some of the ivars from this class though, both in the debugger as well as the objc runtime methods, though there doesn't seem to be any interesting things there. Has this achieved anything though? I doubt it. In order to do the swizzle, we need to get some handle to the method. From my explorations, it seems that a method must be tagged with :( |
Excuse me, am I the only one who can't use this plugin in Xcode 9.2 after trying all suggestted method? I added DVTPlugInCompatibilityUUIDs, but it still not work. |
No, it does not work anymore. |
the same issue. I use xcode10.1 and the plugin still does not work. |
How to fix it? |
I think this plug-in is done. :/ |
Hope so. |
I didn't want to implement or change to another framework for logging, and I wanted the color functionality that is now long dead. I'm tired of apple deprecating things to death and frameworks that implement Swift breaking with every XCode release... so I wanted something just very simple and usable that would never break. I implemented something using the bones of Xcode logger but not using any Xcode plugin. It is pretty simple to use this, all you need to do is call the logging functions and it will dump ANSI coded log output to /tmp/xcode.log as well as continue logging to the Xcode console (but without colors). Furthermore in the color log I'm injecting information about the file and class and method that is being called. So if you use it like this:
You get output that looks like this: Or this: The first two params are short forms, where say "yellow" will turn into a call to [UIColor yellowColor] and I tried (but didn't really test) to support older ways XCodelogger was logging colors. So things like:
Should work as before. I hope anyway. It will automatically remove itself when compiling optimized at the macro level. You can pass in various params as shown above to format and log strings. To view the color log you'd just do this in a terminal window:
And then you have some color logging functionality back on a lightweight basis without having to maintain anything. All you really need to do is just use the top level functions, there are objects underneath on a singleton basis and using dispatch queues so multiple threads don't interfere and overwrite in the log. I just slammed this together, so maybe there's bugs still. But you can build on it. Xlogger.h:
XLogger.m
|
Has anyone luck with Xcode 10?
The text was updated successfully, but these errors were encountered: