Buildbot 0.8.1 inactive for 2 minutes before building - buildbot

My apologies if this has been answered before - I can't seem to find any previous q&a on this.
I run buildbot 0.8.1 and use PBChangeSource() to receive changes from svn. Problem is a build will only start exactly 2 minutes after a commit. I am pretty sure there is a config somewhere that I can use to make the pause go away, but I can't find anything in the documentation. Thanks.

That sounds like the treeStableTimer (see http://buildbot.net/buildbot/docs/0.8.1/full.html#Scheduler-Scheduler).
You should be able to set this to 0 (though I think it is useful to have some delay).

Related

Karma clear screen before running tests

I use karma to run jasmine specs. Every time a file changes the tests are run. This is awesome but it would be even better if the previous test output would be removed from the terminal.
Is there a way to clear the terminal before tests are run in karma?
It is not supported. I like this idea though. I created issue #1004 to support this.
The issue #Sylvain has created is still open, but there is a plugin karma-clear-screen-reporter which does the job. Internally it uses the magic:
console.log('\u001b[2J\u001b[0;0H');
Alternatively you can also place this at the top of your test runner code to clear the console yourself.
Context
My answer is the same as #bluenote10
The difference is that I made some improvements to the package he posted and published it on my github:
Karma Clear Screen
Improvements
Improvement in the initial message.
Date of the update.
In addition to console.log('\u001b[2J\u001b[0;0H'); the spacing has been improved.

Where do I get XHProfLive for XHProf?

I've read a long page about XHProfLive, but I didn't manage to find where to download it. Where do I find it?
http://www.facebook.com/note.php?note_id=62667953919
I am aware that XHProf comes with some UI, but I didn't find anything more advanced than that.
XHProf was open sourced, not XHProfLive.
But do look into XHGui: http://phpadvent.org/2010/profiling-with-xhgui-by-paul-reinheimer
It has been more than a year since I've asked the original question. There hasn't been much of an improvement to the original UI ever since. Therefore, I've undertaken the development of xhprof.io - GUI to analyze the profiling data collected using XHProf.
Furthermore, as #gazarsgo have already mentioned, there is Reinheimer's branch of the original XHProf UI.

In Emacs how to prevent the same buffer from showing up in different windows in the same frame?

I'm not sure how to comprehensively accomplish this.
Currently I build my own bzr Emacs on Windows, so I can see that `display-buffer' now takes a SPECIFIERS option, which could be interesting, but I couldn't find concrete examples of how to use it.
But this problem really has to be solved before display-buffer is called.
For example a Help window previously was visiting Buffer-A, but I've visited Buffer-A in another window while reading the help. Now when I quit the Help window, Buffer-A appears there as well. I want some other useful buffer to appear there.
I have some experimental code that appears to work here.
I emphasize experimental. This could melt your Emacs.
I'd appreciate it if you could contact me on github or here to let me know your experiences with this.
Emacs 24 is not yet released. They have changed the buffer-display/window behavior and Lisp interfaces several times over the release's development period. The current status of the release is pretest, so development is supposedly stopped, except for bug fixes.
However, ongoing emacs-devel#gnu.org discussions show that things are still in flux wrt buffer display and windows.
Your best bet is to check the latest doc and code (which might not correspond exactly, at this point).

Eclipse - Number of times compiled over project?

My team just finished a huge project. We're going to present it to class in a week, and want to add some interesting stats.
Is there any way to find out how many times we've compiled the code over the last X days?
Thanks
Not that I'm aware of but if you go into Project>Properties>Refactoring History you can see a detail of all the refactoring you've done. That may make for some interesting stats.
I'm not aware of such functionality but you can install a metrics plugin such as this for other code metrics. Eclipse auto-compiles code so I'm not sure how useful such as statistic is.
I don't know of any way to get the number of times you compiled. But if you want some similar (and hopefully useful) statistics, go to .metadata\.plugins\org.eclipse.core.resources.history. You will see the change history there. Each time you make a change, Eclipse keeps track of the change by creating a file here. Sort the files by date, and you can easily get some statistics to display for your presentation.

Undo history broken in Eclipse?

Is Eclipse's undo history broken? I have been using 3.1, 3.2, 3.3, and now 3.4 versions for the last few years and was always able to undo only about 20-25 changes back in history.
This nonsense has cost me some lost modifications countless times when trying to revert some recent changes (if you reply with "you should commit to svn every 25 changes", I'm going to unleash dragons on you).
There's a setting in Preferences->Editors->Text Editors->Undo history size and I set it to 1000 but it didn't help anything.
I'm mostly using Eclipse with the Perl E.P.I.C. in the Perl Perspective, if it matters.
So guys, what's the problem and how do I fix it?
I'm experienceing the same problems and I am also using Eclipse with EPIC.
It seems this is a known issue with EPIC, see http://sourceforge.net/tracker/index.php?func=detail&aid=1728227&group_id=75859&atid=545274
Reported in 2007, so I'm surprised it hasn't been fixed :(
Edit: Yay! This is now fixed in EPIC version 0.6.37
Testing show that for low values of the property it does indeed work - I'm using the Java Editor.
Perhaps you can try and see if the Java Editor respects those settings - I'm too lazy to make > 50 changes and undo, and if it does file a bug against E.P.I.C.?
Not a direct answer, but Eclipse maintains a local history of edited files (Context menu -> Restore from local history). Maybe that would be a better way than going back 25 steps in the undo-history.