DEV Community: Brian J. Cardiff

¿Cómo instalar Haskell?

Brian J. Cardiff — Mon, 24 Mar 2025 18:49:12 +0000

Hay varias opciones para instalar las herramientas necesarias para programar en Haskell y también varias opciones sobre cómo usarlas. A continuación se presenta una serie de pasos y algunas opciones para que elijamos según nuestra preferencia. No es una guía exhaustiva. El objetivo es disponer de un entorno moderno que nos permita experimentar y aprender el lenguaje.

GHCup

Primero vamos a instalar el instalador GHCup. En https://www.haskell.org/ghcup/ vamos a encontrar el siguiente comando que funciona para Linux, macOS, FreeBSD o WSL2 y lo podemos ejecutar desde una terminal.

% curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh

Nos va a hacer algunas preguntas, podemos usar las opciones por defecto que son buenas.

Después de ejecutar el comando de arriba vamos a tener un ejecutable de ghcup en ~/.ghcup/bin (ese ~ representa la ruta de su usuario: seguramente /home/nombreusuario, /Users/nombreusuario o /mnt/c/Users/nombreusuario)

Tenemos que verificar si el directorio ~/.ghcup/bin está en el PATH o no. Ejecutando ghcup --version deberíamos ver algo como lo siguiente:

% ghcup --version
The GHCup Haskell installer, version 0.1.40.0

Si en cambio ven algo como command not found significa que ~/.ghcup/bin no está en el PATH y debemos agregarlo. Cómo, depende de qué sistema operativo y shell usemos, pero tenemos que agregar ~/.ghcup/bin al PATH. Seguramente necesitemos poner la ruta completa de ~.

Por ejemplo si usan macOS y zsh agregando lo siguiente a ~/.zprofile vamos a lograr tener ghcup en el path.

export PATH="/Users/nombreusuario/.ghcup/bin:$PATH"

Si hacemos algún cambio para modificar el PATH cerremos y vuelvamos a abrir la terminal. Probemos si ghcup --version anda esta vez.

Si anduvo ya está la parte más engorrosa.

GHC

GHC es un compilador del lenguaje Haskell. Hay muchas versiones. GHCup permite elegir entre ellas, instalar una o varias versiones y definir cuál es la versión por defecto que se va a usar cuando se ejecute el comando ghc.

Entre todas las versiones hay una que se llama recommended. Actualmente es la 9.4.8.

Si ejecutamos ghcup tui vamos a ver un menu para elegir instalar (presionando i) y establecer como default (presionando s).

% ghcup tui

Seguramente ya tengamos instalada y establecida la versión recomendada de GHC. GHCup hace eso por defecto. Deberíamos ver un doble tilde verde en la primer columna de GHC. Un tilde para instalado y otro tilde para establecido.

Para verificar si tienen GHC instalado podemos hacer lo siguiente:

% ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.4.8

Si no funcionó podemos usar los siguientes comandos para instalar y establecer la versión recomendada de GHC.

% ghcup install ghc recommended
% ghcup set ghc recommended

GHCi

Junto con GHC viene GHCi, el intérprete. Con GHCi podemos experimentar en forma interactiva, sin necesidad de crear archivos incluso.

% ghci
GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
ghci> 1+1
2
ghci> mayor a b = if a > b then a else b
ghci> mayor 3 4
4
ghci> :q
Leaving GHCi.

Trabajando con archivos en GHCi

También se pueden cargar archivos. Si creamos un archivo Ejemplo.hs (la convención es que empiecen con mayúscula) con el siguiente contenido:

mayor a b = if a > b then a else b

Podemos cargarlo en ghci usando :l Ejemplo.hs y usar la función definida en él.

% ghci
GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
ghci> :l Ejemplo.hs 
[1 of 2] Compiling Main             ( Ejemplo.hs, interpreted )
Ok, one module loaded.
ghci> mayor 2 4
4

Si cambiamos el contenido del archivo con :r vamos a recargarlo

ghci> :r
[1 of 2] Compiling Main             ( Ejemplo.hs, interpreted ) [Source file changed]
Ok, one module loaded.

Trabajando con VSCode

Si elegimos VSCode como editor, lo recomendable es instalar extensión haskell.haskell. Se integra con GHCup y cuenta con algunas herramientas adicional.

