Scala

.gitignore

@@ -2,3 +2,5 @@
 .Rhistory
 .RData
 .Ruserdata
+.DS_Store
+

R/.gitignore

@@ -0,0 +1,8 @@
+.Rproj.user
+.Rhistory
+.RData
+.Rproj
+.DS_Store
+src/*.o
+src/*.so
+src/*.dll

README.md

@@ -1,3 +1,3 @@
 # 2020 Advent of Code
 
-Solutions in R, Swift, javascript, Python (in the `R` dir since I'm using RStudio's Python REPL) and mebbe others
+Solutions in R, Swift, Scala, javascript, Python (in the `R` dir since I'm using RStudio's Python REPL) and mebbe others

scala/.gitignore

@@ -0,0 +1,42 @@
+# sbt
+# (may want to keep parts of 'project')
+bin/
+project/
+target/
+build/
+
+# eclipse
+build
+.classpath
+.project
+.settings
+.worksheet
+
+# intellij idea
+*.log
+*.iml
+*.ipr
+*.iws
+.idea
+
+# mac
+.DS_Store
+
+# other?
+.history
+.scala_dependencies
+.cache
+.cache-main
+
+#general
+*.class
+
+dist/*
+target/
+lib_managed/
+src_managed/
+project/boot/
+project/plugins/project/
+.history
+.cache
+.lib/

scala/01/01/.bsp/sbt.json

@@ -0,0 +1 @@
+{"name":"sbt","version":"1.4.3","bspVersion":"2.0.0-M5","languages":["scala"],"argv":["/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin/java","-Xms100m","-Xmx100m","-classpath","/Users/hrbrmstr/.sdkman/candidates/sbt/1.4.4/bin/sbt-launch.jar","xsbt.boot.Boot","-bsp"]}

scala/01/01/build.sbt

@@ -0,0 +1,77 @@
+
+// The simplest possible sbt build file is just one line:
+
+scalaVersion := "2.13.3"
+// That is, to create a valid sbt build, all you've got to do is define the
+// version of Scala you'd like your project to use.
+
+// ============================================================================
+
+// Lines like the above defining `scalaVersion` are called "settings". Settings
+// are key/value pairs. In the case of `scalaVersion`, the key is "scalaVersion"
+// and the value is "2.13.3"
+
+// It's possible to define many kinds of settings, such as:
+
+name := "hello-world"
+organization := "ch.epfl.scala"
+version := "1.0"
+
+// Note, it's not required for you to define these three settings. These are
+// mostly only necessary if you intend to publish your library's binaries on a
+// place like Sonatype or Bintray.
+
+
+// Want to use a published library in your project?
+// You can define other libraries as dependencies in your build like this:
+
+libraryDependencies += "org.scala-lang.modules" %% "scala-parser-combinators" % "1.1.2"
+
+// Here, `libraryDependencies` is a set of dependencies, and by using `+=`,
+// we're adding the scala-parser-combinators dependency to the set of dependencies
+// that sbt will go and fetch when it starts up.
+// Now, in any Scala file, you can import classes, objects, etc., from
+// scala-parser-combinators with a regular import.
+
+// TIP: To find the "dependency" that you need to add to the
+// `libraryDependencies` set, which in the above example looks like this:
+
+// "org.scala-lang.modules" %% "scala-parser-combinators" % "1.1.2"
+
+// You can use Scaladex, an index of all known published Scala libraries. There,
+// after you find the library you want, you can just copy/paste the dependency
+// information that you need into your build file. For example, on the
+// scala/scala-parser-combinators Scaladex page,
+// https://index.scala-lang.org/scala/scala-parser-combinators, you can copy/paste
+// the sbt dependency from the sbt box on the right-hand side of the screen.
+
+// IMPORTANT NOTE: while build files look _kind of_ like regular Scala, it's
+// important to note that syntax in *.sbt files doesn't always behave like
+// regular Scala. For example, notice in this build file that it's not required
+// to put our settings into an enclosing object or class. Always remember that
+// sbt is a bit different, semantically, than vanilla Scala.
+
+// ============================================================================
+
+// Most moderately interesting Scala projects don't make use of the very simple
+// build file style (called "bare style") used in this build.sbt file. Most
+// intermediate Scala projects make use of so-called "multi-project" builds. A
+// multi-project build makes it possible to have different folders which sbt can
+// be configured differently for. That is, you may wish to have different
+// dependencies or different testing frameworks defined for different parts of
+// your codebase. Multi-project builds make this possible.
+
+// Here's a quick glimpse of what a multi-project build looks like for this
+// build, with only one "subproject" defined, called `root`:
+
+// lazy val root = (project in file(".")).
+//   settings(
+//     inThisBuild(List(
+//       organization := "ch.epfl.scala",
+//       scalaVersion := "2.13.3"
+//     )),
+//     name := "hello-world"
+//   )
+
+// To learn more about multi-project builds, head over to the official sbt
+// documentation at http://www.scala-sbt.org/documentation.html

scala/01/01/src/main/scala/Main.scala

@@ -0,0 +1,29 @@
+// See R or Python code for today's challenge description
+
+object Main extends App {
+
+  val bufferedSource = io.Source.fromFile("/Users/hrbrmstr/Development/2020-code-advent/input/01-01.txt")
+  val input = (for (line <- bufferedSource.getLines()) yield line.toInt).toList
+  bufferedSource.close
+  
+  // 01-01
+
+  val pairs = input.combinations(2).toSeq
+  
+  var sums = pairs.map { _.reduce((a, b) => a + b )}
+
+  var idx = sums.indexOf(2020)
+  
+  println(pairs(idx).reduce { (a, b) => a * b })
+
+  // 01-02
+
+  var tri = input.combinations(3).toSeq
+
+  sums = tri.map { _.reduce((a, b) => a + b )}
+
+  idx = sums.indexOf(2020)
+
+  println(tri(idx).reduce { (a, b) => a * b })
+
+}