airinstallationlinuxsdk
i'm trying to install the adobe air sdk in linux. i unzip the package downloaded from http://www.adobe.com/products/air/tools/sdk/ into a folder "AdobeAIRSDK", and add the /bin folder into the PATH environment variable. but when i tried to run the adl, it gives me the following error:
Error loading the runtime (/home/monuser/AdobeAIRSDK/bin/../runtimes/air/linux/Adobe AIR/Versions/1.0/Resources/nss3/None/libnss3.so: file too short)
what's the problem here and how do i get it fixed?
If your goal is to use a profiler, use one of the suggested ones.
However, if you're in a hurry and you can manually interrupt your program under the debugger while it's being subjectively slow, there's a simple way to find performance problems.
Just halt it several times, and each time look at the call stack. If there is some code that is wasting some percentage of the time, 20% or 50% or whatever, that is the probability that you will catch it in the act on each sample. So, that is roughly the percentage of samples on which you will see it. There is no educated guesswork required. If you do have a guess as to what the problem is, this will prove or disprove it.
You may have multiple performance problems of different sizes. If you clean out any one of them, the remaining ones will take a larger percentage, and be easier to spot, on subsequent passes. This magnification effect, when compounded over multiple problems, can lead to truly massive speedup factors.
Caveat: Programmers tend to be skeptical of this technique unless they've used it themselves. They will say that profilers give you this information, but that is only true if they sample the entire call stack, and then let you examine a random set of samples. (The summaries are where the insight is lost.) Call graphs don't give you the same information, because
They will also say it only works on toy programs, when actually it works on any program, and it seems to work better on bigger programs, because they tend to have more problems to find. They will say it sometimes finds things that aren't problems, but that is only true if you see something once. If you see a problem on more than one sample, it is real.
P.S. This can also be done on multi-thread programs if there is a way to collect call-stack samples of the thread pool at a point in time, as there is in Java.
P.P.S As a rough generality, the more layers of abstraction you have in your software, the more likely you are to find that that is the cause of performance problems (and the opportunity to get speedup).
Added: It might not be obvious, but the stack sampling technique works equally well in the presence of recursion. The reason is that the time that would be saved by removal of an instruction is approximated by the fraction of samples containing it, regardless of the number of times it may occur within a sample.
Another objection I often hear is: "It will stop someplace random, and it will miss the real problem". This comes from having a prior concept of what the real problem is. A key property of performance problems is that they defy expectations. Sampling tells you something is a problem, and your first reaction is disbelief. That is natural, but you can be sure if it finds a problem it is real, and vice-versa.
Added: Let me make a Bayesian explanation of how it works. Suppose there is some instruction I (call or otherwise) which is on the call stack some fraction f of the time (and thus costs that much). For simplicity, suppose we don't know what f is, but assume it is either 0.1, 0.2, 0.3, ... 0.9, 1.0, and the prior probability of each of these possibilities is 0.1, so all of these costs are equally likely a-priori.
Then suppose we take just 2 stack samples, and we see instruction I on both samples, designated observation o=2/2. This gives us new estimates of the frequency f of I, according to this:
Prior
P(f=x) x P(o=2/2|f=x) P(o=2/2&&f=x) P(o=2/2&&f >= x) P(f >= x | o=2/2)
0.1 1 1 0.1 0.1 0.25974026
0.1 0.9 0.81 0.081 0.181 0.47012987
0.1 0.8 0.64 0.064 0.245 0.636363636
0.1 0.7 0.49 0.049 0.294 0.763636364
0.1 0.6 0.36 0.036 0.33 0.857142857
0.1 0.5 0.25 0.025 0.355 0.922077922
0.1 0.4 0.16 0.016 0.371 0.963636364
0.1 0.3 0.09 0.009 0.38 0.987012987
0.1 0.2 0.04 0.004 0.384 0.997402597
0.1 0.1 0.01 0.001 0.385 1
P(o=2/2) 0.385
The last column says that, for example, the probability that f >= 0.5 is 92%, up from the prior assumption of 60%.
Suppose the prior assumptions are different. Suppose we assume P(f=0.1) is .991 (nearly certain), and all the other possibilities are almost impossible (0.001). In other words, our prior certainty is that I is cheap. Then we get:
Prior
P(f=x) x P(o=2/2|f=x) P(o=2/2&& f=x) P(o=2/2&&f >= x) P(f >= x | o=2/2)
0.001 1 1 0.001 0.001 0.072727273
0.001 0.9 0.81 0.00081 0.00181 0.131636364
0.001 0.8 0.64 0.00064 0.00245 0.178181818
0.001 0.7 0.49 0.00049 0.00294 0.213818182
0.001 0.6 0.36 0.00036 0.0033 0.24
0.001 0.5 0.25 0.00025 0.00355 0.258181818
0.001 0.4 0.16 0.00016 0.00371 0.269818182
0.001 0.3 0.09 0.00009 0.0038 0.276363636
0.001 0.2 0.04 0.00004 0.00384 0.279272727
0.991 0.1 0.01 0.00991 0.01375 1
P(o=2/2) 0.01375
Now it says P(f >= 0.5) is 26%, up from the prior assumption of 0.6%. So Bayes allows us to update our estimate of the probable cost of I. If the amount of data is small, it doesn't tell us accurately what the cost is, only that it is big enough to be worth fixing.
Yet another way to look at it is called the Rule Of Succession.
If you flip a coin 2 times, and it comes up heads both times, what does that tell you about the probable weighting of the coin?
The respected way to answer is to say that it's a Beta distribution, with average value (number of hits + 1) / (number of tries + 2) = (2+1)/(2+2) = 75%.
(The key is that we see I more than once. If we only see it once, that doesn't tell us much except that f > 0.)
So, even a very small number of samples can tell us a lot about the cost of instructions that it sees. (And it will see them with a frequency, on average, proportional to their cost. If n samples are taken, and f is the cost, then I will appear on nf+/-sqrt(nf(1-f)) samples. Example, n=10, f=0.3, that is 3+/-1.4 samples.)
Added: To give an intuitive feel for the difference between measuring and random stack sampling:
There are profilers now that sample the stack, even on wall-clock time, but what comes out is measurements (or hot path, or hot spot, from which a "bottleneck" can easily hide). What they don't show you (and they easily could) is the actual samples themselves. And if your goal is to find the bottleneck, the number of them you need to see is, on average, 2 divided by the fraction of time it takes.
So if it takes 30% of time, 2/.3 = 6.7 samples, on average, will show it, and the chance that 20 samples will show it is 99.2%.
Here is an off-the-cuff illustration of the difference between examining measurements and examining stack samples. The bottleneck could be one big blob like this, or numerous small ones, it makes no difference.
Measurement is horizontal; it tells you what fraction of time specific routines take. Sampling is vertical. If there is any way to avoid what the whole program is doing at that moment, and if you see it on a second sample, you've found the bottleneck. That's what makes the difference - seeing the whole reason for the time being spent, not just how much.
TLDR: brew install postgresql@8.4.4 See answer below for more details.
*(I’ve re-edited my answer to give a more thorough workflow for installing/using older software versions with homebrew. Feel free to add a note if you found the old version better.)
Let’s start with the simplest case:
When homebrew installs a new formula, it puts it in a versioned directory like /usr/local/Cellar/postgresql/9.3.1. Only symbolic links to this folder are then installed globally. In principle, this makes it pretty easy to switch between two installed versions. (*)
If you have been using homebrew for longer and never removed older versions (using, for example brew cleanup), chances are that some older version of your program may still be around. If you want to simply activate that previous version, brew switch is the easiest way to do this.
Check with brew info postgresql (or brew switch postgresql <TAB>) whether the older version is installed:
$ brew info postgresql
postgresql: stable 9.3.2 (bottled)
http://www.postgresql.org/
Conflicts with: postgres-xc
/usr/local/Cellar/postgresql/9.1.5 (2755 files, 37M)
Built from source
/usr/local/Cellar/postgresql/9.3.2 (2924 files, 39M) *
Poured from bottle
From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/postgresql.rb
# … and some more
We see that some older version is already installed. We may activate it using brew switch:
$ brew switch postgresql 9.1.5
Cleaning /usr/local/Cellar/postgresql/9.1.5
Cleaning /usr/local/Cellar/postgresql/9.3.2
384 links created for /usr/local/Cellar/postgresql/9.1.5
Let’s double-check what is activated:
$ brew info postgresql
postgresql: stable 9.3.2 (bottled)
http://www.postgresql.org/
Conflicts with: postgres-xc
/usr/local/Cellar/postgresql/9.1.5 (2755 files, 37M) *
Built from source
/usr/local/Cellar/postgresql/9.3.2 (2924 files, 39M)
Poured from bottle
From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/postgresql.rb
# … and some more
Note that the star * has moved to the newly activated version
(*) Please note that brew switch only works as long as all dependencies of the older version are still around. In some cases, a rebuild of the older version may become necessary. Therefore, using brew switch is mostly useful when one wants to switch between two versions not too far apart.
Especially for larger software projects, it is very probably that there is a high enough demand for several (potentially API incompatible) major versions of a certain piece of software. As of March 2012, Homebrew 0.9 provides a mechanism for this: brew tap & the homebrew versions repository.
That versions repository may include backports of older versions for several formulae. (Mostly only the large and famous ones, but of course they’ll also have several formulae for postgresql.)
brew search postgresql will show you where to look:
$ brew search postgresql
postgresql
homebrew/versions/postgresql8 homebrew/versions/postgresql91
homebrew/versions/postgresql9 homebrew/versions/postgresql92
We can simply install it by typing
$ brew install homebrew/versions/postgresql8
Cloning into '/usr/local/Library/Taps/homebrew-versions'...
remote: Counting objects: 1563, done.
remote: Compressing objects: 100% (943/943), done.
remote: Total 1563 (delta 864), reused 1272 (delta 620)
Receiving objects: 100% (1563/1563), 422.83 KiB | 339.00 KiB/s, done.
Resolving deltas: 100% (864/864), done.
Checking connectivity... done.
Tapped 125 formula
==> Downloading http://ftp.postgresql.org/pub/source/v8.4.19/postgresql-8.4.19.tar.bz2
# …
Note that this has automatically tapped the homebrew/versions tap. (Check with brew tap, remove with brew untap homebrew/versions.) The following would have been equivalent:
$ brew tap homebrew/versions
$ brew install postgresql8
As long as the backported version formulae stay up-to-date, this approach is probably the best way to deal with older software.
The following approaches are listed mostly for completeness. Both try to resurrect some undead formula from the brew repository. Due to changed dependencies, API changes in the formula spec or simply a change in the download URL, things may or may not work.
Since the whole formula directory is a git repository, one can install specific versions using plain git commands. However, we need to find a way to get to a commit where the old version was available.
a) historic times
Between August 2011 and October 2014, homebrew had a brew versions command, which spat out all available versions with their respective SHA hashes. As of October 2014, you have to do a brew tap homebrew/boneyard before you can use it. As the name of the tap suggests, you should probably only do this as a last resort.
E.g.
$ brew versions postgresql
Warning: brew-versions is unsupported and may be removed soon.
Please use the homebrew-versions tap instead:
https://github.com/Homebrew/homebrew-versions
9.3.2 git checkout 3c86d2b Library/Formula/postgresql.rb
9.3.1 git checkout a267a3e Library/Formula/postgresql.rb
9.3.0 git checkout ae59e09 Library/Formula/postgresql.rb
9.2.4 git checkout e3ac215 Library/Formula/postgresql.rb
9.2.3 git checkout c80b37c Library/Formula/postgresql.rb
9.2.2 git checkout 9076baa Library/Formula/postgresql.rb
9.2.1 git checkout 5825f62 Library/Formula/postgresql.rb
9.2.0 git checkout 2f6cbc6 Library/Formula/postgresql.rb
9.1.5 git checkout 6b8d25f Library/Formula/postgresql.rb
9.1.4 git checkout c40c7bf Library/Formula/postgresql.rb
9.1.3 git checkout 05c7954 Library/Formula/postgresql.rb
9.1.2 git checkout dfcc838 Library/Formula/postgresql.rb
9.1.1 git checkout 4ef8fb0 Library/Formula/postgresql.rb
9.0.4 git checkout 2accac4 Library/Formula/postgresql.rb
9.0.3 git checkout b782d9d Library/Formula/postgresql.rb
As you can see, it advises against using it. Homebrew spits out all versions it can find with its internal heuristic and shows you a way to retrieve the old formulae. Let’s try it.
# First, go to the homebrew base directory
$ cd $( brew --prefix )
# Checkout some old formula
$ git checkout 6b8d25f Library/Formula/postgresql.rb
$ brew install postgresql
# … installing
Now that the older postgresql version is installed, we can re-install the latest formula in order to keep our repository clean:
$ git checkout -- Library/Formula/postgresql.rb
brew switch is your friend to change between the old and the new.
b) prehistoric times
For special needs, we may also try our own digging through the homebrew repo.
$ cd Library/Taps/homebrew/homebrew-core && git log -S'8.4.4' -- Formula/postgresql.rb
git log -S looks for all commits in which the string '8.4.4' was either added or removed in the file Library/Taps/homebrew/homebrew-core/Formula/postgresql.rb. We get two commits as a result.
commit 7dc7ccef9e1ab7d2fc351d7935c96a0e0b031552
Author: Aku Kotkavuo
Date: Sun Sep 19 18:03:41 2010 +0300
Update PostgreSQL to 9.0.0.
Signed-off-by: Adam Vandenberg
commit fa992c6a82eebdc4cc36a0c0d2837f4c02f3f422
Author: David Höppner
Date: Sun May 16 12:35:18 2010 +0200
postgresql: update version to 8.4.4
Obviously, fa992c6a82eebdc4cc36a0c0d2837f4c02f3f422 is the commit we’re interested in. As this commit is pretty old, we’ll try to downgrade the complete homebrew installation (that way, the formula API is more or less guaranteed to be valid):
$ git checkout -b postgresql-8.4.4 fa992c6a82eebdc4cc36a0c0d2837f4c02f3f422
$ brew install postgresql
$ git checkout master
$ git branch -d postgresql-8.4.4
You may skip the last command to keep the reference in your git repository.
One note: When checking out the older commit, you temporarily downgrade your homebrew installation. So, you should be careful as some commands in homebrew might be different to the most recent version.
It’s not too hard and you may then upload it to your own repository. Used to be Homebrew-Versions, but that is now discontinued.
If you want to keep a certain version of, say postgresql, around and stop it from being updated when you do the natural brew update; brew upgrade procedure, you can pin a formula:
$ brew pin postgresql
Pinned formulae are listed in /usr/local/Library/PinnedKegs/ and once you want to bring in the latest changes and updates, you can unpin it again:
$ brew unpin postgresql
Best Answer
Are you trying to install on a 64-bit OS? Either way, Adobe has a KB on installation that might help.