La configuración sugerida ( Ctrl + Shift + P o Cmd + Shift + P , > Open User Settings (JSON)) es la siguiente.

{
    "haskell.manageHLS": "GHCup",
    "haskell.upgradeGHCup": false,
    "haskell.toolchain": {
        "ghc": "recommended",
        "hls": "recommended",
        "cabal": "recommended",
        "stack": null
    },
    "editor.formatOnSave": true
}

Esta configuración sólo necesita que GHCup esté en el PATH y va a bajar otras herramientas cuando las necesite. Si ya tenemos ghc en PATH podemos omitir ésta configuración.

Si abrimos el archivo Ejemplo.hs con el editor vamos a tener coloreo de sintaxis. 🎨

Seguramente nos aparezca la pregunta "Need to download hls-recommended, continue?". Digamos que sí. Alternativamente podemos instalar la versión recomendada de HLS usando ghcup como hicimos antes.

Es posible que necesitemos reiniciar el editor (Ctrl + Shift + P o Cmd + Shift + P , > Developer: Reload Window).

Ahora disponemos de HLS (Haskell Language Server) que nos dará acceso a documentación y otras herramientas integradas para

Dar formato al código usando ormolu
Sugerencias sintácticas usando hlint
Anotaciones de tipo usando el algoritmo de inferencia
Ir a la definición de la función
Ver documentación
Evaluar código en líneas que empiezan con -- >>>

Por ejemplo, si el archivo contiene

mayor a b = if a > b then a else b

-- >>> mayor 2 3

Nos va a aparecer un Evaluate... arriba del -- >>> que al hacer click nos dará el resultado.

mayor a b = if a > b then a else b

-- >>> mayor 2 3
-- 3

Trabajando con múltiples archivos

Tanto GHCi como VSCode pueden operar con múltiples archivos al mismo tiempo. Hay veces que queremos separar el código en distintos módulos, ya sea para restringir interface o por mera organización.

Supongamos que en una carpeta tenemos Foo.hs y Bar.hs con el siguiente contenido

module Foo where

foo = 2

module Bar where

import Foo

bar = foo + foo

-- >>> bar
-- 4

En GHCi podemos cargar cualquiera de los dos módulos con :l y evaluar sus funciones.

% ghci
GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
ghci> :l Bar.hs 
[1 of 2] Compiling Foo              ( Foo.hs, interpreted )
[2 of 2] Compiling Bar              ( Bar.hs, interpreted )
Ok, two modules loaded.
ghci> bar
4

En VSCode basta con abrir la carpeta que los contiene para que todo funcione y podamos evaluar -- >>> bar como antes.

Cabal

Es usual aprovechar paquetes y aplicaciones definidos por otras personas. En Haskell se registran y distribuyen en Hackage. Para descargar los paquetes o aplicaciones de Hackage se usa Cabal. Si hemos seguido las instrucciones ya tenemos Cabal instalado, sino podemos usar GHCup para obtener la versión recomendada.

% cabal --version
cabal-install version 3.12.1.0
compiled using version 3.12.1.0 of the Cabal library

A continuación usaremos aplicaciones y paquetes de Hackage.

Re-evaluando expresiones

Cada vez que cambiamos un archivo y queremos ver el resultado de nuestro nuevo programa tenemos que alejarnos de donde estamos editando el código para ir a evaluar una expresión.

Si usamos GHCi tenemos que hacer :r y escribir la expresión a evaluar.

Si usamos VSCode podemos llegar a tener ya escrita cerca de la función que estamos editando la expresión a evaluar a continuación de un -- >>> . Con un click en Evaluate... o Refresh... obtenemos el resultado.

Hay otra opción que no require alejarnos del código que estamos editando. La herramienta ghcid permite ejecutar un expresión ni bien se hacen cambios en un archivo.

Para instalarla primero debemos tener una versión actualizada del índice de paquetes.

% cabal update

Luego podemos proceder a instalar la aplicación ghcid.

% cabal install ghcid

Con el comando anterior la aplicación va a quedar instalada en ~/.cabal/bin. Vamos a necesitar agregar este directorio al PATH.

Como alternativa podemos indicar en qué directorio instalar la aplicación. Por ejemplo en un directorio bin junto a los archivos que estamos editando.

% cabal install ghcid --installdir=bin

Volviendo al ejemplo de Bar.hs, podemos querer evaluar la función bar cada vez que hagamos cambios en el archivo.

