Tuesday, October 13, 2015

Netbeans for C++

I've been using Netbeans for C++ development. One of the big issues I had is getting the Netbeans Code Assistance feature to work properly. Meaning, I want:

  • syntax highlighting
  • code completion
  • refactoring
  • call graphs
In short, everything I expect from Netbeans when using Java. I am dealing with a large CMake based project, with existing sources. So I build the project manually, and CMake emits the Makefiles. Now I have a project that netbeans can open (an "existing Makefile based project"). The next thing you need to do is set your include directories (shown below). 

Now this is where things get weird. Despite having set the includes several times none of the Code Assistance features worked. I tried deleting the NB cache, restarting, etc, etc. Nothing worked. If I write click on the project, and select Code Assistance I can dump the diagnostics. Notice how the user include paths that I entered ARE NOT PRESENT? WTF?


 from project main [/Users/ghendrey/git/main]
Lang=CPP Flavor=CPP excluded=false
User Include Paths:
User Macros:
System Include Paths:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks



But, my user includes are not showing up! Finally, I tried Project > Properties > General and added my "src" folder to the "Project Source Folders". Now this seems like a bit of a "duh", but it wasn't obvious, since "." was already listed under project source folders, which presumably grabs everything. Furthermore, once I save the properties, and close the dialog, the "src" folder disappears, and only "." is shown. HOWEVER, it seems that adding "src" somehow kicked started the Code Assistance. Now  I see the correct user includes when I dump the diagnostics:

 from project main [/Users/ghendrey/git/main]

Lang=CPP Flavor=CPP excluded=false
User Include Paths:
/Users/ghendrey/splunk/current/include
/Users/ghendrey/git/main/src
/Users/ghendrey/git/main/src/libzero
/Users/ghendrey/git/main/src/util
User Macros:
System Include Paths:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks

And lo and behold, all of code completion is working. Incidentally, the Code Assistance right click menu is often broken (several of the items become unelectable until I close the project and restart netbeans). So, if you can deal with these annoyance, once you (finally) get up and running with code assistance in netbeans, it is a way way better c++ development environment than eclipse. 



Friday, October 09, 2015

Why oh why did I just waste the day on this shit?

I just missed tucking my daughter in because I've been trying to wrangle Jersey's Moxy into working properly. Jersey guys: you have done great work, but this Moxy thing is a PIECE OF SHIT. I'm sorry, but I am tired and grumpy. I have used Jackson so successfully with Jersey in the past, but I wanted to believe your docs on Moxy. I wanted to believe it would "just work". Boy...moxy sucks. I should have just stuck with Jackson. I'm so pissed off I need to write a silly blog post to calm down. What really pisses me off, is every single thing I was trying to make work with Moxy, just immediately worked when I switched to Jackson.

Thank god for Stack Overflow: http://stackoverflow.com/questions/29322605/how-to-return-a-json-object-from-a-hashmap-with-moxy-and-jersey

I should have listened to the answer better. Apparently the answer to how to get Moxy to work is not to use Moxy.: "For this reason, and actually many others I have encountered in the past, I do no recommend using MOXy even though it is recommended by Jersey. Instead, use Jackson. Jackson has been the defacto Java goto for JSON processing for a while. For Jackson, just use this dependence".

Another annoyance in this whole fiasco has been that the interwebs are littered with descriptions of how to use ResourceConfig...but there are multiple versions of ResourceConfig. What the fuck?

https://jersey.java.net/apidocs/2.4.1/jersey/org/glassfish/jersey/server/ResourceConfig.html
https://jersey.java.net/apidocs/1.1.5/jersey/com/sun/jersey/api/core/ResourceConfig.html

They have different interfaces. So you'll find a snippet like this, which pertains to the old 1.1.5 API. Thus totally confusing the fuck out of you: http://stackoverflow.com/questions/9490123/how-do-i-enable-pojo-mapping-programatically-in-jersey-using-grizzly2

Moxy blows. Jackson rules. Punk is out. Rap is in.

ActiveMQ: Your "Hello World" really should work...

I just downloaded ActiveMQ and started running the basic Publisher/Listener example. Now, sort of the first thing I would expect from this example would be that the count of received messages would be accurate. But alas, it seems all too common, for Hello World not to work.  Sure enough, Publisher publishes 10000 messages, Listener reports "Received 10001 in 1.66 seconds". One extra message! WTF. Ahh, I see, you're loop count is broken. Really?


Monday, August 10, 2015

Debugging deadlocks with Java's ReentrantLock


I recently experience a situation where my program just seemed to "stop". My first instinct was to use the Netbeans "check for deadlock" feature. Unfortunately, when Netbeans told me "no deadlock found". I still thought it was a deadlock. The app created dozens of threads, and the Netbeans debugger has a really crummy bug where the vertical slider repositions the threads viewport every time you pause a thread. This made it very difficult to see what was going on, but after a lot of clicking around I seemed to be able to determine that there was a thread waiting on a ReentrantLock. Every time I un-suspended the thread, it stayed at exactly the same place. Obviously someone was holding the lock. With the debugger, I could see a field inside the ReentrantLock called "exclusiveHolder" (or something like that), and by looking at the char array for the field, I could see the name of the other thread. Indeed this other thread was sitting trying to enter a synchronized method. From the call stack of the first thread I could see that the first thread already had entered the synchronized method. So it was a deadlock. To pin it down with certainty, I added these debug statements before attempting lock() on the lock instance.:

