bit of responsiveness

app/assets/stylesheets/site.sass

@@ -11,6 +11,19 @@ a
   margin: 0 auto
 .container
   max-width: 90%
+.container_full
+  min-width: 100%
+  width: 100%
+  &:after
+    clear: both
+  .half_left
+    @include span(6)
+    @media only screen and (max-width: 880px)
+      @include span(12)
+  .half_right
+    @include span(6)
+    @media only screen and (max-width: 880px)
+      @include span(12)
 
 ul.nav
   text-align: center
@@ -38,6 +51,8 @@ ul.nav
 
 .tripple
   @include span(4)
+  @media only screen and (max-width: 880px)
+    @include span(12)
 
 .main
   width: 78%

app/views/pages/rubyx/calling.html.haml

@@ -5,7 +5,7 @@
 %p
   Dynamic object oriented languages rely very heavily on dynamic method
   resolution and calling.
-  =link_to "Dynamic method resolution" , "method_resolution.html" 
+  =link_to "Dynamic method resolution" , "method_resolution.html"
   is the process of finding a
   method to call, and the calling convention defines how arguments are transferred and
   control changes and returns.
@@ -17,7 +17,7 @@
 
 %h3 Previous approaches
 %p
-  A quick review of existing c-like, stack based conventions, will reveal what we
+  A quick review of existing c-like, stack based conventions will reveal what we
   need to consider and solve. Coming from assembler, C uses a stack pointer to
   push both return address and arguments. Subsequently the function may use the
   the same stack to push/pop local variables, and off course it usually does calls
@@ -26,7 +26,7 @@
   Without going into detail, there are clear problems with this. For me the biggest
   is that this is not object oriented. The size of argument and frame (local)
   sizes of the stack are not locally known and require extensive knowledge of the
-  compiler to extract at compile time.
+  compiler to extract at run-time.
 %p
   The approach used a constant of the time: that a method returns to where it was called.
   In the face of lambdas this is not true anymore. This is linked in with the

app/views/pages/rubyx/layers.html.haml

@@ -13,7 +13,7 @@
   just push more functionality into the “virtual machine” and it is in fact only the
   compilation to binaries that gives static languages their speed. This is the reason
   to compile ruby.
-%p.center
+%p.center.full_width
   = image_tag "layers.jpg" ,  alt: "Architectural layers"
 
 %h3#ruby Ast + Ruby

app/views/pages/rubyx/memory.html.haml

@@ -65,8 +65,8 @@
   wasteful at first sight, it is
   %em much
   more efficient than using a hash (as in mri, that not only stores all those names
-  over and over, but also has buckets, list functionality and must use a cache line
-  for a single variable)
+  over and over, but also has buckets, list functionality and just about uses a cache
+  line for a single variable)
 
 %h3 Data
 
@@ -78,7 +78,7 @@
   Just to make that totally clear: The OO level has no access, no idea of data.
 %p
   Data does off course exist, but it is hidden, beyond the instance variables,
-  inaccessible to ruby code.
+  inaccessible to normal ruby code.
 %p
   The way this works, is that all access to data, or one should really say all
   functionality that is needed to perform on data, is implemented in the lower
@@ -86,7 +86,8 @@
 %p
   In the Builtin module, we can define methods in purely Risc terms. The Risc
   layer does have access to the memory, and can thus do things with it. Let's
-  look at the simple example of Integer addition. The method is defined in Builtin,
+  look at the simple example of Integer addition. The method is defined in
+  =ext_link "Builtin," , "https://github.com/ruby-x/rubyx/blob/master/lib/risc/builtin/integer.rb#L82"
   on the Integer type. The method requires one argument and checks that that too
   is an Integer. Then it loads the data from both objects, performs the operation,
   "allocates" a new Integer object and saves the machine word into it.