% bin/ghcid Bar.hs --test bar

En la pantalla veremos:

4

...done

Probemos cambiar el contenido de Bar.hs o Foo.hs y el valor se actualizará.

Trabajando con paquetes externos

Para trabajar con paquetes hay dos alternativas

Instalar el paquete que queremos en forma manual y que esté disponible universalmente en la computadora, o bien
Definir un proyecto cabal y declarar ahí cuales son los paquetes externos que queremos usar.

Forma manual

Por ejemplo si queremos escribir casos de prueba podemos optar por usar el paquete HUnit e instalarlo de forma manual y que esté disponible universalmente.

% cabal install --lib HUnit

Luego podemos usarlo directamente al importarlo.

module Bar where

import Foo
import Test.HUnit

bar = foo + foo

main = runTestTTAndExit allTests

allTests =
  test
    [ bar ~?= 4
    ]

En GHCi podemos evaluar la función main

% ghci Bar.hs 
ghci> main
Cases: 1  Tried: 1  Errors: 0  Failures: 0
*** Exception: ExitSuccess

En VSCode podemos evaluar -- >>> main pero la salida vamos a verla en la pestaña de OUTPUT si seleccionamos Haskell en la lista de la derecha.

Con ghcid podemos ejecutar el siguiente comando para correr los test automáticamente con cada cambio.

% bin/ghcid Bar.hs --test main

⚠️ Si bien cabal install --lib paquete anda y parece simple, no es la forma más adecuada de instalar paquetes. Dentro de la comunidad de Haskell se desaconseja usar esta forma. Está disponible por motivos históricos.

‼️ En VSCode es posible que necesitemos ejecutar el comando Haskell: Restart Haskell LSP Server (Ctrl + Shift + P o Cmd + Shift + P) para que tome los cambios del entorno.

Definir un proyecto

Cabal nos permite también inicializar un proyecto Haskell. Esto nos sirve para organizar mejor el código en distintas partes pero sobre todo para un mejor manejo de dependencias.

Para inicializar un proyecto podemos usar cabal init nombreproyecto y aceptar todas las opciones por defecto.

% cabal init nombreproyecto
What does the package build:
   1) Library
 * 2) Executable
   3) Library and Executable
   4) Test suite
Your choice? [default: Executable] 
...

Vamos a obtener la siguiente estructura en la carpeta nombreproyecto

.
├── CHANGELOG.md
├── LICENSE
├── app
│   └── Main.hs
└── nombreproyecto.cabal

Podemos borrar CHANGELOG.md y LICENSE para código de prueba.

El archivo .cabal tiene información sobre cómo se conforma el proyecto. En particular al final obtenemos algo similar a lo siguiente:

executable nombreproyecto
    import:           warnings
    main-is:          Main.hs
    -- other-modules:
    -- other-extensions:
    build-depends:    base ^>=4.17.2.1
    hs-source-dirs:   app
    default-language: Haskell2010

hs-source-dirs indica dónde va a estar el código, si queremos podemos cambiarlo a src y cambiar de nombre la carpeta existente app.

Cuando hagamos % cabal run dentro de la carpeta nombreproyecto va a compilar Main.hs y ejecutar la función main definida ahí.

% cabal run
Hello, Haskell!

Adaptemos el ejemplo de Foo, Bar y HUnit a este esquema.

Podemos tener un Bar.hs y Foo.hs en el directorio app junto a Main.hs. Y dejar el test en Main, de forma que Bar sólo tenga el código que queríamos escribir.

module Foo where

foo = 2

module Bar where

import Foo

bar = foo + foo

module Main where

import Bar
import Test.HUnit

main = runTestTTAndExit allTests

allTests =
  test
    [ bar ~?= 4
    ]

Ahora bien, nos falta actualizar el archivo nombreproyecto.cabal para declarar

Qué otros archivos forman parte del proyecto: sí hay que listarlos explícitamente.
Qué paquetes externos queremos usar.

Quitemos el comentario a other-modules para listar Bar y Foo para lo primero. Agregamos HUnit opcionalmente con información de versión.

executable nombreproyecto
    import:           warnings
    main-is:          Main.hs
    other-modules:
        Bar
        Foo
    -- other-extensions:
    build-depends:    base ^>=4.17.2.1, 
                      HUnit ^>=1.6.2.0
    hs-source-dirs:   app
    default-language: Haskell2010

