New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parquet-related Utility Classes #264

Merged
merged 1 commit into from Jun 17, 2014

Conversation

Projects
None yet
5 participants
@tdanford
Contributor

tdanford commented Jun 10, 2014

This includes several utility classes that we wrote, as part of our work to adapt and re-use Parquet within Spark and ADAM.

One of our goals was to re-use as little Hadoop-specific functionality as possible, since disentangling Parquet from Hadoop was important (for a number of reasons, not least of which are class conflicts when it comes to wrapping HTTP services around a Spark cluster).

This PR includes three major components:

  • ByteAccess -- which is a trait whose implementations wrap any source of bytes to which random access is available
  • some classes that help us load and manage S3 and AWS credentials, and
  • FileLocator -- a trait whose implementations are a union of Hadoop's "Path" class, Java's File class, URLs, and pointers into S3.

Carl and I are eager to hear, though, if anyone objects to these implementations and would like to suggest an alternative class or type that already exists and does the same thing. We're eager not to re-invent too many wheels.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 10, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/365/

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 10, 2014

Contributor

That's an interesting failure, "cannot find 'git'."

Contributor

tdanford commented Jun 10, 2014

That's an interesting failure, "cannot find 'git'."

Show outdated Hide outdated adam-core/pom.xml
@@ -0,0 +1,75 @@
package org.bdgenomics.adam.util

This comment has been minimized.

@fnothaft

fnothaft Jun 11, 2014

Member

Missing header.

@fnothaft

fnothaft Jun 11, 2014

Member

Missing header.

This comment has been minimized.

@tdanford

tdanford Jun 11, 2014

Contributor

Good catch. Copy-and-paste from another place, argh.

@tdanford

tdanford Jun 11, 2014

Contributor

Good catch. Copy-and-paste from another place, argh.

}
}
private[util] case class ConfigurationFile(properties: Map[String, String]) extends Serializable {

This comment has been minimized.

@fnothaft

fnothaft Jun 11, 2014

Member

Instead of creating our own configuration file format and parser, can we reuse a format/parser that already exist?

@fnothaft

fnothaft Jun 11, 2014

Member

Instead of creating our own configuration file format and parser, can we reuse a format/parser that already exist?

This comment has been minimized.

@tdanford

tdanford Jun 11, 2014

Contributor

Mmm... I had problems using the Properties class from java.util (mostly centered around whitespace, I think). @carlyeks want to suggest an alternative?

@tdanford

tdanford Jun 11, 2014

Contributor

Mmm... I had problems using the Properties class from java.util (mostly centered around whitespace, I think). @carlyeks want to suggest an alternative?

This comment has been minimized.

@carlyeks

carlyeks Jun 11, 2014

Member

I agree we should probably move away from the custom format/parser. We don't currently have a configuration use case, so we'd be in uncharted waters. I'm always partial to Yaml (mainly because I'm allergic to XML), but I could be talked off a ledge.

@carlyeks

carlyeks Jun 11, 2014

Member

I agree we should probably move away from the custom format/parser. We don't currently have a configuration use case, so we'd be in uncharted waters. I'm always partial to Yaml (mainly because I'm allergic to XML), but I could be talked off a ledge.

This comment has been minimized.

@fnothaft

fnothaft Jun 11, 2014

Member

I'm OK with leaving this as is for now; we should open an issue to go back and clean this up.

BTW, downstream in avocado, I'm using Apache Commons Config, which seems to support many different formats, at the expense of being somewhat heavyweight.

@fnothaft

fnothaft Jun 11, 2014

Member

I'm OK with leaving this as is for now; we should open an issue to go back and clean this up.

BTW, downstream in avocado, I'm using Apache Commons Config, which seems to support many different formats, at the expense of being somewhat heavyweight.

This comment has been minimized.

@massie

massie Jun 12, 2014

Member

+1 on not creating our own configuration file parser.

@massie

massie Jun 12, 2014

Member

+1 on not creating our own configuration file parser.

This comment has been minimized.

@tdanford

tdanford Jun 13, 2014

Contributor

Okay, I'll work on ripping out this parser and replacing it with (maybe) Apache Commons Config, today.

@tdanford

tdanford Jun 13, 2014

Contributor

