mernst / plume-lib

A library of useful abstractions for programming. Obsolete, use https://github.com/plume-lib/ instead.

Monolithic plume-lib: a library of utilities for programming

Monolithic plume-lib is obsolete! This package, called monolithic plume-lib, is obsolete. As of August 2018, it has been split into many smaller packages Each one is smaller and more focused.

• The Java libraries are conveniently available from the Maven Central Repository.
• Obtain the Java programs, and the non-Java libraries and programs, from their repositories.

The old documentation for monolithic plume-lib is still available:

• in file docs/index.html , or
• at the plume-lib homepage: https://mernst.github.io/plume-lib/

plume-lib's Issues

JavaDoc errors in ArraysMDE

In plume-lib/java/src/plume/ArraysMDE.java there is a subarray testing section starting ~ line 1167
the methods (isSubarray and isSubarrayEq) have:

• @return the first index at which the second array starts in the first array,
• or -1 if the element is not found in the array

in the javadoc but they return booleans

Access denied

Dear Mernst,

I'm not sure for me does this not work.
I receive access denied for the curl request.

Have you a suggestion?

Question for trigger travis script

Dear @mernst,

I'm using your trigger travis script.
However, I cannot get it to work if I have to trigger a build from another organization,
i.e. I want to trigger a build of a repository from another organization.

Do you have an idea how to adapt?

Checker Framework annotation warnings when compiling against release version of plume.jar

When including plume.jar from the release, there were are warnings due to Checker Framework annotations:

1. classfile version warnings, which can be suppressed by -Xlint:-classfile
2. missing symbol warnings, which can be suppressed by including checker-qual.jar in the classpath. I'm told that type annotations in plume are in the comments, and so the release version could be built without needing the checker framework jar.

Options doclet does not correctly print first Option in an OptionGroup

If an option is the first option in an OptionGroup, the options doclet does not 
print out the Javadoc comment, for the option, it only prints out the one-line 
version.

Example: option --string-maxlen in

http://randoop.googlecode.com/hg/doc/index.html#command-line-options

The declaration for this option is here:

http://code.google.com/p/randoop/source/browse/src/randoop/main/GenInputsAbstrac
t.java#168

Original issue reported on code.google.com by [email protected] on 16 Aug 2010 at 12:00

Feature request: allow enum Option values to be types in lowercase

Feature request: if an Option's type is an enum, the user should be able to 
specify the option's value in lowercase letters. It appears that currently the 
option value must be types in uppercase letters.

Original issue reported on code.google.com by [email protected] on 16 Aug 2010 at 12:02

Using SimpleLog with @Option

The plume.SimpleLog class provides a nice way to perform logging, with the ability to log to both a file or to standard out. However, a SimpleLog cannot be used with @Option. Ideally, this would be possible with the ability for the user to indicate whether to use a file or standard out.

OptionsDoclet does not include options in inner classes

Currently, the OptionsDoclet Javadoc doclet ignores inner classes.  This is 
because I do not have a good solution to the following problem: given a 
ClassDoc instance 'cd' which refers to class A, how do you get a Class<?> 
instance corresponding to A?

Originally, I used 'Class.forName(cd.qualifiedName())'.  This approach fails 
when cd is an inner class.

The documentation for Class.forName() says the first parameter to this method 
is a String representing the fully qualified name of a class.  This is false.  
In fact, the first parameter to Class.forName() must be a string representing 
the *binary* name of the desired class.  So what we have is cd.qualifiedName() 
correctly returning a fully qualified name, and Class.forName() expecting a 
binary name.  Usually, when inner classes are not being used, this distinction 
wont matter since the FQN and binary name are the same.  But with Javarifier, 
which has inner classes in its main class, we have the following:

   javarifier.Main$JrTransformer is a binary name.
   javarifier.Main.JrTransformer is a fully qualified name.

The Class.forName() method fails on the FQN of this class.

One solution would be a general method to translate from a fully qualified name 
to a binary name.  This method has to be robust and work correctly on all 
cases.  Another solution is to use calls to 'cd.containingClass()' to determine 
which classes are inner classes and then make the appropriate replacements of 
dots with dollar signs in the fully qualified name.  Better yet, perhaps there 
is a method of going from ClassDoc to Class<?> without using strings or names 
at all.  For now, my solution is to simply ignore any classes that are 
contained within other classes.  This means any @Option annotations in inner 
classes will not be included in the generated HTML documentation.

Original issue reported on code.google.com by david.lazar on 8 Jul 2010 at 6:03

Java home on OSX

Makefile does not work on Mac b/c of of missing JAVA_HOME.
According to following, convention on OS X since 10.5 is to use command /usr/libexec/java_home that returns home directory: https://developer.apple.com/library/mac/qa/qa1170/_index.html

patch.txt

Feature Request: configurable travis-ci.com

Having the ability to override trigger-travis.sh to use travis-ci.com could be beneficial

plume won't build with Java5

What steps will reproduce the problem?
1. clone repo
2. tried to make it with bin/make-plume-release 
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
latest, on OSX 10.5, apple's java5

Please provide any additional information below.
trying to make (build) a JAva5 compatible randoop.jar, got stuck with plume..

Thanks
Zoltan

Original issue reported on code.google.com by [email protected] on 24 Nov 2010 at 9:07

CLASSPATH parsing for .classpath

.classpath may contain other fields like "sourcepath" in addition to "path", but the embedded perl one-line matches all strings after "path". There is no problem for .classpath on HEAD, however eclipse may modify/add fields. Here is a dirty fix.

diff --git i/common.mk w/common.mk
index 1de01f5..55364a9 100755
--- i/common.mk
+++ w/common.mk
@@ -11,7 +11,7 @@ CLASS_DIRS := $(RANDOOP_HOME)/bin $(RANDOOP_HOME)/tests
 # order of the files.

 # Use the same order of jar files as in .classpath
-CLASSPATH_WITH_SPACES := $(RANDOOP_EXTRA_CLASSPATH):$(CLASS_DIRS):$(shell perl -n -e 'if (/kind="lib" path="(.*)"\/>/) { print ":$(RANDOOP_HOME)/$$1"; }' $(RANDOOP_HOME)/.classpath)
+CLASSPATH_WITH_SPACES := $(RANDOOP_EXTRA_CLASSPATH):$(CLASS_DIRS):$(shell perl -n -e 'if (/kind="lib" path="([\S]*)"(.*)\/>/) { print ":$(RANDOOP_HOME)/$$1"; }' $(RANDOOP_HOME)/.classpath)

 # Convert to a standard classpath
 empty:=