Si hacemos cabal run obtenemos el resultado de los tests.

% cabal run 
Cases: 1  Tried: 1  Errors: 0  Failures: 0

Si hacemos cabal repl vamos a iniciar un ghci con todo el proyecto ya cargado.

% cabal repl
[1 of 4] Compiling Foo              ( app/Foo.hs, interpreted )
[2 of 4] Compiling Bar              ( app/Bar.hs, interpreted )
[3 of 4] Compiling Main             ( app/Main.hs, interpreted )
Ok, three modules loaded.
ghci> main
Cases: 1  Tried: 1  Errors: 0  Failures: 0
*** Exception: ExitSuccess
ghci> 
Leaving GHCi.

Si usamos VSCode el editor va a ayudarnos a navegar entro los archivos y otros beneficios. Cada vez que cambiamos el archivo .cabal vamos a necesitar hacer un Haskell: Restart Haskell LSP Server (Ctrl + Shift + P o Cmd + Shift + P) para que tome los cambios del entorno.

Si usamos ghcid no necesitamos indicar el archivo Main.hs, solo la función a evaluar, ya que usa la información de main-is del archivo .cabal pero vamos a notar que el resultado de los tests no aparece.

% bin/ghcid --test main
Loading cabal repl --repl-options=-fno-break-on-exception --repl-options=-fno-break-on-error --repl-options=-v1 --repl-options=-ferror-spans --repl-options=-j ...
Build profile: -w ghc-9.4.8 -O1
In order, the following will be built (use -v for more details):
 - nombreproyecto-0.1.0.0 (interactive) (exe:nombreproyecto) (first run)
Preprocessing executable 'nombreproyecto' for nombreproyecto-0.1.0.0...
GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
[1 of 4] Compiling Foo              ( app/Foo.hs, interpreted )

app/Foo.hs:3:1-3: warning: [-Wmissing-signatures]
    Top-level binding with no type signature: foo :: Integer
  |
3 | foo = 2
  | ^^^
...

En su lugar aparecen solamente warnings. Esto es porque nuestro archivo .cabal indica ser muy estricto con los warnings.

En este caso los warnings son porque las funciones foo, bar y main no tiene declaración de tipos. Podemos agregarlas, pero en general cuando estamos modificando código vamos a producir varias situaciones de warnings: variables no usadas, pattern matchings no exhaustivos, funciones no exportadas no usadas, etc..

Si cambiamos el archivo .cabal para que sea más permisivo y no reportemos warnings nuestro editor también va a dejar de mostrarlos. Lo recomendado es hacer que ghcid se más permisivo y nada más. Con la opción --warnings lo logramos. De esta forma si bien va a seguir reportando los warnings, para que los vayamos arreglando, no va a dejar de ejecutar la función test.

% bin/ghcid --warnings --test main
...

Cases: 1  Tried: 1  Errors: 0  Failures: 0

...done

Generating LaTeX Beamer Handouts without changing files

Brian J. Cardiff — Thu, 27 Feb 2025 13:18:43 +0000

When using LaTeX, it's common to use Beamer to create slides for presentations. Typically, a Beamer document starts like this:

\documentclass{beamer}
% Presentation content...

You can use transitions like \pause to reveal content step by step. However, when preparing handouts, it's often desirable to remove these transitions for clarity.

The Standard Approach: Using the `handout` Option

A common method to create handouts is to modify the \documentclass line:

\documentclass[handout]{beamer}
% Presentation content...

This effectively removes all transitions, producing a clean, static document. However, constantly toggling this line on and off can be tedious. Below are alternative approaches to simplify this process.

Alternative 1: Using `\PassOptionsToClass`

A more flexible method is to use \PassOptionsToClass, which allows you to toggle handout mode with a simple comment:

\PassOptionsToClass{handout}{beamer}
\documentclass{beamer}

To switch back to transition mode, just comment out the first line:

% \PassOptionsToClass{handout}{beamer}
\documentclass{beamer}

This avoids direct modifications to the \documentclass line, making toggling easier.

Alternative 2: Using a Separate Handout File

If you frequently need both presentation and handout versions, consider creating a separate file. If your main Beamer file is main.tex, create a new handout.tex file containing:

\PassOptionsToClass{handout}{beamer}
\input{main}

