intellij woe

The below meant “it’s a bug in intellij 13.1.2, use junit 4.11 instead of 4.8 (or upgrade to intellij 13.1.3) instead”

I also have the same issue of not being able to run a single test. I write the test, have the cursor in the test method body, hit ctrl + shift + F10 and get the following
Exception in thread “main” java.lang.NoSuchMethodError: org.junit.runner.manipulation.Filter.matchMethodDescription(Lorg/junit/runner/Description;)Lorg/junit/runner/manipulation/Filter;

 at com.intellij.junit4.JUnit4TestRunnerUtil.buildRequest(
 at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
 at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(
 at com.intellij.rt.execution.junit.JUnitStarter.main(
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(
 at java.lang.reflect.Method.invoke(
 at com.intellij.rt.execution.application.AppMain.main(

jruby woe

clicking on a jcheckbox (checkbox)

causes add_item_listener addItemListener to be called twice, the second time with the wrong value!

fiz these call stacks:

C:\dev\ruby\virtual\screen-capture-recorder-to-video-windows-free\configuration_setup_utility>c:\installs\jruby-1.7.12\bin\jruby bad_jruby.rb

done showing
after_checked true
["bad_jruby.rb:45:in `go'",
"bad_jruby.rb:12:in `call'",
"bad_jruby.rb:12:in `on_clicked'",
"org/jruby/gen/InterfaceImpl1723616662.gen:13:in `itemStateChanged'"]
after_checked false
["bad_jruby.rb:45:in `go'",
"bad_jruby.rb:12:in `call'",
"bad_jruby.rb:12:in `on_clicked'",
"org/jruby/gen/InterfaceImpl1723616662.gen:13:in `itemStateChanged'",
"bad_jruby.rb:27:in `__ensure__'",
"bad_jruby.rb:26:in `go'",
"bad_jruby.rb:46:in `go'",
"bad_jruby.rb:12:in `call'",
"bad_jruby.rb:12:in `on_clicked'",
"org/jruby/gen/InterfaceImpl1723616662.gen:13:in `itemStateChanged'"]


“fix” (gah broken java swing yikes) is, as specified here

is to wrap the call to JOptionPane.showMessageDialog inside a SwingUtilities.invokeLater, now it magically works.  Yikes java.

jenkins/hudson woe

The following meant “jenkins has some bug so that if your root pom has needed changes, jenkins doesn’t adopt them right” or something:

fix: manually go in there and run a “mvn install -U” to force it to update

or possibly maven validate


Started by user anonymous
Checkout:workspace / /var/lib/hudson/jobs/ta-common-utils/workspace - hudson.remoting.LocalChannel@52c71145
Using strategy: Default
Last Built Revision: Revision 1b1fc5d76dfc765024433978d6c5013f844ac25e (origin/master)
Checkout:workspace / /var/lib/hudson/jobs/ta-common-utils/workspace - hudson.remoting.LocalChannel@52c71145
GitAPI created
Fetching changes from the remote Git repository
Fetching upstream changes from
[workspace] $ git fetch -t g...
[workspace] $ git ls-tree HEAD
Seen branch in repository origin/master
Commencing build of Revision 1b1fc5d76dfc765024433978d6c5013f844ac25e (origin/master)
GitAPI created
Checking out Revision 1b1fc5d76dfc765024433978d6c5013f844ac25e (origin/master)
[workspace] $ git checkout -f 1b1fc5d76dfc765024433978d6c5013f844ac25e
[workspace] $ git tag -a -f -m "Hudson Build #34" 
Recording changes in branch origin/master
[workspace] $ git whatchanged --no-abbrev -M --pretty=raw 1b1fc5d76dfc765024433978d6c5013f844ac25e..1b1fc5d76dfc765024433978d6c5013f844ac25e
Parsing POMs
ERROR: Failed to parse POMs
org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for javax.mail:mail:jar is missing. @ line 83, column 17

	at hudson.maven.MavenEmbedder.buildProjects(
	at hudson.maven.MavenEmbedder.readProjects(
	at hudson.maven.MavenModuleSetBuild$PomParser.invoke(
	at hudson.maven.MavenModuleSetBuild$PomParser.invoke(
	at hudson.FilePath.act(
	at hudson.FilePath.act(
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(
	at hudson.model.AbstractBuild$
	at hudson.model.ResourceController.execute(
Skipping sonar analysis due to bad build status FAILURE
Sending e-mails to: xxx
Notifying upstream projects of job completion
Finished: FAILURE


mplayer ffmpeg low latency woe

A: 83.1 V: 56.4 A-V: 26.709 ct: -1.840 297/297 3% 1% 0.7% 0 0
[mp2float @ 01062ba0]overread, skip -8 enddists: -4 -4
A: 42.7 V: 56.8 A-V:-14.068 ct: -1.860 301/301 3% 1% 0.7% 0 0
[mp2float @ 01062ba0]overread, skip -6 enddists: -1 -1
[mp2float @ 01062ba0]overread, skip -5 enddists: -4 -4
A: 83.3 V: 56.8 A-V: 26.526 ct: -1.840 301/301 3% 1% 0.7% 0 0
[mp2float @ 01062ba0]overread, skip -5 enddists: -2 -2
A: 42.7 V: 97.6 A-V:-54.871 ct: -1.860 302/302 3% 1% 0.7% 0 0
[mp2float @ 01062ba0]overread, skip -5 enddists: -1 -1
[mp2float @ 01062ba0]overread, skip -7 enddists: -6 -6
[mp2float @ 01062ba0]overread, skip -7 enddists: -1 -1
A: 43.2 V: 98.4 A-V:-55.157 ct: -1.920 310/310 3% 1% 0.7% 0 0
[mp2float @ 01062ba0]overread, skip -6 enddists: -1 -1
A: 84.4 V: 99.2 A-V:-14.848 ct: -2.000 318/318 3% 1% 0.7% 0 0
[mp2float @ 01062ba0]overread, skip -7 enddists: -3 -3
A: 43.6 V: 99.2 A-V:-55.625 ct: -2.020 318/318 3% 1% 0.7% 0 0


meant “you have two ffmpeg’s streaming udp simultaneously to the same port–not good!”

go golang woe

go run wiki.go
# command-line-arguments
./wiki.go:48: function ends without a return statement


meant “your version of go is older than the one you were using before, update it [possibly have to update your ubuntu distro before that will happen though]“

duralast starter vs ultima

Prefer ultima, see my description of my duralast [for my honda accord 96] below.

Just so you’re aware, the following occurred:

I bought a new starter [duralast, lifetime warranty], and installed it presumably well.
It worked once, however, the 2nd, 3rd, and 4th times, it just “spins” like the solenoid isn’t connecting.
I reinstalled it. Same deal. Reinstalled my previous starter [the semi-broken one], still works ok, no spinning.

Took in the starter to get a replacement [lifetime warranty, right?] and the clerk informed me that, unfortunately, unless it tests bad [this one test good, but fails under load], he couldn’t give me a replacement. So I…turned in my new starter for its *own* core charge, and proceeded to decide to never shop at AutoZone again.