Okay, I'll work on ripping out this parser and replacing it with (maybe) Apache Commons Config, today.

Show outdated Hide outdated pom.xml
@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 11, 2014

Member

Jenkins, retest this please.

Member

fnothaft commented Jun 11, 2014

Jenkins, retest this please.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 11, 2014

Member

@tdanford @carlyeks this code looks good to me, but it's somewhat sparsely documented (see my comments above).

I'm concerned that ADAM isn't the best place to put this code. Perhaps it'd be best to create some sort of S3Utils/ParquetUtils/FileUtils project in bdgenomics that we put these in? My inking is that we may want to use this code later outside of ADAM(/other people may want to use this code), and that we wouldn't want to pull all of adam in to access just these classes. If you folks are interested in this, I can set up a repository, and work to get mvn deployment and Jenkins set up.

Member

fnothaft commented Jun 11, 2014

@tdanford @carlyeks this code looks good to me, but it's somewhat sparsely documented (see my comments above).

I'm concerned that ADAM isn't the best place to put this code. Perhaps it'd be best to create some sort of S3Utils/ParquetUtils/FileUtils project in bdgenomics that we put these in? My inking is that we may want to use this code later outside of ADAM(/other people may want to use this code), and that we wouldn't want to pull all of adam in to access just these classes. If you folks are interested in this, I can set up a repository, and work to get mvn deployment and Jenkins set up.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 11, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/366/

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 11, 2014

Contributor

Frank, we (Carl and I) are fine doing it in a different repository, if you want to set one up. However, we didn't think that this would ultimately go into ADAM, but rather, this is the first PR (of several) which supports our internal re-implementation of Parquet's metadata data structures and some indexing on top of Parquet files.

I think Carl and I were expecting that this code would ultimately be submitted to Parquet, but we were assuming that we could use ADAM as a way-station as part of our effort to quickly get it out of our private-only internal repos.

@massie thoughts?

Contributor

tdanford commented Jun 11, 2014

Frank, we (Carl and I) are fine doing it in a different repository, if you want to set one up. However, we didn't think that this would ultimately go into ADAM, but rather, this is the first PR (of several) which supports our internal re-implementation of Parquet's metadata data structures and some indexing on top of Parquet files.

I think Carl and I were expecting that this code would ultimately be submitted to Parquet, but we were assuming that we could use ADAM as a way-station as part of our effort to quickly get it out of our private-only internal repos.

@massie thoughts?

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 11, 2014

Member

@tdanford ah, I see. That should be OK then.

Member

fnothaft commented Jun 11, 2014

@tdanford ah, I see. That should be OK then.

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 11, 2014

Contributor

The ordering here, by the way, will be that once (1) this PR is merged, and (2) the flat genotype PR is merged, then there will be either one or two more PRs which contain Parquet-specific code. Mostly re-implementing a bunch of the internal Parquet data structures in Scala, followed by using them to build an RDD on top of parquet files directly, and then adding some code to index parquet files by genomic region and sample and then building an RDD using those indices.

The parquet classes themselves, along with the support classes (in this PR), are the ones that will go into Parquet ultimately I hope.

Contributor

tdanford commented Jun 11, 2014

The ordering here, by the way, will be that once (1) this PR is merged, and (2) the flat genotype PR is merged, then there will be either one or two more PRs which contain Parquet-specific code. Mostly re-implementing a bunch of the internal Parquet data structures in Scala, followed by using them to build an RDD on top of parquet files directly, and then adding some code to index parquet files by genomic region and sample and then building an RDD using those indices.

The parquet classes themselves, along with the support classes (in this PR), are the ones that will go into Parquet ultimately I hope.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 11, 2014

Member

Indexing support sounds pretty cool! I know @massie is very interested in these. BTW, @massie is working on fixing Jenkins. There's some issue where the VMs we use to run Jenkins went down... hopefully this will be resolved by the end of today.

Member

fnothaft commented Jun 11, 2014