Now, compiling main.tex gives you the regular slides with transitions, while compiling handout.tex produces a transition-free handout.

Alternative 3: On-the-Fly Handout Generation

For even greater flexibility, you can generate the handout dynamically using a shell command. If you use Makefile or automation scripts, this method fits well into workflows:

echo '\\PassOptionsToClass{handout}{beamer}\\input{main}' | pdflatex -jobname=handout

Note that when piping LaTeX source to pdflatex you will need to pass -jobname to setup the output file name.

Conclusion

By using \PassOptionsToClass, separate handout files, or shell scripting, you can streamline the process of generating handouts from Beamer presentations. Choose the method that best fits your workflow and avoid the hassle of manually toggling the handout option!

Contributing to devenv

Brian J. Cardiff — Mon, 21 Nov 2022 20:23:00 +0000

I wanted to contribute a bit to devenv. I consider myself a novice nix user. Anything beyond a couple of recipes I know fall out of my comfort zone. Yet the goals of devenv plus how supportive the maintainers seems to be were enough to do an attempt.

Build, share, and run your local development environments with a single command. Without containers.
https://devenv.sh/

I want to cover how you could contribute to add support for the language, or improve an existing one.

There are many options of course, but a workflow that worked for my was

Install Nix+Cachix+Devenv as explained in https://devenv.sh/getting-started/
(Optional) Install direnv, most likely you already use this :-)
Fork and Clone https://github.com/cachix/devenv

The devenv repo defines both:

a cli tool that will set up your environment
a repository of devenv modules

The modules are a description of which nix packages should be downloaded and how they should be setup when devenv options are declared in the devenv.nix file of your project.

We are interested in the second aspect: the modules repository.

For contributing to those we actually don't need to build a new version of the cli (as long as we are not changing some core functionality of course).

When you create a new project powered by devenv you will have at least:

a devenv.nix file where you setup what languages/packages you want
a devenv.yaml file that defines some pinning and source of truth to be used.