log.warn("attempting increment LOCK: " + lock +" w/ queue len  "+lock.getQueueLength());

 I also added this log4j configuration so that I could see the calling thread.


Fortunately, the toString method of ReentrantLock also prints the current owner of the lock.

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=WARN, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] [line=%L] [%M] %-5p %c %x - %m%n

The "%t" will show the calling thread. 




Thursday, July 16, 2015

Akka Respond When Ready Pattern (pause processing of messages)?

Perhaps someone has already solved this, or perhaps it is so simple what I've done is common sense. I am too new to Akka to know for sure. So here is the scenario:

  • An Actor we'll call Server needs to bootstrap itself. This takes some time.
  • Meanwhile, an Actor we can call Client begins to send Request messages to the server
  • ...but the server isn't ready yet.
The punchline, put long running initialization in preStart(). http://stackoverflow.com/questions/17061740/how-to-deal-with-long-initialization-of-an-akka-child-actor since messages will happily collect in the mailbox.
So, let's look to the more general case of what do do if an actor becomes unavailable for some reasonable period of time, not just at initialization. Here are the options I considered:
  • Server can discard messages any time it isn't available to respond (such as the bootstrap scenario)
    • Requires clients to wait a certain amount of time for a timeout, then resend.Requires client to keep track of/queue messages
  • Server can buffer messages when it is unable to respond, then handle them when ready
 I like the last solution the best. I browsed the akka docs on the thought that maybe they had something that does this. Low and behold: ReliableProxy is already available from Akka. At first I thought this was what I needed.
But I immediately realized that the message between E to B in the picture above suffers exactly the same problem as the message from A to B directly. So this is of no use. Therefore I implemented serverside buffering of messages during times it is unable to respond. When it is able to respnd it dequeues the messages and handles them. This is better than any option in which the client needs to take server "sleepiness" into consideration. I came across this stack overflow topic which affirms my design choice: http://stackoverflow.com/questions/9602322/akka-2-how-to-pause-processing-of-messageshttp://stackoverflow.com/questions/9602322/akka-2-how-to-pause-processing-of-messages

Friday, June 26, 2015

First reaction to Akka

Akka looks awesome. But never have I seen a more overdocumented framework. Every piece of docs is an exposition. Way too hard to find hello world. Most people today don't read docs top to bottom. We google "build akka" ...and we find this: http://doc.akka.io/docs/akka/snapshot/dev/building-akka.html

Any mention here of Maven being supported? Not that I saw. So I spent a while thinking I had to learn SBT. Then I found this page, which right at the top shows how to build with maven:

http://doc.akka.io/docs/akka/snapshot/intro/getting-started.html

But...WTF...the pom.xml they ship with doesn't include a connection to their repo! Have to add this:
Next we try to run some akka bins: ghendrey-mbp:akka-2.3.11 ghendrey$ ./bin/akka-cluster -bash: ./bin/akka-cluster: /bin/bash^M: bad interpreter: No such file or directory 

(yup, every bin script is borked with windows line returns and won't run)

LOL.

So how about we pop off the stack and try another approach:  http://doc.akka.io/docs/akka/2.0.1/intro/getting-started-first-java.html
 ...Follow the instructions..."
ghendrey-mbp:NetBeansProjects ghendrey$ cd akka/akka-tutorials/akka-tutorial-first
-bash: cd: akka/akka-tutorials/akka-tutorial-first: No such file or directory 
 
So after fixing the line breaks, fixing pom.xml, finding the right docs, finally hello world runs. Yeah. Now I try a more complex example.
Does it work?? NOPE. Exception spray:

 
 

Netbeans for c++

I have abandoned eclipse for c++ development on mac. Its "indexing" of large code basis was insanely slow (hours!!), and every now and then it would maddeningly begin redlining things again. I spent too many hours on it. It also can't debug with the current version of GDB. Spent so many hours in hell, compiling ancient versions of GDB. Ultimatly abandonded ship. The Eclipse UI was also vastly inferior to that of Netbeans. Just one of the irks is that the dropdown for open files doesn't display the files alphabetically. That's absurd. Then SWT look and feel, despite all the claims, isn't any faster than the Netbeans Swing-based UI. Does it look better? Nope. The icons in eclipse are outdated and the whole thing feels oldschool.

So...more or less happily  back to Netbeans. It has only one problem for c++ development. For some reason all method on STL classes, such as vector::push_back cannot be resolved and are redlined. I am willing to live with this since callgraph etc is all very fast. The same debugging issue exists on Netbeans as on eclipse but on Netbeans I found this workaround. If I run GDB server, using a netbeans plugin I can connect to GDB server and debug. The core problem you hit in both NB and eclipse is that the debugger will freeze on the first line you break at (not for any trivial hello world of course. But on every real project I actually need to work. Lot's of other people have run into it).

I speculate that it is some kind of race condition. By using GDB server, the connection to the breakpoint avoids the race.