Scrayz

Work has finally slowed down enough that I have inched my Scala based ray tracer along, just a tiny bit. I'm keeping the code on gitla...

March 9, 2020

Scrayz

Work has finally slowed down enough that I have inched my Scala based ray tracer along, just a tiny bit.

I'm keeping the code on gitlab this time, and so far it has been different, but problem free.  CI is built in on GitLab, but it did take a bunch of fiddling due to me not understanding a bunch of stuff, and out of date docs (of course).  So, on the CI side of things, I think it will run my tests on push now. Next up will be to enable Coveralls, "just because".


Now that I have that going, I started flipping through the book a little bit again.

The first step (after reading) is to get the tests written.  Luckily there are files full of features to start with. So, that's exactly what I'm going to do using ScalaTest. It supports multiple styles, but to stay with the style in the book, I'm going to use FeatureSpec.

Itt is fairly straightforward at the top-most level to get the tests in a format ScalaTest likes:

import org.scalatest.FeatureSpec         
import org.scalatest.GivenWhenThen               

class TupleFeatures extends FeatureSpec with GivenWhenThen {
  feature("Tuples, Vectors, and Points") {

    scenario("A tuple with w=1.0 is a point") {
      Given("a ← tuple(4.3, -4.2, 3.1, 1.0)")
      Then("a.x = 4.3")               
      And(" a.y = -4.2")                      
      And(" a.z = 3.1")              
      And(" a.w = 1.0")                                  
      And(" a is a point")      
      And(" a is not a vector")  
    } 
  }
}



So, the next step there is to figure out where and how you write the background steps that set things up for you.


While flipping through the book again, it started off with Tuples. I thought I knew what to do but there is a slight rub.  The book uses four values (x, y, z, w) where the "thing" is a point of w = 1.0 and a vector if w = 0.0. I may be able to do something with the type system to handle this, I'm not sure.

My first thought was to not try to combine them at all, so after some failed attempts and a StackOverflow question, I ended up going down this road:

package com.craigtreptow.scrayz

package object types {
  final case class X(v: Double) extends AnyVal
  final case class Y(v: Double) extends AnyVal
  final case class Z(v: Double) extends AnyVal
  final case class Point(x: X, y: Y, z: Z)
}


package com.craigtreptow.scrayz.types

object Main extends App {
  val x: X = X(1.1)
  val y: Y = Y(2.2)
  val z: Z = Z(3.3)
  val p: Point = Point(x, z, z)

  println(p)
  println(p.x)
  println(p.y)
  println(p.z)
}


We'll see if this works out, but, hey, it's a place to start.

January 27, 2020

My First Taste of Pattern Matching in Scala

I just got a taste of some pattern matching in Scala. It was not really like what I had scene in Elixir or Haskell, but seems straight forward enough. In this case we match on some String attributes:



What made it slightly awkward, I guess, was the have to explicitly use the "match" keyword to say "I'm going to match here", but use the full class name and attributes. I guess it is just a bit "weird" to my eyes. There very well may be slicker ways to do this when I get into the more "hard core" FP techniques that I assume I will see in this book (or another).

All in all, I'm still enjoying Scala and this is just another thing to file away in the Scala portion of my brain.

January 22, 2020

A real quick Scala tip

For my purposes of learning Scala, I generally want to follow the compile, then run model. I didn't want to get into a whole IDE, so I'm still using vim and doing this from the command line. For this to work, however, I needed to extend App, like this:



The key bits are to extend App, and the name you use for the object must be used when running it. So you could name it calc, but then you must also run it with "scala calc", not "scala Calc".

This allows you to catch typos with the compiler and do some simple testing with the asserts. Later, I'll figure out how to integrate a test suite, but not today.

January 20, 2020

More Scala, More Questions

I've started on the Scala Exercises and have learned some tiny tidbits, which lead to more questions.

One thing that was stated in a section titled "Functional Loops", is that you may use '@tailrec' to enforce using a tail call.  I had never seen this, or quite honestly, thought of such a thing myself.  I find this pretty interesting.  The page says "In Scala, only directly recursive calls to the current function are optimized."  So, it is mostly (only) about optimizations, which is more to say memory requirements will stay constant since the stack won't grow out of control.  I suspect I mostly won't notice any issues surrounding this, but ya never know.

Here's an example of the above:



I'm ready to start muddling through a project so I can learn more about how things are tested, and how to start working with Scala in something slightly bigger than tiny little trivial functions. In a section titled "Lexical Scoping" I learned that you can add a 'package' declaration to control which definitions are seen where. So, you might add a 'package foo' to a file forcing all definitions in that file under the 'foo' package and thereby limiting the scope so other packages cannot accidentally see definitions they shouldn't. The example indicated that you might have a function "Bar" in a file "foo/Bar.scala", with a 'package foo' declaration. Ok, but is that file structure enforced? My suspicion is that it is enforced, because this ends up on the JVM.

This brings up another question. Is there a utility to generate a "correct" project structure? Elixir has the 'mix' tool for this (and many other) uses. I'm only aware of the 'sbt' (Scala Build Tool) at the moment. Judging from this old SO question it isn't the solved problem I was hoping for, but I don't know much so it might be once I learn what G8 is, I guess.

Time for some more Scala.

January 18, 2020

Haskell to Scala

I had no real expectations for Haskell when I started to learn it. Now, after going through a few books on it, I've been unable to get to the point where I want to really dive in and attempt my "go to" project of building a ray tracer with it. It's been very good to see other ideas about building software, but I haven't gotten over that "hump".

There is a language that I feel differently about after only a few days: Scala. I've known of it's existence for a long time, but never really looked at it.  Then I started listening to the CoRecursive podcast, and the host, Adam, works in Scala.  Around that same time, I saw some Haskell people posting about people attempting to "de-platform" a Scala person.  Well, that person was John De Goes.  I've found him to be nothing but helpful and pretty nice online.  He's also contributed a concurrent library called ZIO to the Scala world.

So, with all that, and my slight dissatisfaction with the Haskell language (and community) I finally "committed" in my head to learning Scala.

I haven't found "the right book" yet, but I did discover the Scala exercises site.  So far, I like the way they combined reading with answering questions via fields that are checked with Scala.  I started with the track called "Scala Tutorial".  It is providing a little background and "big picture" as well as the more straight forward facts about language features.  I'll need to read a little more before I learn how to organize a project and can begin muddling through The Ray Tracer Challenge, though.

Scala seems to tick all my boxes: it is FP (and OOP FWIW), has a compiler(I just like that step), is probably pretty fast (being on the JVM), but also allows for native binaries, and has browser/Web Assembly targets.  I think the "big ideas" from Haskell are in there, so I'm hopeful and excited about it.