In particular devenv.yaml there is a input.devenv.url key that points to the modules repository. By default points to github:cachix/devenv?dir=src/modules (defined in flake.nix#L7), but we can override it! To a local path!

That's what happening in examples/supported-languages. The input.devenv.url key points to the working copy src/modules. We can use this example as a playground or create a new empty project devenv.

If you choose to work on a new empty project, run devenv init in an empty folder and edit devenv.yaml:

inputs:
  nixpkgs:
    url: github:NixOS/nixpkgs/nixpkgs-unstable
  devenv:
    url: path:/absolute/path/to/src/modules

After running direnv allow, or devsenv shell if you don't use direnv you should get the packages and languages defined in devenv.nix.

I added languages.elm.enable = true; to devenv.nix to get elm compiler and it works!

% devenv shell
Building shell ...
Entering shell ...

elm --version
0.19.1
elm2nix --version
/nix/store/3szqhljvvkynvfi5gymfnxsiljpd6hmg-elm2nix-0.3.0/bin/elm2nix
hello from devenv
git version 2.38.1

But this does not come with elm-format. We want the formatter, always. That's the contribution we want to make. We could make the formatter optional, but it's so widely used in the elm community that I think we can install it always. What could be nice is a pre-commit hook integration to run it. That could be configurable, but let's stick to get the elm-format installed for now.

The package already exists in nixpkgs as elmPackages.elm-format so this should be easy.

Go to src/modules/languages/elm.nix, and add elm-format to the package dependency. Additionally add some advertisement you think pertinent. Unfortunately elm-format does not returns it's version with --version, so we will just show that elm-format is indeed available.

--- a/src/modules/languages/elm.nix
+++ b/src/modules/languages/elm.nix
@@ -11,6 +11,7 @@ in
   config = lib.mkIf cfg.enable {
     packages = with pkgs; [
       elmPackages.elm
+      elmPackages.elm-format
       elm2nix
     ];

@@ -18,6 +19,8 @@ in
       echo elm --version
       elm --version

+      which elm-format
+
       echo elm2nix --version
       which elm2nix
     '';

Now, how we check if this changes are good?
If you followed along you should be on a devenv shell (via direnv or explicit devenv shell command).

Update the shell by either running direnv allow again, or exiting the devenv shell (ctrl+D) and entering again.

And that's it. You should have elm-format available.

Submit a PR!

Caveats for aarch64-darwin

I needed to comment out pkgs.python3Packages.cairocffi in devenv.nix#L7 for devenv source to work on aarch64-darwin, thanks @domenkozar!

An iterative validation of a new implementation

Brian J. Cardiff — Mon, 21 Dec 2020 22:46:13 +0000

Sometimes I need to replace or refactor a function in a program. In this post I want to share a process I’ve used to make such change. The goal is to improve our confidence in the end result.

Suppose you have a function f we need to migrate. For the sake of simplicity, we will assume f will never raise an exception.

def f(input : String)
  # ... stripped ...
end

There are no unit tests, but said function is widely used through the whole suite of tests.

First step, leave the original function and define a wrapper.

def original_f(input : String)
  # ... stripped ...
end

def f(input : String)
  original_f(input)
end

Second step, define a new implementation:

def new_f(input : String)
  # something new we hope will work
end

Third step, run both implementations and detect invalid behaviors of new_f with respect to original_f. These invalid behaviors can be either crashes or unexpected results.

To detect them we are going to change the wrapper with a bit of code that you will probably not like at all. Relax, it will be gone at the end.

def f(input : String)
  original_result = original_f(input)

  begin
    new_result = new_f(input)
  rescue e
    e.inspect_with_backtrace(STDOUT)
    File.write("bug.txt", input)
    exit(1)
  end

  if original_result != new_result
    File.write("bug.txt", input)
    puts "\n\nUnexpected result: #{input.inspect}.\n  Expected: #{original_result.inspect}\n       Got: #{new_result.inspect}\n\n"
    exit(1)
  end

  original_result
end

If there is an unexpected result the program will stop. Immediately. This can be done differently but, for the sake of simplicity, we are stopping at the first invalid behavior.

We run the whole suite of tests and, if there is a crash, a bug.txt file will be created with the input that caused the invalid behavior.

We can use a smaller program to work on the input that causes the crash.

def t(input)
  original_result = original_f(input)
  new_result = new_f(input)

  if original_result != new_result
    pp! input, original_result, new_result
  end
end

# Some trivial cases, maybe
t("")
t("abc")
t("   abc    ")
t("   ")

# The input that caused the crash
t(File.read("bug.txt"))

# You could also use a test framework, of course.

This way we can work on new_f until the identified case is fixed.

Iterate the process of running the whole suite of tests until there is no crash.

Now you have a new_f that works as original_f. At least, to the extent the suite of tests needs. Note that we are not talking about only unit tests of f.

Drop the "ugly" code to compare both implementations. Drop the original_f. We don't need them anymore. Leave only the new_f as the implementation of f.

def f(input : String)
  # something new we hope will work
end

You are done! 🎉

This process was explained with Crystal but it can be adapted easily to other languages.

Programming is a tool. Yet, as a tool, it can be used as a process. We made temporal additions to our codebase as part of the process. There is no need for the code you write to always be permanent in the code base.

There are more advanced processes and tools in software verification. This is a small example that might motivate you to look into them.

A counting triangles story

Brian J. Cardiff — Thu, 26 Nov 2020 18:18:12 +0000

Programming is a tool that can be used for a wide range of problems. Usually we code solutions for our clients, sometimes we build applications for ourselves. Programs don’t always need to be products at all, they can act as tiny pieces towards a larger objective.

It was back in May 2009 in Manas.Tech when Nico came with a simple question. How many triangles can you find in this figure?

Obviously 1-3-10, 1-2-7 are triangles. For sure 7-9-2 is easy to depict. 2-4-6 is a bit small but definitely one to count and so on. Each of these triangles has another mirror image. After a little while, you realise there is also 1-2-6, and 2-6-7 and –oh boy!– 1-2-9. Most likely you will have lost count of how many triangles there are unless you are seriously organized.

Since we like having fun, either with arcades, drinks or whatever challenge comes to our daily life in Manas, we decided to tackle down this problem using our favorite tools.

In May 2009, some of us were nearing graduation, teaching assistants at college; school was another daily activity.

Most of us are programmers, and as such, we program. But each programmer has different preferences, backgrounds, areas of expertise, and this simple exercise was a perfect manifestation of that richness.

During the whole day a bunch of emails were sent with the proposed answers. Claims were made around 53, 54, 47, 63, 65. 47 was the most popular answer by far, yet, incorrect according to some sources.

The difference between the numbers is based on whether or not three aligned points shall be considered a triangle. And if 2-6-8 is equal to 2-8-10... definitely not the important thing here.

Different approaches

So the result was that we had lots of implementations, with completely different “mathematical” backgrounds to solve this riddle.

In chronological order we had the following solutions

Santiago Palladino, with 62 lines of Python, he counted 3-segment cycles in a graph. Yep, he likes Python and Graph Theory (and Numerical Methods).
Adrian Romero, with 35 lines of Python, he focused more on the lines than on the dots. He counted the intersections between pairs of lines that correspond to a triangle.
Juan Wajnerman, with 41 lines of C# and heavy use of LINQ, he took a relational algebra approach (or SQL-ish if Algebra is not your cup of tea) to get a cross product and filter, achieving the same answer as the previous ones.
Brian J. Cardiff (that’s me!), wrote a shameful and silly 30 lines of Prolog (could have been 20). Same answer! It was a Generate & Test algorithm that searched for three not aligned points that were aligned in pairs.

There were rounds of iteration along the day (we are agile developers after all) for fixing, discussing and discovering the different opinions around what is or isn’t a triangle. We relaxed the triangle criteria since we were not reaching the expected answer and we wanted to know why.

Adapting software is a big concern. If the inner functioning of the algorithm is not evident by reading the code, changing it is pretty hard. None of the above were too long or too cryptic, specially for the author himself. But, maybe because of my bias, Prolog was a clear winner here. Check the code!

But you know what? The solutions didn’t stop there.

Ary Borenszweig codes a lot, seriously. Back then Crystal was not even a dream and he wrote 334 lines of Java. He even created a Graph class, tests and TrianglesCounter class. It’s Java’s way. The idea behind it was similar to Adrian’s, focused on the lines.
Jonathan Kicillof (our graphic designer!) submitted his own. Although he knew ActionScript and today I am amazed about the Javascript plugins he is able to pull off, he submitted a PDF. Yeap, a well organized PDF that helped us point directly to the good, the bad and the ugly triangles.
Ary Borenszweig, that guy that still codes a lot, submitted a total of 676 lines of Java. This time with a UI to draw and solve any triangle based problem.

Given that the input is fixed, the shortest program would be echo 47 but that would have taken all the fun out of it.

And it’s nice to use your skills and the computer to solve a problem for yourself, by yourself. I happily remember when I already had lots of fun and challenges programming with nothing but a turtle.

Debug Crystal in VSCode via CodeLLDB

Brian J. Cardiff — Fri, 17 Apr 2020 21:06:39 +0000

This post mentions features that will be released in 0.35.0, or that will require you to compile Crystal master branch ;-)

Crystal uses LLVM under the hood. To allow a more comfortable debugging experience it is required to instruct lldb how to understand the values stored in memory. Recently this story got a lot of effort and it finally got merged. You can read more at #8538.

Let me share with you the configurations that will let you use the CodeLLDB
extension to debug Crystal programs.

Create a task that will compile the current file and leave it in bin/ folder. In your project’s .vscode/tasks.json add:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "crystal: build current file (debug)",
      "type": "shell",
      "command": "crystal build --debug ${relativeFile} -o bin/${fileBasenameNoExtension}"
    }
  ]
}

You might need to set the Crystal binary path in "command" field depending on your environment.

Check you have the CodeLLDB extension installed.

Create a launch configuration that will run the previous task and start debugging the binary left in bin/. It will also set up lldb with the appropriate formatters. In your project’s .vscode/launch.json add:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "crystal: debug current file",
      "preLaunchTask": "crystal: build current file (debug)",
      "program": "${workspaceFolder}/bin/${fileBasenameNoExtension}",
      "args": [],
      "cwd": "${workspaceFolder}",
      "initCommands": [
        "command script import /path/to/crystal/etc/lldb/crystal_formatters.py"
      ]
    }
  ]
}

You will need to set the crystal_formatters.py path in "initCommands" field accordingly to your environment. The file is located in the compiler’s repo at etc/lldb/crystal_formatters.py

You are all set, have fun!

Keep in mind we are still in the early days for these improvements. Debug information metadata and more formatters are still pending. But the recent effort to improve their current state sets the scaffolding to move steadily forward.

Happy Crystalling!