I've tried Swift3, it looked nice.
After adding some Swift code to existing Objc/C++ codebase (pretty large one), terrible debug delays began to happen.
If I write
assert(false);
somewhere, the message about it appears in console, and Xcode reaches breakpoint after 2 minutes (so I can see exact place of failure, observe variables and so on).
After discarding Swift code (so there're only Objc/C++ files), debugging is just 2-3 times faster.
I have to wait 30 seconds to reach function on button click:
After searching for it, I suppose the problem is with Xcode 8.3.2.
Have you met this problem?
Do you know of some new compiler/debugger flags, which speed up debugging?
Is it proper (for development process efficiency) to add Swift to such codebase?
Related
I'm working on an iPhone game and have now a big problem.
The project is getting larger and larger. Now Xcode takes forever for indexing, typing is laggy, autocomplete takes some seconds, building the file takes forever and so on.
Im using Xcode 8 Beta 6, but that is not the problem. If i open another project which is not so big the performance is normal.
I deleted the files under DerivedData but that did not help.
My question is: In this big project I have one GameScene.swift file with 7500 lines of code. Is that causing the problem? Or should Xcode be able to perform this much code in one file and the problem is more the code itself? Ive read that for example the syntax of an array can cause the problem, or if you declare an array with 30 or more objects (both not the case for me).
I think it's something inside the code which causes the problem and not the size of the code - but I don't know how to find it out.
Edit: Oh, the process SourceKitService has almost always 100% CPU use.
This Issue Occurred On A SpriteKit Xcode Project
I have an issue with Swift where, once my project reaches a certain level of complexity where I have tons of classes and methods around, my autocompletion breaks so that "Jump To Definition" ceases to work and my IDE is reduced to the usefulness of a basic TextEditor/Notepad.
My code's color will change to white completely, which causes a lot of strain on my eyes, and this seems to only happen when I remove and add large blocks of code as I watch my CPU activity climb up to 75% usage on all CPU cores.
I think this started happening when I switched the target iOS from 9.3 over to 8.0. Is this an issue with the compiler trying to interpret old Swift syntax?
I also will have cases where I wait two minutes for minor changes to compile, only for the build to fail due to "Linker command failed with exit code", which is easily fixed by compiling twice.
Here's my specs:
OS X 10.11.4
Core i7 Skylake 4.0GHz
16 GB DDR4 RAM
256GB SSD
I'm thinking about building a system running OS X with dual processors which might alleviate the issue, since it can take upwards of 2 minutes just to compile code that's different by 1 line.
Okay, I found one solution which resolved my issue.
Remove All Emojis From Variable Names & .Swift File Names
Contrary to Apple's official Swift 2.0 textbook, DO NOT use ANY kind of Emoji's for things like Variable Names and Swift File Names UNLESS you know that the emoji you're using is a very old emoji (but even then, I wouldn't recommend it).
After opening my project in AppCode, AppCode had unicode problems with file names such as: foobar🔵.swift. It was very buggy and it would break Xcode later if I opened and saved a project with pre-existing emojis in AppCode.
So avoid using emojis in your code unless it's for strings like:
let someString = "⬛️🗡💣📚"
Welcome to Swift! Great language, awful tooling.
Joking aside, there are a couple of issues at play here. First off, syntax highlighting disappears when SourceKit crashes. SourceKit is the library which parses Swift on-the-fly so that Xcode can do things like indexing, syntax highlighting and code completion. It's a lot better than it used to be (using Swift 1.0 in Xcode was almost comical at times), but it's still far from perfect. Until SourceKit improves, you won't see much difference.
As for your build times, it's worth trying something like the Swift Build Time Analyzer to see which functions are taking a particularly long time to compile. I recently halved the compile time of the project I work on by removing all lazy vars set via closures. A recent compiler change made type inference for these sorts of closures incredibly slow, so each one was taking ~6 seconds to compile.
I'm stumped with an error I found and from my searches, only a few have also received it a long time ago and I'm not quite sure if / how a solution was achieved.
The error I'm getting in xcode is
Mprotect failed at 0xed50000 (length 212992) with errno 12
Mprotect remapping failed
The game works fine in the editor and all other platforms. This error is iOS specific and happens every session that goes past the login process (loads another scene) for > 10 seconds. The exact time is inconsistent. I say inconsistently because it doesn't seem to happen right after an interaction. My game does download data and images so my hunch (and a lousy hunch at that) is threading / wait time is the cause of the inconsistently.
Here's some of my search results
http://forum.unity3d.com/threads/mprotect-failed-at-0x51fa000.15858/
this is from all the way back from 2008 and it looked like it was a
hotfixed by Unity
http://forum.unity3d.com/threads/mprotect-remapping-failed.15443/
this is more of the same but a Unity dev did mention:
Workaround: don't allocate mono objects too frequently, reuse them if
possible (this would also improve your performance).
This is a little embarrassing since I'm a self taught Unity user but
what exactly does that mean and can I apply it to my problem?
My system info:
Currently on Unity 5.3 but has been happening since 5.2 Xcode is version 7.2 but has been happening since 7.0 I think My game is 2d, it uses NGUI, it downloads data and images from the internet.
Thank you so much for your read and time. Hope you can help!
We've came onto this strange bug in our project (I hope it's a bug not just our fault). Let's jump straight into the problem.
Our application is Storyboard based, of course it connects to the external API etc. But we've faced this strange thing that regular implementation of prepareForSegue: and things related to segues automagically delegates things to other threads. Just a small example - when I do NSLog(#"Sample log") in viewDidLoad it doesn't get fired when it should but it gets called in the random time that's why I guessed that something might get delegated to the other-than-main thread. Firstly I thought that the networking layer may cause this because of blocks and so but even when I put direc logs into the application they get called in a random time! We've tried to check the thread in debugger and it shows us thet everything happens in the main thread. Strange, right?
Anyway, my colleagues check this against the different versions of Xcode because on my machine there are bothe 6.2 and 6.3 Beta. When we compile this on a computer with only 6.3 installed everything works properly! Is it possible that 6.3 Beta introduces some changes which handles segues differently than previous versions? Or maybe we should start seeking for the troubles some oher place?
I have been asked to update a old ios application built in Xcode 3.1 with some ios 6 features.
When I tried building the source using my xcode 4.5, it refuses to compile because there are numerous places in the project where simple return statements are used in methods which actually is supposed to return a boolean or similar value.
Xcode 3.1 allows it and 4.5 does not. Somewhere in the middle, apple decided to add this restriction.
My problem is that the code is over 20,000 lines of code and the developers have used the simple return statements where ever they needed the method to stop execution. Since the compiler stops compilation when it encounter's the first of these errors, I have to fix it one at a time and then try compiling it again only to find another error. I tried like 2 hours fixing 100s of such return statements.
Is there a compiler flag or Xcode build setting that would change these errors as warnings and allow me to run this app on Xcode 4.5?
This is the exact error that Xcode throws :
/Users.../Classes/WaterMaps.m:5471:5: Non-void method 'initWithParams:mass:radius:totalAssetInfo:' should return a value
Please help..
This has nothing to do with Xcode, but with the compiler. And not Apple added this restriction, the compilers are not from Apple, they are OpenSource projects (GCC and LLVM/clang).
May I ask why it took you 2 hours to fix 100 such return statements? Fixing 100 such return statements shouldn't take much longer than 5 minutes.
Write return 0; somewhere, select it, copy it to clipboard (CMD+C), delete it again.
Write return; somewhere, select it, hit CMD+E to copy it to search buffer, delete it again.
Go to your source code.
Hit CMD+G which means "find next".
If the found expression is not marked as error, go to (4).
Hit CMD+V (paste), which overwrites return; with return 0;.
Got to (4).
So basically you keep hitting CMD+G to jump through the file and CMD+V whenever you see an error. To quickly jump to the next file, open the error view in Xcode:
Select the first error of the first file and whenever your CMD+G procedure reaches the end of the file, hit CMD+' which jumps to the first issue of the next file on the list. As a developer, you should really learn to use your keyboard more effectively. Keeping your hands on the keyboards makes you hundreds of times more productive than going forth and back between keyboard and mouse/touchpad/trackball/etc.
And how is the amount of code lines ("over 20'000 lines of code") even relevant? It's the amount of return statements that is relevant.
Your code is currently seriously broken and instead of wasting time on thinking how to make this broken code compile, I strongly recommended that you should rather go and fix it. Since once fixed, it will work forever and not break again the next time the compilers are updated and your last hack doesn't work any longer.
I mean how shall a compiler know what you want to return for a method that returns a boolean or an int value if you only type return? The suggested `return 0;' works for all methods that return a numeric value (including floating point) and booleans (0 = false/NO) and makes the compiler happy again. It is the same value that was returned by ancient C compilers in that case.
Note that even in Xcode 3.1 those return statements should have produced warnings all over the place. As a serious developer, always treat all warnings as errors. You project should not have any warnings. Warnings tell you that there is something wrong or at least there might be something wrong and that means you should go out and fix it. Almost all warnings can be silenced by modifying your code. So instead of ignoring warnings or disabling them in the compiler, fix them. Many companies have a zero warning policy today and if your code produces only a single warning, it is rejected. If the author of this code had treated all warnings as errors, you wouldn't have to fix those now.