After updating to assimp 5.0.1 from 4.1 I noticed that animations in my engine were running very slow. I'm loading assets from .fbx files. I proceeded to do some debugging and found that aiScene->mAnimations[i]->mDuration value is different for the same assets between versions 4.1 and 5.0.1 of assimp:
4.1:
5.0.1
So that would be 33.3333 times slower. I can of course account for this in engine, but was curious to know if this was done on purpose and if so what that purpose was (as I noticed in release logs that improvements were made to the fbx importer for this release)
We made a lot of improvements in the FBX-animations. The time-scaling was also refactored by the developers of the Godot team. So right now the times for the 5.0.1 animations are correct in terms of the FBX-specification.
That is the reason for the changes in times to a much slower animation.
Related
I'm maintaining some js library. Releases follow SemVer. Current stable version is 1.5.0. I'm working on 1.5.1 and have 1.5.1-beta.2 which is published at npm with "next" tag. Today I got bug report, discovered the issue and ready to fix it. The thing is that 1.5.1 is not going to be finished during nearest days, it turned out to be more complicated than I planned initially. But I want the fix to be published.
What is the right strategy in this situation? Obvious approach which I'd like to avoid is to postpone the bug fix until 1.5.1 is done and published and then release 1.5.2 containing the fix.
Another way is to publish the fix as 1.5.1 based on 1.5.0 and then continue previous work switching it from 1.5.1-beta.2 to 1.5.2 or even 1.6.0. I'm concerning about inconsistency with the result chain in this case:
1.5.0 → 1.5.1-beta → 1.5.1-beta.1 → 1.5.1-beta.2 → 1.5.1 (bug fix, based on 1.5.0) → 1.5.2 (based on 1.5.1-beta.2)
How such collisions are being addressed using SemVer?
Okay, so you have bug set A currently baking as 1.5.1-beta2 and you have a new bug set B that you want to get the fix out for immediately. The correct mechanism for this is to fork 1.5.0, fix bug set B, and release 1.5.2 (assuming you don't need a beta). Then merge your B fixes into your A working branch and release 1.5.3-beta1 and proceed to drive that to an official release.
It gets a little more complicated when you have two parallel beta sequences running, particularly when you're not sure which is going to make it to release first, but it is manageable. The key is to to just keep in mind, how SemVer precedence impacts the decisions your customers make (the algorithms they apply), whether to fast-track a particular version into their production systems, verses how their developers pull bits from you.
My production systems, have two inputs:
Development is the product of my engineers.
Automated maintenance is the product of a system that:
Pulls patch releases and applies them to a fork of my current production code.
Tests the applied changes against an extensive suite of functional and performance tests.
If the tests are green, flight tests the changes in my production environment, while monitoring for unusual changes in production failure rates.
As long as everything is going well and a human doesn't step-in to stop it, eventually rolls out the changes to the entire production system.
There are of course, variations for services and packaged products. The point is, you can use your release points to signal to your customers automation, or developers, that you have an important bug fix that has little risk of breaking anything. There is no requirement that 1.5.2 have any lineage back to 1.5.1-beta#. You are not required to ever release a 1.5.1. It is customary however to add a comment in your release notes that 1.5.2 is a hot fix for the bug in 1.5.0 and does not contain the fixes in 1.5.1-beta#.
While you may never encounter a need to do so, you don't have to include the bug fixes from 1.5.2 in your eventual 1.5.3 release, provided the later release, passes your quality controls. It is sometimes the case that a specific bug fix, winds up not being applicable in later releases.
How you maintain your product quality is entirely up to you. How you signal the level of risk/importance for a specific release, is defined by the SemVer standard.
I need to be able analyzing Performance/memory issues which occurs on customer site for a OSX production application written with Objective-C.
As for now I found:
OSXPmem – it’s main drawback is that I need to dump all memory space to in to a single file(it’s not possible for me to transfer ~4GB or more from customer site - I can zip it but the bigger problem is that it not support 10.10 Yosemite.
Valgrind – Does not support 10.10 Yosemite.
Is there a good tool out there ? (such as WinDBG for windows)
BTW at development I use Instruments but in this case it does not help.
thanks for the help
Apparently valgrind will build, install, and work on osx 10.10 from the head of the development branch in the source repository, e.g. as per yosemite-and-valgrind and http://kalapun.com/posts/checking-c-code-with-valgrind-on-yosemite/
However depending on how the application works you may have more luck with the leaks command-line tool or the full-fledged Instruments tool, from Xcode. I haven't upgraded to 10.10 yet to try it there, but it should obviously still work in the latest Xcode for 10.10. leaks attaches to the running process, so is better for long-running processes that you can't shut down (cleanly), or for capturing usage metrics during specific operations.
I'm in charge of developing an in-house enterprise app for the company I'm working for. I've hit a huge roadblock that I can't figure out.
The app use's audio units, I have 3 iPhones:
3gs - iOS 5.1.1
4 - iOS 5.1.1
5 - iOS 6
using a provisioning profile I can run a test build on these devices and everything works fine, using my own developer account and an ad hoc profile, they all work fine. Build it for wireless distribution with enterprise and all the iOS 5.1.1 devices don't work.
There is no install issue, the apps load correctly but the audio units + a circular buffer I made go to hell. It seems like I'm getting massive buffer overrun, but I can't figure why, its only with the enterprise account that this happens. I'm getting all the correct data, the data is feeding into the audio correctly and if I increase the circular buffer size very high I can here the correct audio for a very short time and then it goes hazy and will come back briefly and go hazy again.
I'm wondering if anybody knows any of the underlying differences between a testing build and an enterprise build. Is it possible there are some best practices that I'm not following, as I can't understand why I'm seeing such huge differences between the two.
Note:
Only settings change I'm making between the 2 builds is code signing, nothing else
Without you posting code I can only speculate. The Enterprise build most likely compiles with optimizations while your test builds will not. You may have introduced some undefined behavior that causes your application behave irregularly when optimized. I recommend running the analyzer over your code and fixing any issues, as well as running the profiler. An example of compiler optimizations causing issues can be found here: Compiler optimization causing program to run slower
I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.
I see that some people are updating their apps to Rails 3.1. When is the best time to update a production app? As soon as it is released? When the next stable version is released? A major release like Rails 4?
Currently running 3.07 app on Heroku.
Thanks.
EDIT: Yes, running Ruby 1.92p180.
Tests definitely.
The answer also depends on a lot of other factors about your setup such as:
What is your current testing stratgey? Do you volume test?
Do you have a lot of users that would drown your ability to respond if there's an issue?
Do you have a failover / fallback strategy/plan if issues arise?
What is your backup stratgey and how well do you execute it?
How complex is your code and how much custom code is there?
How similar are your development / test / production environments?
Is there a particular business reason to upgrade now rather than wait a month or two (given that it was just released).
Are you running ruby 1.9.2 (almost certainly but has to be checked).
Have you planned for staff availability for the downtime/interruption "in case"
Have you tested the actual planned move process on test servers to make sure there are no gotchas?
Generally I would wait 2-3 months. Especially so with Rails 3.1 as there were quite a few changes with this 'dot' release, although again tests should help - though that'll depend on their availability and completeness.
When all your tests pass.
I normally wait til at least the .1 release to update an existing production app. But i have apps runnig on 3.1 as they where developed using the betas and RCs, and so far no issues.
But seriously when all your tests pass.