Indexing support sounds pretty cool! I know @massie is very interested in these. BTW, @massie is working on fixing Jenkins. There's some issue where the VMs we use to run Jenkins went down... hopefully this will be resolved by the end of today.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 11, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/367/

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 11, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/368/

}
/**
* This is somewhat poorly named, it probably should be LocalFileByteAccess

This comment has been minimized.

@massie

massie Jun 12, 2014

Member

Isn't that what it's named?

@massie

massie Jun 12, 2014

Member

Isn't that what it's named?

This comment has been minimized.

@fnothaft

fnothaft Jun 12, 2014

Member

Jedi mind tricks...

@fnothaft

fnothaft Jun 12, 2014

Member

Jedi mind tricks...

This comment has been minimized.

@tdanford

tdanford Jun 12, 2014

Contributor

I forgot to remove that comment, when I renamed it in the most recent rebase.

@tdanford

tdanford Jun 12, 2014

Contributor

I forgot to remove that comment, when I renamed it in the most recent rebase.

This comment has been minimized.

@tdanford

tdanford Jun 13, 2014

Contributor

Fixed now.

@tdanford

tdanford Jun 13, 2014

Contributor

Fixed now.

override def length(): Long = f.length()
override def readByteStream(offset: Long, length: Int): InputStream = {
val fileIo = new FileInputStream(f)

This comment has been minimized.

@massie

massie Jun 12, 2014

Member

Same here. Create FileInputStream once and check markSupported and available?

@massie

massie Jun 12, 2014

Member

Same here. Create FileInputStream once and check markSupported and available?

This comment has been minimized.

@tdanford

tdanford Jun 13, 2014

Contributor

It would seem that FileInputStream.markSupported == false. @massie is that a Java 7 thing, or is that a platform-dependent thing? I don't know enough about how FileInputStream works to figure that out.

@tdanford

tdanford Jun 13, 2014

Contributor

It would seem that FileInputStream.markSupported == false. @massie is that a Java 7 thing, or is that a platform-dependent thing? I don't know enough about how FileInputStream works to figure that out.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 13, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/370/

@massie

This comment has been minimized.

Show comment
Hide comment
@massie

massie Jun 14, 2014

Member

Jenkins, test this please.

Member

massie commented Jun 14, 2014

Jenkins, test this please.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 14, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/371/

@massie

This comment has been minimized.

Show comment
Hide comment
@massie

massie Jun 14, 2014

Member

Jenkins, test this please.

Member

massie commented Jun 14, 2014

Jenkins, test this please.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 14, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/372/

@massie

This comment has been minimized.

Show comment
Hide comment
@massie

massie Jun 16, 2014

Member

Jenkins, test this please.

Member

massie commented Jun 16, 2014

Jenkins, test this please.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins commented Jun 16, 2014

Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/378/

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 16, 2014

Member

Jenkins, retest this please.

Looks like a network address bind error...

Member

fnothaft commented Jun 16, 2014

Jenkins, retest this please.

Looks like a network address bind error...

@carlyeks

This comment has been minimized.

Show comment
Hide comment
@carlyeks

carlyeks Jun 16, 2014

Member

Jenkins recovers from those network bind errors, but the jar file is invalid; it is failing the intergration test in the very last few lines of the output. @tdanford suggested that we are probably not shading the jar file correctly (seems plausible), so we will have to fix this.

Tests save the day!!

Member

carlyeks commented Jun 16, 2014

Jenkins recovers from those network bind errors, but the jar file is invalid; it is failing the intergration test in the very last few lines of the output. @tdanford suggested that we are probably not shading the jar file correctly (seems plausible), so we will have to fix this.

Tests save the day!!

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 16, 2014

Contributor

Ugh. Yeah.

Contributor

tdanford commented Jun 16, 2014

Ugh. Yeah.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 16, 2014

Member

Ah, fascinating! Does this show up on your end as well, or just in Jenkins?

Member

fnothaft commented Jun 16, 2014

Ah, fascinating! Does this show up on your end as well, or just in Jenkins?

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 16, 2014

Contributor

It does show up on our end. It is very confusing (I was saying this in IRC too), here's the rundown as we have it so far.

The current master builds a fine jar file, but (if you look in our repo), commit 37c7060 produces a build which fails. All that commit does is include the AWS SDK.

Okay, so, looking at the "corrupt" jar a little more closely -- if you do
java -jar adam-0.11.1-SNAPSHOT.jar
fails. But if you do,
java -cp adam-0.11.1-SNAPSHOT.jar org.bdgenomics.adam.cli.ADAMMain

it works fine! Weird. So we figured it was the MANIFEST.MF files, but ... they are identical between jars. So now we're at the point where we're diffing pieces of the unpacked jars and trying to guess what's going wrong.

Anyone else have any ideas?

Contributor

tdanford commented Jun 16, 2014

It does show up on our end. It is very confusing (I was saying this in IRC too), here's the rundown as we have it so far.

The current master builds a fine jar file, but (if you look in our repo), commit 37c7060 produces a build which fails. All that commit does is include the AWS SDK.

Okay, so, looking at the "corrupt" jar a little more closely -- if you do
java -jar adam-0.11.1-SNAPSHOT.jar
fails. But if you do,
java -cp adam-0.11.1-SNAPSHOT.jar org.bdgenomics.adam.cli.ADAMMain

it works fine! Weird. So we figured it was the MANIFEST.MF files, but ... they are identical between jars. So now we're at the point where we're diffing pieces of the unpacked jars and trying to guess what's going wrong.

Anyone else have any ideas?

@carlyeks

This comment has been minimized.

Show comment
Hide comment
@carlyeks

carlyeks Jun 17, 2014

Member

I think we have discovered the source of the issue: ZIP doesn't support as many entries as we now have in our uber jar. We have over 74000 with the addition of the AWS SDK dependency, with the limit being 65535.
One solution is to use minimizeJar, which searches for the classes which are actually referenced in the jar file; however, if something is referenced by name only (as in log4j dependencies), they will not be included in the jar. Another potential solution is getting maven to use ZIP64 (which is supposedly supported by Java 7) -- haven't figured out how to do this one yet.

Member

carlyeks commented Jun 17, 2014

I think we have discovered the source of the issue: ZIP doesn't support as many entries as we now have in our uber jar. We have over 74000 with the addition of the AWS SDK dependency, with the limit being 65535.
One solution is to use minimizeJar, which searches for the classes which are actually referenced in the jar file; however, if something is referenced by name only (as in log4j dependencies), they will not be included in the jar. Another potential solution is getting maven to use ZIP64 (which is supposedly supported by Java 7) -- haven't figured out how to do this one yet.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 17, 2014

Member

Nice! I did some grepping, and it looks like Maven's assembly plugin should support ZIP64. It doesn't seem to be documented well, but here's the general "chain" of resources I found pointing to this:

I can take a look at this in the PM, if necessary.

Member

fnothaft commented Jun 17, 2014

Nice! I did some grepping, and it looks like Maven's assembly plugin should support ZIP64. It doesn't seem to be documented well, but here's the general "chain" of resources I found pointing to this:

I can take a look at this in the PM, if necessary.

@carlyeks

This comment has been minimized.

Show comment
Hide comment
@carlyeks

carlyeks Jun 17, 2014

Member

Since the AmazonAWS SDK is 8.8k files by itself (...), I changed that to a provided, so that at least it compiles again.
The problem with the minimizeJars is the log4j and the hadoop dependencies are all mentioned by string name (and thus fail), so it seems like a can of worms trying to get that to work.
I think the easiest longer term fix is to ZIP64 the uberjar.

Member

carlyeks commented Jun 17, 2014

Since the AmazonAWS SDK is 8.8k files by itself (...), I changed that to a provided, so that at least it compiles again.
The problem with the minimizeJars is the log4j and the hadoop dependencies are all mentioned by string name (and thus fail), so it seems like a can of worms trying to get that to work.
I think the easiest longer term fix is to ZIP64 the uberjar.

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 17, 2014

Contributor

Carl and I actually disagree on this -- I am leaning towards not creating an uber-jar at all, as part of any (truly) long-term fix.

Contributor

tdanford commented Jun 17, 2014

Carl and I actually disagree on this -- I am leaning towards not creating an uber-jar at all, as part of any (truly) long-term fix.

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins Jun 17, 2014

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/384/

AmplabJenkins commented Jun 17, 2014

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/384/

@carlyeks

This comment has been minimized.

Show comment
Hide comment
@carlyeks

carlyeks Jun 17, 2014

Member

Now we're cooking with gas.

Member

carlyeks commented Jun 17, 2014

Now we're cooking with gas.

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 17, 2014

Contributor

Should we squash these commits down too? (By the way, I'm still confused as to why the 'java -cp' approach, outlined above, worked when 'java -jar' didn't.)

Contributor

tdanford commented Jun 17, 2014

Should we squash these commits down too? (By the way, I'm still confused as to why the 'java -cp' approach, outlined above, worked when 'java -jar' didn't.)

@carlyeks

This comment has been minimized.

Show comment
Hide comment
@carlyeks

carlyeks Jun 17, 2014

Member

Luck of the jar, my friend.

Probably warrants some investigation...

Member

carlyeks commented Jun 17, 2014

Luck of the jar, my friend.

Probably warrants some investigation...

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 17, 2014

Contributor

I've rebased this PR on top of master and down into the (original) four commits, which are each somewhat standalone but do actually build off each other.

I can rebase down into a single commit though, if anyone cares.

Contributor

tdanford commented Jun 17, 2014

I've rebased this PR on top of master and down into the (original) four commits, which are each somewhat standalone but do actually build off each other.

I can rebase down into a single commit though, if anyone cares.

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 17, 2014

Contributor

"Luck of the jar, my friend."

-- I think you mean, "jarnanigans."

Contributor

tdanford commented Jun 17, 2014

"Luck of the jar, my friend."

-- I think you mean, "jarnanigans."

@carlyeks

This comment has been minimized.

Show comment
Hide comment
@carlyeks

carlyeks Jun 17, 2014

Member

"jarish"?

Member

carlyeks commented Jun 17, 2014

"jarish"?

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins Jun 17, 2014

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/385/

AmplabJenkins commented Jun 17, 2014

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/385/

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 17, 2014

Member

I have a general preference towards the commits being squashed down, otherwise, looks good!

Member

fnothaft commented Jun 17, 2014

I have a general preference towards the commits being squashed down, otherwise, looks good!

Utility classes for Parquet reimplementation in Scala.
The following changes were made as part of this commit:

* Added a dependency on the AWS Java SDK.

This dependency is listed as 'provided', because the AWS SDK for Java adds 8k+ classes,
which pushes our uber-jar over the standard 65k file limit in the Zip archive.

* Added ByteAccess trait and implementations.

ByteAccess is a trait representing "sources of bytes" for which random access is available,
e.g. local files, S3, etc. This is going to be used to wrap different data storage back-ends,
for raw byte access and allowing us to go around the hadoop library itself.

* Added SerializableAWSCredentials is an AWSCredentials which is Serializable.

We're going to need to pass around (serializable) credentials for S3, in order to
implement our ParquetRDD that reads directly from S3.

* Added CredentialsProperties encapsulates reading AWS credentials from configuration.

This is a wrapper class, designed to allow us to recognize and retrieve credentials from
the environment, config files, or other sources.

* Added FileLocator and implementations.

FileLocator, and its implementations, are a common wrapper around local Files, classpath locations,
bucket/keyname pairs in S3, and static byte arrays (for testing).  This is a way (also serializable)
for naming the location of parquet files and indices in different systems.
@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 17, 2014

Contributor

Squashed!

Contributor

tdanford commented Jun 17, 2014

Squashed!

@AmplabJenkins

This comment has been minimized.

Show comment
Hide comment
@AmplabJenkins

AmplabJenkins Jun 17, 2014

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/386/

AmplabJenkins commented Jun 17, 2014

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/386/

fnothaft added a commit that referenced this pull request Jun 17, 2014

@fnothaft fnothaft merged commit 86ed049 into bigdatagenomics:master Jun 17, 2014

1 check passed

default Merged build finished.
Details
@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Jun 17, 2014

Member

Merged! Thanks @carlyeks and @tdanford!

Member

fnothaft commented Jun 17, 2014

Merged! Thanks @carlyeks and @tdanford!

@tdanford tdanford deleted the broadinstitute:parquet-utils-rebase branch Jun 17, 2014

@tdanford

This comment has been minimized.

Show comment
Hide comment
@tdanford

tdanford Jun 17, 2014

Contributor

Awesome. Thanks Frank!

Contributor

tdanford commented Jun 17, 2014

Awesome. Thanks Frank!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment