Posts Tagged java

making m2 salad

March 25, 2010 at 8:00 pm · Filed under java, scripting ·Tagged , , ,

Irrelevant Silliness

So… I’m a vim hold out. I still care deeply about emacs and it’s spawn being defeated once and for all.

Which means I don’t really like bloated IDE’s like Eclipse…. which makes me a pariah… which means people whisper and plot against me behind my back…

And… they’re always out to get me… and…

Ahem… sorry, about that… Like I was saying….

Which means I prefer to write a lot of tools and utilities to provide the sort of out-of-the-box functionality other people are perfectly happy to point and click thru with their brains in the neutral gear.

It’s part of a sickness I have… and I am going to confess it here on the internet: I love programming computers.

I know, I know… appalling! The gall! But there it is! My dirty little secret!

So what have I brewed up this time?

You know that functionality which lets you see right click and see methods, etc in Eclipse?

I thought it would be nice to have something like it for the CLI where I can use grep the way the Lawd intended. Here is the soup-to-nuts for nuts.

Finally he gets to the point

% m2_salad.sh 
m2_cp.txt is older than pom.xml... rebuilding m2_cp.txt
m2_soup.txt is older than m2_cp.txt... rebuilding m2_soup.txt
m2_salad.txt is older than m2_soup.txt... rebuilding m2_salad.txt

Zounds! So I wrote 2 new scripts: m2_soup.sh and m2_salad.sh.

Like m2_cp.sh, each produces a file named X.txt with some junk in it.

Here is the breakdown:

m2_cp.txt      colon separated list of the jars maven uses
m2_soup.txt    list of all the classes defined in the m2_cp.txt jars
m2_salad.txt   javap of all the classes listed in m2_soup.txt

These along with the standard UNIX CLI utils provides the same sort of handy lookup funtionality, where it belongs: in the CLI, not in the editor.

And?

Well… OK, maybe it could live in the editor too if it was slim-and-fast and minimalist…

I’ve really enjoyed the vim plugin supertab for tab completion.

Part of the challenge of integrating it with the output from the scripts is to make the completion be contextual… Which means a plugin would have to have some notion of the program semantics.

For example, it would need to know that a piece of text was a variable and what it’s type was so it could lookup the appropriate methods.

Not easy, but I’m a big believer in the 90/10 rule.

Alternatively… what other sort of useful development application could be written leveraging this info?

Good times… good times…

Leave a Comment

java generic boo-hoo

January 20, 2010 at 4:35 am · Filed under development ·Tagged , ,

Found another soft spot in Java’s generics

public < C extends java.util.Collection, T > C works( C c, T ... ts ) {
        for ( T t : ts ) c.add( t );
        return c;
}

public < C extends java.util.Collection, T > C broke( C< T > c, T ... ts ) {
        for ( T t : ts ) c.add( t );
        return c;    
}

Sort of surprised me the latter didn’t work… but the works version was enuff to get ‘er done.

Eh…

Here is the err:

unexpected type
found   : type parameter C 
required: class

Leave a Comment

Print the name of any class in a jar that has a main method:

December 23, 2009 at 5:14 pm · Filed under java, scripting ·Tagged , , ,

Print the name of any class in a jar that has a main method:

jar="output/opennlp-tools-1.4.3.jar"
javap -classpath ${jar} $(     
    jar tf ${jar}      \
    | grep ass$        \
    | cut -f1 -d.      \
    | tr '[$/]' .      
) \ 
| tr '\n' '@'          \
| sed 's,}@,}=,g'      \
| tr '=' '\n'          \
| grep -w main         \
| tr '@' '\n'          \
| grep '^public class' \
| awk '{print $3}'

Leave a Comment

The Stanford Parser is neat

December 23, 2009 at 2:37 pm · Filed under java, nlp ·Tagged , ,

The Stanford Parser: A statistical parser is a pretty neat piece of GPL java code does all kinds of wild text processing.

It can parse a sentence and create a dependency graph that relates each word and includes POS-tagging. Gadzooks!

I had to change the script to use 512m instead of 150m to process even pretty small files…

% ./lexparser.csh f
Loading parser from serialized file ./englishPCFG.ser.gz ... done [2.1 sec].
f
Parsing file: f with 1 sentences.
Parsing [sent. 1 len. 24]: [The, Stanford, Parser, :, A, statistical, parser, is, a, pretty, neat, piece, of, GPL, java, code, does, all, kinds, of, wild, text, processing, .]
(ROOT
  (NP
    (NP (DT The) (NNP Stanford) (NNP Parser))
    (: : )
    (S 
      (NP (DT A) (JJ statistical) (NN parser))
      (VP (VBZ is)
        (NP
          (NP (DT a)
            (ADJP (RB pretty) (JJ neat))
            (NN piece))
          (PP (IN of)
            (NP (NNP GPL)))
          (SBAR 
            (S
              (NP (NN java) (NN code))
              (VP (VBZ does)
                (NP
                  (NP (DT all) (NNS kinds))
                  (PP (IN of)
                    (NP (JJ wild) (NN text) (NN processing))))))))))
    (. .)))         
    
det(Parser-3, The-1)
nn(Parser-3, Stanford-2)
det(parser-7, A-5)
amod(parser-7, statistical-6)
nsubj(piece-12, parser-7)
cop(piece-12, is-8)
det(piece-12, a-9)
advmod(neat-11, pretty-10)
amod(piece-12, neat-11)
dep(Parser-3, piece-12)
prep_of(piece-12, GPL-14)
nn(code-16, java-15)
nsubj(does-17, code-16)
rcmod(piece-12, does-17)
det(kinds-19, all-18)
dobj(does-17, kinds-19)
amod(processing-23, wild-21)
nn(processing-23, text-22)
prep_of(kinds-19, processing-23)

Parsed file: f [1 sentences].
Parsed 24 words in 1 sentences (17.28 wds/sec; 0.72 sents/sec).

Leave a Comment

lame java collection erasure problem

October 28, 2009 at 12:50 pm · Filed under java ·Tagged ,

Just ran into an example of where Java’s dumb erasure strategy just didn’t cut it.

I wrote a small class to collect up vararg junk into typed collections, something like:

public class Collector {
    public Collection collect( typename... vs ) {...}
    public Collection collect( Collection collection, typename... vs ) {...}
};

This worked fine up until the point where the typename was a typed collection, at which point the second method was invoked instead.

My work around was to rename the latter to “collectInto”

Lame…

Leave a Comment

Older Posts »