So I am converting a project from Unity 4.x to 5.x and there are a number of functions that the Unity compiler is warning me that are no longer supported or are obsolete.
My question is do these functions still work? (even though they are marked as obsolete)
I know at some point they need to be updated to the newer API but for the moment I just need to fix the bugs so that the game works. Are these functions still usable? or are they potentially the source of runtime bugs?
Thanks
All obsolete functions has been replaced with new functions. So should take a backup and update your project. Go to Assets->Run API Updater, if your project in not getting updated automatically. Dont worry unity will take care of most of the things.
Yes, it's still work ! They just only warning it.
But i suggest you should change for better result, Unity 5 will update you code from old project, then you should change it following warning, just replace
using "xxxx" instead.
to the current context.
Related
While I'm making an Android app, Eclipse will strike out some things. More specifically, Gallery. Here is a screen shot:
When I hover my mouse over the warnings, it says The type Gallery is deprecated. I don't know what Deprecated means, but I do know that it's a Java term. Any help would be appreciated. Thanks!
(From the question before editing: The term is deprecated, not depreciated. It's a common typo, but worth being aware of for searching purposes :)
It's basically a bit like "obsolete" - you're encouraged not to use classes or methods which are deprecated. Typically the documentation will explain why you're not meant to use them, and give you a better alternative. The deprecated version is only present for backward compatibility, usually.
It's worth taking this seriously - a lot of the time if you're using a deprecated API, you're coming at something from a fundamentally flawed approach. Date is the clearest example of this, where the Java 1.0 API was almost entirely deprecated in 1.1, when Calendar was introduced. Using the deprecated methods in Date is a sure way of storing up problems for yourself.
See the Oracle "How and when to deprecate APIs" page for more information.
Deprecated means it used to support older SDK, but not anymore. Thats why you get the warning.
It is just a warning most of the times it works, but you most be careful because it could cause problem with newer versions.
Deprecated isn't a Java term. It is used in many other things but a lot in programming. It simply means that it is no longer supported...normally replaced with something else. The Android Docs will help you adapt it to what you need depending on what you're doing
Anyone please let me know what is this all about? I am stuck since a week on this and no help from searching. I posted my query to the developer of Alamofire but still no response. Please help! I am totally confused what is wrong in the integration of Alamofire. I have followed every step and this issue is coming with XCode 6.3 as before it was running properly.
When I am adding the Framework under "Copy Frameworks", it is adding the Framework twice showing different paths but when I am Going to there location, it is taking me to the same location. Here is the screen shot.
I have also created the video for that issue. May be that can help in a better way. Please see HERE
Moreover, latest SDK contains framework for MAC OS as well but I didn't add that. I hope all the above information will help you in helping me. Thanks!
This is going to be incredibly difficult to debug without a sample project that is set up in the same manner as your actual one. If you had imported Alamofire project into your project, you wouldn't see two versions of Alamofire appear when you add it to the Copy Frameworks build phase. If you truly want to resolve this quickly, you have two options.
Option 1
Push up a sample project to Github and link it here. We can then take a look at the project and pretty quickly access what the issue is. The main reason it's so difficult here is that there are roughly 10 different things that could be the cause of the issue. Therefore, it's much faster for you to create a sample project than for us to go round-and-round (which we've already started with #Masterfego).
Option 2
Take the leap and try out CocoaPods. It is a fantastic dependency management system that will forever alleviate these annoying types of project management issues. CocoaPods itself has fantastic documentation. Also, the Alamofire README breaks down in detail how to add Alamofire to your project using CocoaPods.
Recommendation
I would highly encourage you to choose Option 2. That is definitely the fastest way forward and you won't regret moving to a more robust dependency management system. It makes managing library updates and new installations extremely simple.
If you do end up going with Option 1, then I'll take a look at your sample project and revise my answer.
I would like to generate LLVM IR for a toy language whose compiler is written in Scala.
SLEM seems to be exactly what I need but I can't figure out if it's usable in its current
state. I tried to download the sources but I am unable to compile it.
Anyone used it successfully or knows whether it's usable?
I haven't used SLEM, but checking its commits it seems that the last one was from early 2011, so it's updated to LLVM version 2.9 at the latest. The IR has significantly changed since then, so it would probably not be usable if you try to use it with a newer LLVM.
You can update it, of course, but perhaps a better option would be LLVM-J - Java bindings to LLVM. It's updated to LLVM 3.1, in which the IR is far closer to what it is right now, plus it's basically just a wrapper around LLVM's C API, so updating it yourself should be relatively simple.
Semantic issue: 'mutable' cannot be applied to references
The above is only the latest in a series of errors I've received attempting to get the fuego-iphone project to compile. I'm not certain, but it could be related to the way I compiled boost. The project's README recommends using these instructions for compiling boost into a framework, but I had already done so with the more recent instructions here. Could this CLANG error be related to a boost version somehow?
I admit relative ignorance when it comes to C++.
If anyone has any brilliant suggestions for using the fuego library in general with xcode, I have tried quite a few different things, and am pretty much at wit's end. Thanks!
EDIT: Apologies for any ambiguity here, but I'm not asking about mutable references, so much as showing the latest symptom of this issue. The fuego mailing list has a relevant question about using boost 1.48, and checking now, it's clear that I've compiled 1.49, so I'll recompile an earlier version of boost and see if that fixes it somehow.
The mutable modifier means that a field can be changed from within a const method. But for reference fields, that doesn't make any sense, because references can never be changed in C++.
It is this sad moment to a developer's life that he has to maintain and fix legacy code... In my case I have to deal with a modified (core scripts) tinyMCE 3.2.2 which I have to update to the latest version in order to play in IE9+...
So my question is if there is a way to check which files have been changed since version 3.2.2 and try to update only those cause it is an overkill to check all the code for the modifications...
Thanks in advance
I fear there are so many changes in so many files that most of them have changed since then and in order to work with IE9.
If possible you should never ever modify the core code. Instead use custom plugins if possible.