Use profile <the name of your executable> to get the profile. Use opreport to read the result. opreport -l might be more meaningful. You can use opreport <the name of your executable> to only get the result related to your program, but personally I prefer to check the whole system.
I have been working on a dialer button class since yesterday. It makes sense to use the command design pattern here, and I want to separate the commands and the buttons so I can change the functionality of every button at runtime.
Now obviously define numpad_0 to numpad_9 is a boring task. What happens if you need to define numpad 0 to 99? So, I came out with this code piece:
1 2 3 4 5 6
@classmethod def_numpad_commands_factory(cls): for n in xrange(0, 10): setattr(cls, 'numpad_%d' % n, lambda self: self.text.append(str(n)))
DialerButtons._numpad_commands_factory()
This way you initialize DialerButtons AFTER you start the program and make methods numpad_0 to 9 on the fly. At least that’s what I was trying to do. However, it didn’t come out as I expected. Every numpad method will just add ‘9’ to self.text, instead of the respective ‘0’ to ‘9’. Why?
The reason is that the context of numpad_0, for example, is actually “f(self): self.text.append(str(n)))” instead of “f(self): self.text.append(‘0’)”. so, what it does here is that it refers to the variable n inside _numpad_commands_factory, and the value of n is 9 after you executed it.
The correct code piece is:
1 2 3 4 5 6
@classmethod def_numpad_commands_factory(cls): deff(chr): returnlambda self: self.text.append(chr) for n in xrange(0, 10): setattr(cls, 'numpad_%d' % n, f(str(n)))
This way we can evaluate the value of str(n) first, then generate the appropriate function and assign it to numpad_n.
the other problem is that the latest cython release (0.9.8) does NOT work with python-efl. you have to install 0.9.6.14 instead. don’t forget to install python-pyrex as well.
now you’re all set, get python-efl.
1 2
cvs -d :pserver:anonymous@anoncvs.enlightenment.org:/var/cvs/e login cvs -z3 -d :pserver:anonymous@anoncvs.enlightenment.org:/var/cvs/e co e17
it’s under e17/proto/python-efl. another funny gotcha is that the binary packages I installed were built on 20080309. so the latest python-efl will not build successfully.
1
cvs -z3 update -dP -D 20080309
fixs this.
the default build-all.sh under python-efl directory builds evas ecore edje emotion e_dbus epsilon. that’s too many. for me I just need evas ecore edje e_dbus.
it’s a really bad combination. not so long ago the driver changed default from XAA to EXA, thus my fonts disappeared. after the last update, now compiz just keeps telling me it cannot load cpp plugin and fails to start.
guess the compiz guys put this chip(8086:2992) in their blacklist for a reason. damn, I really need compiz!
the whole story is that I started a project locally and I used git as my SCM. now I’m going to put it into a svn repository with full history but I still want to use git.
normally you should make this decision at the beginning. that means you
1
git-svn clone http://svn.somewhere.com/myproject
first, then you use git as usual, do git-svn rebase and git-svn dcommit. you have to do this because git-svn must know where to start, namely you should have at least one git-svn-id in your git log to start with.
here is how I add svn support into an existing git repository. basically it’s easy, you just
now git branch -r should tell you there is a branch called git-svn. you git rebase git-svn your current master. if it succeeded then you’re all set.
however, in order to do this, there must be a point back in time that these two branches are the same. if it’s not the case, you’re in trouble. you have to use git-svn set-tree to force a svn commit to be your starting point. in my case, the svn repository started out empty, so I forced the first commit in my git. after that git rebase succeeded like I expected.
It turns out the default AccelMethod of xdriver “intel” has been changed to EXA, and it’s a known issue that EXA does not work with compiz. So I force the AccelMethod to “XAA” and compiz works again now.
I’m using debian testing (lenny) and after the latest update my xserver no longer display fonts. This is not totally true because I can still see the fonts on gdm, but after logging in, no fonts whatsoever. It turns out the i810 Xorg driver is messed up and I have to set NoAccel to true to avoid it.
If you specify both `inline' and `extern'in the function definition, then the definition is used only for inlining. Inno case is the function compiled on its own, not even if you refer to its address explicitly. Such an address becomes an external reference, as if you had only declared the function, and had not defined it.
This combination of `inline' and `extern' has almost the effect of a macro. The way to use it is to put a function definition in a header file with these keywords, and put another copy of the definition (lacking `inline' and `extern') in a library file. The definition in the header file will cause most calls to the function to be inlined. If any uses of the function remain, they will refer to the single copy in the library.
Since GCC 4.3 will implement ISO C99 semantics for inline functions, it is simplest to use `static inline' only to guarantee compatibility. (The existing semantics will remain available when `-std=gnu89' is specified, but eventually the default will be `-std=gnu99'; that will implement the C99 semantics, though it does notdo so in versions of GCC before 4.3\. After the default changes, the existing semantics will still be available via the `-fgnu89-inline' option or the `gnu_inline' function attribute.)
GCC does not inline any functions when not optimizing unless you specify the `always_inline' attribute for the function, like this: /* Prototype. */ inline void foo (const char) __attribute__((always_inline));
The behavior of the executables will be different with or without the -O option of gcc. Compile it without -O, the program will print “extern”. Compile it with -O, the program will print “intern”.
# Clone a repo (like git clone): git-svn clone http://svn.foo.org/project/trunk # Enter the newly cloned directory: cd trunk # You should be on master branch, double-check with git-branch git branch # Do some work and commit locally to git: git commit ... # Something is committed to SVN, rebase your local changes against the # latest changes in SVN: git-svn rebase # Now commit your changes (that were committed previously using git) to SVN, # as well as automatically updating your working HEAD: git-svn dcommit # Append svn:ignore settings to the default git exclude file: git-svn show-ignore >> .git/info/exclude