Ken Arroyo Ohori

#30DayMapChallenge

Tue, 22 Nov 2022 11:47:00 -0600

Contribuí con 3 mapas al esfuerzo conjunto de mi grupo de investigación en el #30DayMapChallenge. Están publicados en el Twitter del grupo, pero también enlazo los resultados desde aquí.

Día 10: OpenStreetMap

Este mapa muestra el número de huellas de edificios disponibles en OpenStreetMap por celda de H3. Es interesante ver que algunas regiones del mundo están mucho mejor mapeadas que otras y que los datos no se correlacionan tanto con la población o la riqueza.

El script para generar los datos está disponible aquí.

Día 21: Conjunto de datos de población de Kontur

Este mapa muestra las ciudades más grandes del mundo, calculadas de forma independiente a partir del conjunto de datos de población de Kontur. El primer paso fue clasificar todas las celdas de H3 en urbanas y no urbanas con base en un umbral de densidad de población (5000/km^2 por defecto). Las celdas urbanas se agregan entonces en ciudades siempre que formen regiones casi contiguas (hasta un umbral máximo de separación entre celdas).

Debido a la metodología, es posible generar las ciudades más grandes del mundo usando un estándar uniforme, lo que contrasta con la forma inconsistente en que diferentes países calculan sus propias estadísticas. Si te disgusta la expansión urbana tanto como a mí, te alegrará ver que este mapa muestra la verdadera naturaleza del desarrollo suburbano.

El script para generar los datos está disponible aquí.

Día 23: Movimiento

Este mapa, inspirado en Chronotrains, muestra qué tan lejos puedes viajar en la Ciudad de México usando el transporte público en una hora, con base en isócronas precalculadas (de 15, 30, 45 y 60 minutos). Las isócronas se calculan para todas las paradas de metro, BRT, tren ligero, tren suburbano y teleférico usando datos del GTFS estático de la Ciudad de México y un método personalizado.

El código para generar el mapa y calcular las isócronas está disponible aquí.

Cómo molestar a quienes envían sus trabajos a tu conferencia o revista científica

Mon, 10 Jul 2017 18:23:00 -0500

A veces puede parecer que los organizadores de conferencias y los editores se esfuerzan por imponer a los autores tantas reglas sin sentido como sea posible. Así que decidí compilar una lista de mis favoritas.

Actualizado el 11 de julio de 2017

Conferencias

Cambia tus fechas límite de envío muchas veces sin previo aviso, preferiblemente después de que la fecha anterior ya haya pasado. A todo el mundo le encanta afanarse por cumplir una fecha límite y luego enterarse de que pudieron haber evitado trabajar en sus vacaciones.
Diles a quienes envían sus trabajos a tu conferencia que los mejores artículos se publicarán en una revista de alto perfil. Solo después de la conferencia les dices que los artículos tendrán que ampliarse y pasar por rondas adicionales de revisión.

Contenido del artículo

Limita el uso de extractos del trabajo de otras personas. Que se vaya al diablo el uso justo, ¡esa es la manera de hacerlo!
Impón una lista estándar de secciones. Todo el trabajo es básicamente el mismo, así que todo cabe en el mismo formato. Esto de ninguna manera socava la capacidad de los autores de explicar su trabajo.
Pide a los autores que pasen horas buscando detalles bibliográficos oscuros para cada una de sus fuentes. Todos necesitan saber la dirección antigua de una editorial desaparecida.
Los nombres de las revistas deben abreviarse de acuerdo con una lista. Esto de ninguna manera es una práctica ridícula. ¡Cada carácter ahorrado cuenta!

LaTeX vs. Word

No proporciones una plantilla de LaTeX. Enviarse archivos de Microsoft Word de ida y vuelta por correo electrónico es la mejor forma de colaboración. Fusionar los cambios de varias personas siempre es muy divertido.
Si no tienes la experiencia técnica para lidiar con archivos LaTeX, solo dile a la gente que aceptas LaTeX pero luego pide un archivo .doc una vez que un artículo sea aceptado. Los costos hundidos garantizarán que los autores hagan minuciosamente la conversión sin costo alguno para ti.
Implementa un sistema de compilación de LaTeX en vivo en lugar de hacer cargas de PDF. Pasar un día depurando un archivo LaTeX en incrementos de 15 minutos es un gran uso del tiempo de los investigadores.
Proporciona una plantilla de LaTeX que no coincida con la plantilla de Word. Luego pide a los autores que jueguen con su manuscrito hasta que lo haga.

Lenguaje y formato

Exige una variedad específica de inglés. El inglés británico y el inglés americano son mutuamente ininteligibles, así que tiene sentido que tus lectores solo entiendan uno de ellos. Además, nadie es más capaz de lidiar con esto que un científico cuyo idioma nativo no es el inglés.
No permitas subfiguras. Es mucho mejor que los autores las fusionen en una sola figura improvisada con etiquetas de tamaño incómodo y fuentes disparejas.
El texto rasterizado en las figuras siempre es genial. Obligar a los usuarios a ponerlo ahí limitando lo que pueden poner en un pie de figura es solo pensamiento inteligente.
Obliga a los autores a enviar sus archivos de figuras nombrados de acuerdo con el número de su figura. Todos conocen sus figuras por número en lugar de por su contenido, ¿verdad?
Limita las figuras a color. A quién le importa si hace que tus figuras sean mucho más difíciles de leer. Los lectores siempre usan las versiones impresas de una revista o imprimen un artículo en impresoras de matriz de puntos, ¿verdad?
Limita los tamaños de archivo a unos pocos MB. Los gráficos de baja calidad son mucho preferibles a un archivo PDF algo grande.
Diles a los autores que empujen todas sus figuras al final del artículo. Ir y venir mientras se lee es lo mejor.
Limita los formatos de archivos de imagen a EPS o TIFF de última generación.

Envío, revisión y publicación

Cobra unos cuantos miles de dólares/euros por la publicación de acceso abierto. La edición y el alojamiento profesionales son súper caros. Claramente no hay ni un indicio de precios de monopolio ahí. Ninguno en absoluto.
Obliga a quienes envían sus trabajos a sugerir unos cuantos revisores amigables. Seguramente esto de ninguna manera socava la imparcialidad de una revisión.
Permite que los revisores fuercen a los autores a citar el trabajo de los propios revisores. Los editores obviamente no están en posición de detener esta mala práctica.
Rechaza artículos sin revisión sin razón obvia. Puntos extra si lo haces con una carta genérica con una lista de razones potenciales para que los autores adivinen cuál se aplica a ellos.
No aceptes archivos zip. En su lugar, haz que los autores suban cada figura por separado. Solo haz clic en añadir archivo, navega y sube cada vez. ¡Pan comido!
Obliga a los autores a anonimizar el artículo pero no elimines la información del autor de los metadatos del archivo. Es divertido dejarla ahí para que los revisores con inclinaciones técnicas la encuentren.

Problemas metodológicos al usar los datos de contaminación de la Ciudad de México

Tue, 10 Jan 2017 21:08:00 -0600

La contaminación en la Ciudad de México ha sido un problema durante décadas. Recuerdo mi infancia a principios de los años 90 como una época de cielos siempre grises, gasolina con plomo barata e historias casi increíbles de aves que caían muertas del cielo. En 1992, la Ciudad de México obtuvo el dudoso honor de ser la ciudad más contaminada del planeta. Muchos habitantes de la ciudad se indignaron¹.

Hoy en día los cielos son mayormente azules y la situación ha mejorado mucho, lo cual es un logro real considerando la poco afortunada ubicación de la Ciudad de México en un valle cerrado a más de 2 km sobre el nivel del mar². Esta mejora no fue coincidencia. Tras los peores años de la crisis de contaminación vinieron acciones enérgicas, incluyendo el cierre de una refinería de petróleo, el traslado de ciertas fábricas fuera de la ciudad y la obligación de que todos los autos instalaran convertidores catalíticos y se sometieran a estrictos controles de emisiones dos veces al año.

Sin embargo, la reacción más previsora fue quizá la creación en 1986 de un sistema de monitoreo de contaminación para toda la ciudad, ahora conocido como SIMAT. El sistema es reconocido como un gran éxito y se usa ampliamente. Por ejemplo, si los niveles de contaminación alcanzan cierto nivel en un día dado, se imponen restricciones a la circulación de autos para el día siguiente. Mucha gente en la Ciudad de México revisa los niveles de contaminación con más frecuencia que el pronóstico del tiempo³.

Si bien los datos crudos de contaminación son generalmente considerados precisos y confiables, tienen algunas peculiaridades:

Las estaciones de monitoreo de contaminación se han movido muchas veces y el número de estaciones ha fluctuado constantemente.
No todos los contaminantes se miden en todas las estaciones.
Las estaciones se desconectan regularmente para mantenimiento.

Todo lo anterior significa que muchos (¿la mayoría?) de los usuarios de los datos de contaminación de la Ciudad de México los usan incorrectamente incluyendo los gobiernos de la Ciudad de México y el federal mexicano. Este post de blog documenta un par de malos ejemplos que muestran lo que creo que son los principales usos incorrectos de los datos y ojalá ayude a otros a usarlos mejor.

Estadísticas estadísticamente débiles

Un grupo de trabajo intergubernamental conocido como la Comisión Ambiental de la Megalópolis emite alertas ambientales basadas en el nivel máximo de contaminación en la ciudad. Esto es estadísticamente sospechoso: cuantas más estaciones estén en línea, más probable es que se detecte un pico local de contaminación y se emita una alerta ambiental. A su vez, esto crea un incentivo perverso para que el gobierno reduzca el número de estaciones de monitoreo de contaminación y las ubique lejos de las áreas contaminadas.

Por ejemplo, la estación en Xalostoc (una zona industrial al noreste de la zona metropolitana) suele ser la más contaminada de la ciudad. Si esta estación está (temporalmente) fuera de línea, las posibilidades de que se declare una alerta de contaminación disminuyen sustancialmente. Estoy seguro de que si se integraran más estaciones al sistema, particularmente en otras zonas industriales como Cuautitlán Izcalli, Iztapalapa, o los vecinos valles de Toluca o del Mezquital (que también son parte de la megalópolis), provocaría que el número de alertas de contaminación aumentara.

Como otro ejemplo de estadísticas estadísticamente débiles, considera los bonitos mosaicos que muestran los datos máximos de contaminantes de cada día durante los últimos años. También usan solo el máximo y no toman en cuenta el aumento general en el número de estaciones a lo largo de los años.

No manejando correctamente los huecos en los datos

Los niveles crudos de contaminantes son difíciles de entender para los no especialistas. Por lo tanto, el gobierno de México (como la mayoría de los otros gobiernos) ha definido un índice de contaminación llamado IMECA. Su valor se calcula independientemente para cada contaminante (CO, CO₂, NO₂, ozono, PM₁₀, PM_2.5, etc.), pero el único número que está fácilmente disponible y se difunde ampliamente a la población es el máximo de todos los contaminantes por estación⁴.

Cuando consideras este asunto junto con el hecho de que no todas las estaciones miden todos los contaminantes, otro problema se vuelve evidente: el valor de IMECA de cada estación es en realidad solo un límite inferior (en contraposición a su valor real pero desconocido) y estos valores no pueden interpolarse. Y sin embargo, son interpolados directamente por la mayoría de los servicios, incluyendo el por lo demás excelente Hoyo de Smog y la aplicación de Netatmo. Esta es una forma completamente equivocada de proporcionar datos de contaminación en cada ubicación⁵.

Como otro mal ejemplo, considera los mapas que se muestran en el sitio web de SIMAT. Aparentemente, mi alcaldía de origen, Coyoacán (rodeada en rojo), es más limpia que el área circundante, ¿verdad? En realidad, las estaciones de monitoreo de la alcaldía no miden PM₁₀, que es el principal contaminante en estos fríos días de invierno⁶. Esto es doblemente engañoso en la vista de alcaldías/municipios que se muestra a la derecha, donde (de nuevo) las alcaldías/municipios con menos estaciones y que miden menos contaminantes generalmente se muestran como más limpias.

Quizá algún día termine creando mi propio mapa de contaminación en tiempo real. Ese sería un buen proyecto pequeño.

Apéndice: obteniendo los datos

pero la naturaleza cínica de los chilangos hizo que más de unos cuantos lo llevaran con orgullo… ↩
Ninguna otra megaciudad está en una ubicación igualmente difícil. ↩
lo cual quizá no es una sorpresa considerando el clima predeciblemente templado de la Ciudad de México ↩
que es otro caso de estadísticas estadísticamente débiles… ↩
Una solución todavía simple pero mucho mejor: interpolar los valores de IMECA por contaminante, y después usar el máximo en todas partes. ↩
debido a las inversiones térmicas que atrapan la contaminación en el valle ↩

Llamando C++ desde Swift

Mon, 05 Dec 2016 17:44:00 -0600

Cuando recientemente estaba trabajando en azul, un visor de CityGML para Mac, mi primer pensamiento fue hacer un proyecto de Swift 3 puro. Pero ay, pronto descubrí que el XmlParser de Apple es terriblemente lento. En comparación con val3dity, la primera versión funcional del visor era al menos 10 veces más lenta en el análisis de XML.

La solución a este problema fue bastante simple: usar pugixml como backend de análisis de XML en su lugar¹. Sin embargo, pugixml está escrito en C++ y por lo tanto no se puede llamar directamente desde Swift. En mi campo de investigación en SIG esto es en realidad un problema muy típico, ya que la mayoría de las bibliotecas útiles están escritas en C/C++ (por ejemplo, Boost, CGAL, GDAL, GEOS). Considerando el tiempo relativamente corto que Swift lleva fuera y su reconocidamente limitado atractivo, sospecho que este es el caso de mucha gente.

Entonces, ¿cómo llamas código de C++ desde Swift 3? Hay diferentes maneras de hacerlo, pero en mi opinión la mejor involucra un doble envoltorio de Objective-C++ con un header de Objective-C puro.

Un doble envoltorio

Usaré ejemplos tomados directamente de azul. Así que, asumiendo que tienes una clase de C++ CityGMLParser, simplemente necesitas crear un header de Objective-C CityGMLParserWrapperWrapper.h:

struct CityGMLParserWrapper;

@interface CityGMLParserWrapperWrapper: NSObject {
  struct CityGMLParserWrapper *parserWrapper;
}

- (id) init;
- (void) dealloc;

Nota que usamos una declaración adelantada del primer envoltorio CityGMLParserWrapper y almacenamos un puntero a él en el segundo envoltorio. De esta manera, podemos mantener el header como Objective-C puro y así llamarlo desde Swift.

A continuación, definimos su implementación en un Objective-C++ CityGMLParserWrapperWrapper.mm:

#import "CityGMLParserWrapperWrapper.h"
#import "CityGMLParser.hpp"

struct CityGMLParserWrapper {
  CityGMLParser *parser;
};

@implementation CityGMLParserWrapperWrapper

- (id) init {
  if (self = [super init]) {
    parserWrapper = new CityGMLParserWrapper();
    parserWrapper->parser = new CityGMLParser();
  } return self;
}

- (void) dealloc {
  delete parserWrapper->parser;
  delete parserWrapper;
}

Nota que CityGMLParser es la clase de C++, y que necesitamos crear los dos niveles de envoltorio en init y eliminarlos (al estilo C++) en el dealloc. Este archivo puede contener tanto C++ como Objective-C++ lo permita.

Finalmente, probablemente necesites añadir un bridging header que contenga la declaración de importación de tu envoltorio doble para que pueda ser usado en Swift. Si usas Xcode, esto debe configurarse en la pestaña Build Settings de la configuración del proyecto. Simplemente necesita contener algo como:

#import "CityGMLParserWrapperWrapper.h"

Pasando información entre código de C++ y de Swift

Ahora, probablemente necesitarás pasar información entre el código de C++ y el de Swift. Esto es relativamente sencillo, pero es una de las áreas donde Swift ofrece poco azúcar sintáctico.

Si estás usando un tipo de datos POD, esto es lo más fácil. Solo añade getters y setters apropiados en tu envoltorio doble. Estos deberían hacer llamadas de la forma return parserWrapper->parser->... o parserWrapper->parser->... = ....

Así que veamos directamente algo un poco más difícil: cómo leer un arreglo u otra secuencia de elementos contiguos en memoria de tamaño conocido.

Un par de arreglos

En mi código de C++, tengo un par de arreglos que guardan la caja delimitadora que rodea mis datos:

float minCoordinates[3];
float maxCoordinates[3];

Para acceder a estos, tengo un par de declaraciones de métodos en mi envoltorio de Objective-C:

- (float *) minCoordinates;
- (float *) maxCoordinates;

Nota que devolveremos un puntero. Esta será la dirección del primer elemento de cada arreglo. Entonces, la implementación de estos métodos es sencilla:

- (float *) minCoordinates {
  return parserWrapper->parser->minCoordinates;
}

- (float *) maxCoordinates {
  return parserWrapper->parser->maxCoordinates;
}

Iteradores

Ahora veamos un ejemplo más complejo. En azul, necesitaba una forma de obtener estructuras de datos mucho más complejas que fueron creadas en C++. Estas estructuras de datos consistían en std::lists de clases personalizadas que contenían varios atributos.

En tales casos donde no sabes exactamente dónde podrían estar almacenadas las cosas², la forma más fácil de transferir información es definiendo iteradores personalizados y pasando la información objeto por objeto y atributo por atributo.

Así que, en mi código de C++ creé varios iteradores como este:

std::list<CityGMLObject>::const_iterator currentObject;

Entonces, en el envoltorio doble definí los métodos apropiados para inicializar, avanzar y comprobar si el iterador ha terminado:

- (void) initialiseObjectIterator;
- (void) advanceObjectIterator;
- (BOOL) objectIteratorEnded;

Estos pueden implementarse simplemente llamando a las respectivas funciones de iterador de C++:

- (void) initialiseObjectIterator {
  parserWrapper->parser->currentObject = parserWrapper->parser->objects.begin();
}

- (void) advanceObjectIterator {
  ++parserWrapper->parser->currentObject;
}

- (BOOL) objectIteratorEnded {
  if (parserWrapper->parser->currentObject == parserWrapper->parser->objects.end()) {
    return true;
  } return false;
}

Cadenas de texto

Ahora, veamos cómo extraer variables de C++ un poco más complejas como std::strings u otros tipos que pueden extraerse como bloques contiguos de memoria que no tienen una longitud fija.

En el caso de un std::string, el truco es usar su representación en C como un const char * y también recibir un lugar donde pasar su longitud al código de Swift. Un getter en el envoltorio doble puede entonces verse así:

- (const char *) currentObjectTypeWithLength: (unsigned long *)length;

Nota que usamos un unsigned long ya que eso es equivalente a un UInt de Swift. La implementación sería así:

- (const char *) currentObjectTypeWithLength: (unsigned long *)length {
  *length = parserWrapper->parser->currentObject->type.size();
  return parserWrapper->parser->currentObject->type.c_str();
}

A diferencia de los otros ejemplos, el código de Swift no es trivial y por lo tanto también lo explicaré:

var objectTypeLength: UInt = 0
let firstElementOfObjectTypeBuffer = UnsafeRawPointer(cityGMLParser.currentObjectType(withLength: &objectTypeLength))
let objectTypeData = Data(bytes: firstElementOfObjectTypeBuffer!, count: Int(objectTypeLength)*MemoryLayout<Int8>.size)
objects.last!.type = String(data: objectTypeData, encoding: .utf8)!

Hay algunas cosas que ver aquí. Primero definimos la variable donde almacenaremos la longitud de la cadena objectTypeLength y la pasamos como un puntero usando &objectTypeLength. El valor de retorno se convierte inmediatamente a un UnsafeRawPointer.

Entonces, usamos el Data de Swift para almacenar el contenido del buffer en la ubicación del puntero devuelto. Y finalmente, podemos crear una String de Swift usando los datos del buffer.

que también se usa en val3dity ↩
o es engorroso averiguarlo ↩

Swift 3 y Metal

Thu, 17 Nov 2016 16:04:00 -0600

Como continuación del post anterior, quizá también sea útil explicar la forma más fácil de dibujar en una vista de Cocoa usando Metal en lugar de OpenGL¹. Y como extra, también explico cómo elegir entre el renderizado con OpenGL o con Metal sobre la marcha.

Algo de contexto

Apple nunca ha sido diligente a la hora de estar al día con las nuevas versiones de OpenGL (o con las tarjetas gráficas más recientes, para el caso), pero la situación ha llegado a un punto bastante malo. Incluso el hardware más nuevo solo soporta el vetusto OpenGL 4.1 de hace seis años. En comparación, Metal está en desarrollo constante y cada WWDC se anuncian un montón de funciones nuevas. Pero quizá por la misma razón hay una escasez de documentación y de ejemplos buenos, introductorios y actualizados².

Ahora, para ser honesto, preferiría usar algo abierto y multiplataforma como Vulkan, pero sigue sin estar disponible en macOS (y no espero que eso cambie en el futuro). O podría pasarme a Windows. Es broma. Por supuesto que me pasaría a Linux en su lugar.

Dibujando en un MTKView

Con mucho, la forma más fácil de dibujar en una vista de Cocoa es subclasificar MTKView, parte de MetalKit y disponible desde iOS 9 y El Capitan en adelante. Esto es similar a NSOpenGLView para OpenGL, y significa que la mayoría de las cosas se gestionan automáticamente por ti. Así que probablemente necesites configurar una clase como esta:

import Metal
import MetalKit

class MetalView: MTKView {
  var commandQueue: MTLCommandQueue?
  var renderPipelineState: MTLRenderPipelineState?
  var depthStencilState: MTLDepthStencilState?
}

Después, crea el método init() y configura ahí el dispositivo de Metal, las propiedades de MTKView, la cola de comandos, el pipeline de renderizado, los shaders y el depth stencil. Lo mismo si necesitas texturas u otros stencils.

required init(coder: NSCoder) {
  
  super.init(coder: coder)
  
  // Device
  device = MTLCreateSystemDefaultDevice()
  
  // View
  clearColor = MTLClearColorMake(1.0, 1.0, 1.0, 1)
  colorPixelFormat = .bgra8Unorm
  depthStencilPixelFormat = .depth32Float
  
  // Command queue
  commandQueue = device!.makeCommandQueue()
  
  // Render pipeline
  let library = device!.newDefaultLibrary()!
  let vertexFunction = library.makeFunction(name: "vertexTransform")
  let fragmentFunction = library.makeFunction(name: "fragmentLit")
  let renderPipelineDescriptor = MTLRenderPipelineDescriptor()
  renderPipelineDescriptor.vertexFunction = vertexFunction
  renderPipelineDescriptor.fragmentFunction = fragmentFunction
  renderPipelineDescriptor.colorAttachments[0].pixelFormat = colorPixelFormat
  renderPipelineDescriptor.depthAttachmentPixelFormat = depthStencilPixelFormat
  do {
    renderPipelineState = try device!.makeRenderPipelineState(descriptor: renderPipelineDescriptor)
  } catch {
    Swift.print("Unable to compile render pipeline state")
    return
  }
  
  // Depth stencil
  let depthSencilDescriptor = MTLDepthStencilDescriptor()
  depthSencilDescriptor.depthCompareFunction = .less
  depthSencilDescriptor.isDepthWriteEnabled = true
  depthStencilState = device!.makeDepthStencilState(descriptor: depthSencilDescriptor)
}

Finalmente, crea el método draw, que se llamará automáticamente en cada frame, automáticamente con una notificación de la vista o manualmente, dependiendo de cómo configures isPaused y enableSetNeedsDisplay.

override func draw(_ dirtyRect: NSRect) {
    let commandBuffer = commandQueue!.makeCommandBuffer()
    let renderPassDescriptor = currentRenderPassDescriptor!
    let renderEncoder = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDescriptor)
    
    renderEncoder.setFrontFacing(.counterClockwise)
    renderEncoder.setDepthStencilState(depthStencilState)
    renderEncoder.setRenderPipelineState(renderPipelineState!)
    
    // Draw something...
    
    renderEncoder.endEncoding()
    let drawable = currentDrawable!
    commandBuffer.present(drawable)
    commandBuffer.commit()
  }

Eligiendo entre el renderizado con Metal o con OpenGL sobre la marcha

Si te emociona el rendimiento de Metal (como a mí) pero quieres soportar hardware de Mac más antiguo que 2012 (como a mí), probablemente quieras elegir sobre la marcha entre subclases personalizadas de MTKView y NSOpenGLView. De esa manera, probablemente puedas tirar el código de OpenGL en unos pocos años sin reescrituras importantes del código.

Para mí, el primer paso fue aislar todo el código específico de OpenGL y de Metal en estas dos subclases. Después, creé un NSView de marcador de posición simple en Interface Builder y mantuve una referencia a él (aquí view). Ahora, cuando tu aplicación se carga puedes hacer algo como esto:

func applicationDidFinishLaunching(_ aNotification: Notification) {
  
  let processInfo = ProcessInfo.processInfo
  let sierraOrHigher = processInfo.isOperatingSystemAtLeast(OperatingSystemVersion(majorVersion: 10, minorVersion: 12, patchVersion: 0))
  if sierraOrHigher, let defaultDevice = MTLCreateSystemDefaultDevice() {
    let metalView = MetalView(frame: splitView.subviews[1].frame, device: defaultDevice)
    metalView.controller = self
    splitView.removeArrangedSubview(splitView.arrangedSubviews[1])
    splitView.insertArrangedSubview(metalView, at: 1)
    view = metalView
    window.makeFirstResponder(metalView)
  } else {
    let attributes: [NSOpenGLPixelFormatAttribute] = [
      UInt32(NSOpenGLPFAAccelerated),
      UInt32(NSOpenGLPFAColorSize), UInt32(24),
      UInt32(NSOpenGLPFADoubleBuffer),
      UInt32(NSOpenGLPFADepthSize), UInt32(32),
      UInt32(0)
    ]
    let pixelFormat = NSOpenGLPixelFormat(attributes: attributes)
    let openGLView = OpenGLView(frame: splitView.subviews[1].frame, pixelFormat: pixelFormat)
    openGLView!.controller = self
    splitView.removeArrangedSubview(splitView.arrangedSubviews[1])
    splitView.insertArrangedSubview(openGLView!, at: 1)
    view = openGLView
    window.makeFirstResponder(openGLView)
  }
}

Nota algunas cosas. Si quieres soportar las funciones más nuevas de Metal hasta 2016³, quieres probar el soporte de Sierra. Mi aplicación falla en 10.11 incluso con hardware compatible con Metal⁴, así que he forzado OpenGL en 10.11 o inferior. La forma más fácil de probar el soporte de Metal es revisar el valor de retorno de MTLCreateSystemDefaultDevice().

Además, sustituir una vista sobre la marcha es algo delicado. Sustituir solo la vista no tendrá ningún efecto, así que necesitas quitarla de su vista padre (en este caso splitView, una instancia de NSSplitView) y volver a añadir tu subclase de MTKView o NSOpenGLView.

Finalmente, para que esto funcione necesitas usar diferentes inicializadores en tus subclases de MTKView y NSOpenGLView. Estos deberían recibir el frame de la vista y otras variables en lugar de una instancia de NSCoder.

// In the MTKView subclass:
override init(frame frameRect: CGRect, device: MTLDevice?) {
  super.init(frame: frameRect, device: device)
  // Same as before...
}

// In the NSOpenGLView subclass:
override init?(frame: NSRect, pixelFormat: NSOpenGLPixelFormat?) {
  super.init(frame: frame, pixelFormat: pixelFormat)
  // Same as before...
}

Para mi aplicación, esto resultó en una mejora de rendimiento de aproximadamente 10 veces en comparación con OpenGL. Tu kilometraje puede variar. ↩
La clara excepción a esto son las sesiones de la WWDC 2016 de Apple sobre Adopting Metal. Consulta la parte 1 y la parte 2. No olvides revisar el código de muestra. ↩
¡¿Por qué Apple no pone números de versión claros?! ↩
Al igual que el propio código de muestra de Adopting Metal de Apple… ↩

Swift 3 y OpenGL

Sat, 05 Nov 2016 15:17:00 -0600

Aprender Swift había estado durante mucho tiempo en mi lista de pendientes. Así que, cuando recientemente emprendí el proyecto de escribir un visor de CityGML para Mac (que se lanzará pronto), decidí que el momento de aprender Swift era ahora. Afortunadamente, Apple acababa de lanzar Swift 3, y como me gustan las cosas nuevas y brillantes, decidí aprender Swift 3 directamente.

Sin embargo, pronto me di cuenta de que la documentación de Apple es muy irregular. A pesar del nuevo aspecto de las páginas de documentación, casi todo el código de muestra y los ejemplos todavía usan Objective-C. Además, interactuar con APIs de C de bajo nivel como OpenGL es más que un poco complejo, ya que requiere varias conversiones y el uso de tipos de datos similares a punteros.

Por lo tanto, espero documentar algunos de los problemas que me dejaron atascado y cómo los resolví. En este post, explicaré cómo dibujar OpenGL en un NSOpenGLView o en un NSView personalizado. Para más información, consulta la documentación de Apple (que usa Objective-C). Echa un vistazo a esta pregunta y respuestas de Stack Overflow sobre cómo funciona esto con Swift 2.

Usando NSOpenGLView

La forma más fácil de dibujar OpenGL es subclasificar NSOpenGLView. De esta manera, la mayoría de las cosas se manejan automáticamente por ti. Así que probablemente necesites configurar una clase como esta:

import Cocoa
import OpenGL
import GLKit

class OpenGLView: NSOpenGLView {
  var displayLink: CVDisplayLink?
}

Después, crea el método init?() y configura ahí el formato de píxeles, el contexto y el intervalo de intercambio de OpenGL.

required init?(coder: NSCoder) {
  super.init(coder: coder)
  
  let attributes: [NSOpenGLPixelFormatAttribute] = [
    UInt32(NSOpenGLPFAAccelerated),
    UInt32(NSOpenGLPFAColorSize), UInt32(32),
    UInt32(NSOpenGLPFADoubleBuffer),
    UInt32(NSOpenGLPFAOpenGLProfile),
    UInt32(NSOpenGLProfileVersion3_2Core),
    UInt32(0)
  ]
  self.pixelFormat = NSOpenGLPixelFormat(attributes: attributes)
  self.openGLContext = NSOpenGLContext(format: pixelFormat, share: nil)
  self.openGLContext?.setValues([1], for: NSOpenGLCPSwapInterval)
  
}

Después, crea el método prepareOpenGL() y su callback. Esto se llamará antes del primer render y tiene como objetivo inicializar el estado de OpenGL. En este ejemplo, configuramos CVDisplayLink para que se llame a una función callback que renderice cada nuevo frame.

Nota los tipos de puntero UnsafePointer, UnsafeMutablePointer y UnsafeMutableRawPointer, y cómo unsafeBitCast se usa para convertir el UnsafeMutableRawPointer en una instancia de la clase actual. Esto es necesario para poder llamar cualquier método.

override func prepareOpenGL() {
    
  func displayLinkOutputCallback(displayLink: CVDisplayLink, _ now: UnsafePointer<CVTimeStamp>, _ outputTime: UnsafePointer<CVTimeStamp>, _ flagsIn: CVOptionFlags, _ flagsOut: UnsafeMutablePointer<CVOptionFlags>, _ displayLinkContext: UnsafeMutableRawPointer?) -> CVReturn {
      unsafeBitCast(displayLinkContext, to: OpenGLView.self).renderFrame()
      return kCVReturnSuccess
    }

  CVDisplayLinkCreateWithActiveCGDisplays(&displayLink)
  CVDisplayLinkSetOutputCallback(displayLink!, displayLinkOutputCallback, UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque()))
	CVDisplayLinkStart(displayLink!)
}

El método renderFrame() es llamado por la función callback en el CVDisplayLink. Ahí, puedes usar cualquier función de dibujo de OpenGL.

func renderFrame() {
  CGLLockContext(self.openGLContext.cglContextObj!)
  
  // Draw something...

  CGLFlushDrawable(self.openGLContext.cglContextObj!)
  CGLUnlockContext(self.openGLContext.cglContextObj!)
}

El método de dibujo debería llamar también a renderFrame().

override func draw(_ dirtyRect: NSRect) {
  super.draw(dirtyRect)
  renderFrame()
}

Finalmente, el método deinit() debería detener el display link.

deinit {
  CVDisplayLinkStop(displayLink!)
}

Dibujando en un NSView personalizado

A veces, NSOpenGLView no es suficiente. Por ejemplo, NSOpenGLView no soporta compartir contexto, lo cual es un problema si quieres crear aplicaciones de pantalla completa. En esos casos, necesitas subclasificar NSView en su lugar. Apple proporciona este pedazo de código de muestra para ese propósito, pero también está escrito en Objective-C y muy desactualizado.

Subclasificar NSView es similar al caso anterior. Sin embargo, necesitas conservar tu propio NSOpenGLPixelFormat y NSOpenGLContext.

import Cocoa
import OpenGL
import GLKit

class OpenGLView: NSView {
  var pixelFormat: NSOpenGLPixelFormat?
  var openGLContext: NSOpenGLContext?
  
  var displayLink: CVDisplayLink?
}

El método init? puede entonces ser prácticamente igual que antes, pero es necesario hacer que llame tu propio método para inicializar OpenGL (setupDisplayLink()) y el display link. Si quieres compartir contexto, probablemente quieras crear otro método init? que reciba el contexto a compartir. Asegúrate de llamar makeCurrentContext() en el contexto de OpenGL.

required convenience init?(coder: NSCoder) {
  self.init(coder: coder, context: nil)
}

init?(coder: NSCoder, context: NSOpenGLContext?) {
  // Set up pixel format and context...
  
  super.init(coder: coder)
  openGLContext!.makeCurrentContext()
  setupDisplayLink()
  
  // ...

  NotificationCenter.default.addObserver(self, selector: #selector(reshape), name: NSNotification.Name.NSViewGlobalFrameDidChange, object: self)
}

Los métodos sobreescritos para bloquear el foco y para dibujar la vista deberían establecer la vista del contexto como el propio view.

override func lockFocus() {
  super.lockFocus()
  if openGLContext!.view != self {
    openGLContext!.view = self
  }
}

override func draw(_ dirtyRect: NSRect) {
  if openGLContext!.view != self {
    openGLContext!.view = self
  }
  
  // Actually draw something...
  if !CVDisplayLinkIsRunning(displayLink!) {
    drawView()
  }
}

Finalmente, el método para dibujar cosas (llamado por draw() o por el callback del display link) debería hacer lo mismo que antes, pero también asegurarse de establecer el contexto actual de OpenGL.

func drawView() {
  CGLLockContext(openGLContext!.cglContextObj!)
  openGLContext!.makeCurrentContext()
  
  // Draw things...

  openGLContext!.flushBuffer()
  CGLUnlockContext(openGLContext!.cglContextObj!)
}

La terrible capa de transporte público de Google Maps

Wed, 27 Jul 2016 00:16:00 -0500

Hace dos días, Google lanzó una nueva versión de Google Maps. La mayoría de la gente parece estar de acuerdo en que es una buena mejora de un servicio que ya era genial. Cuando lo vi, inmediatamente me encantó el aspecto más limpio y la legibilidad mejorada.

Es decir, hasta que activé la capa de transporte público y vi que sigue tan fea y mal diseñada como siempre.

Como alguien a quien le apasionan tanto los mapas como el transporte público, esto es decepcionante. Han pasado más de 10 años desde que Google Transit apareció por primera vez en Google Labs y casi 9 años desde que se integró a Google Maps. Y así que decidí escribir un post de ‘name and shame’ para ver cuánto tiempo le toma a Google poner sus mapas de transporte público a la altura.

Entre otros problemas, la capa de tránsito de Google Maps sufre de líneas discontinuas, que se cruzan entre sí y entrecortadas, demasiado énfasis en las calles, etiquetas mal colocadas y mal coloreadas que a menudo son ilegibles, repetidas o faltantes, una falta de nombres de líneas y estaciones en la mayoría de los niveles de zoom, y una falta total del aspecto limpio de la capa estándar de Google Maps. En los países de Map Maker la información también es terriblemente inconsistente, con estaciones duplicadas, categorías equivocadas, nombres mal escritos, diferentes estilos de capitalización y mucha información superflua (por ejemplo, ‘Metro xxx’ para referirse a una estación llamada xxx).

Pero no te fíes solo de mi palabra. Mejor échale un vistazo a las capturas de pantalla de abajo, que comparan la bastante buena capa de transporte público en Apple Maps¹ (arriba) con la terrible de Google Maps (abajo) en varias ciudades y a diferentes escalas. Estoy seguro de que tú también verás una multitud de problemas.

Berlin

London

Mexico City

Montreal

New York City

Rio de Janeiro

San Francisco

Sydney

La verdad, esta es una de las pocas áreas donde Apple Maps está significativamente por delante de Google Maps. Aunque la cobertura de Apple Maps es bastante irregular. ↩

Programación independiente de la dimensión usando plantillas de C++

Sun, 10 Jul 2016 14:39:00 -0500

Es uno de esos dilemas típicos de la programación. La sabiduría popular (entre programadores) dicta que tu código puede ser eficiente pero inflexible, o flexible pero intensivo en recursos. Intentar hacer ambas cosas casi siempre falla espectacularmente.

Sin embargo, de vez en cuando uno encuentra una excepción bastante asombrosa, que a primera vista puede parecer casi magia. Es decir, hasta que aprendes cómo funciona a nivel técnico. Por ejemplo, hace varios años me dejó perplejo cómo DTrace—un buen framework de rastreo—logra alcanzar cero sobrecarga cuando no está habilitado.

Un tiempo después, tuve un sentimiento similar sobre cómo los mapas combinatorios de CGAL logran ser a la vez rápidos y completamente independientes de la dimensión. La respuesta está en una ingeniosa meta-programación con plantillas usando plantillas recursivas de C++11, una solución que después incorporé extensamente en mi trabajo de doctorado.

La meta-programación con plantillas es una técnica que usa plantillas para generar ciertas estructuras de datos o realizar ciertas computaciones durante la compilación de un programa en lugar de durante su ejecución. Esta técnica se usa normalmente como una forma de apoyar la programación genérica definiendo funciones que pueden manejar indistintamente diferentes tipos de datos. Por ejemplo, a menudo uso este ingenioso pedazo de código para parsear fácilmente números a diferentes tipos de datos.

template <typename T>
T string_to_number (const std::string &text, T def_value) {
  std::stringstream ss;
  for (std::string::const_iterator i = text.begin(); i != text.end(); ++i)
    if (isdigit(*i) || *i=='e' || *i=='-' || *i=='+' || *i=='.') ss << *i;
  T result;
  return ss >> result ? result : def_value;
}

Sin embargo, aparte de este uso común, las plantillas también pueden usarse para crear estructuras de datos y algoritmos complejos independientes del tipo y de la dimensión. CGAL hace esto usando la técnica de programación Traits, que explota las declaraciones typedef de C++ para crear tipos personalizados. Como ejemplo, usé este tipo de enfoque en mi tesis para convertir conjuntos de datos de n dimensiones en unos de (n+1) dimensiones. Los tipos de los conjuntos de datos de n y (n+1) dimensiones se derivan automáticamente con base en n, que se pasa como parámetro de plantilla en tiempo de compilación. Como la programación en dimensiones altas suele estar fuertemente limitada por el tiempo de CPU durante la ejecución, esto efectivamente trae lo mejor de ambos mundos: independencia de la dimensión y velocidad.

template <unsigned int dimension>
class Linear_cell_complex_extruder_with_range {
public:
  typedef typename Linear_cell_complex<dimension>::type Lower_dimensional_cell_complex;
  typedef typename Linear_cell_complex<dimension+1>::type Higher_dimensional_cell_complex;
  typedef Linear_cell_complex_extruder_with_range<dimension> Self;
  
private:
  Lower_dimensional_cell_complex ldcc;
  Higher_dimensional_cell_complex hdcc;
};

Sin embargo, para explotar realmente este tipo de mecanismo en la programación independiente de la dimensión, necesitas plantillas recursivas. Con ellas, puedes construir una estructura de datos compleja o resolver un problema iterando dimensión por dimensión en tiempo de compilación.

Consideremos un ejemplo similar a uno usado en mi tesis, una estructura de datos donde queremos almacenar un valor (representado aquí por un float, pero puede ser una estructura de datos arbitrariamente compleja por sí misma) para cada objeto (representado aquí por un puntero Object *) de cada dimensión. Esencialmente, esto sería un std::map<Object *, float>. Primero, definimos un struct personalizado llamado Value_map_of_dimension, que almacena el mapa de valores para una sola dimensión (parametrizada con plantilla). Nota el uso de typedef para definir type antes de usarlo.

template <unsigned int dimension>
struct Values_map_of_dimension {
public:
  typedef std::map<Object *, float> type;
  type values_map;
};

Después, usamos un struct parametrizado con plantilla que define Values_map_tuple_per_dimension_up_to, que almacenará una tupla dependiente de la dimensión de las estructuras de datos anteriores donde cada elemento de la tupla contendrá una instancia de Value_map_of_dimension. Aquí, el primer parámetro de plantilla es la dimensión y el segundo es la tupla, que se inicializa con una vacía.

template <unsigned int dimension, class Result = std::tuple<>>
struct Values_map_tuple_per_dimension_up_to;

Este struct se especializa usando una plantilla recursiva que antepone a la tupla una instancia de Values_map_of_dimension para la dimension actual y se llama a sí misma con dimension-1.

template <unsigned int dimension, class ... Result>
struct Values_map_tuple_per_dimension_up_to<dimension, std::tuple<Result ...>> {
  typedef typename Values_map_tuple_per_dimension_up_to<dimension - 1, 
    std::tuple<Values_map_of_dimension<dimension>, Result ...>>::type type;
};

Finalmente, este struct se especializa aún más con una condición de terminación para la dimensión 0, donde la tupla se devuelve tal cual.

template <class ... Result>
struct Values_map_tuple_per_dimension_up_to<0, std::tuple<Result ...>> {
  typedef std::tuple<Values_map_of_dimension<0>, Result ...> type;
};

Para que el compilador construya esta estructura de datos correctamente, es crucial asegurarse de que el último struct sea una especialización más completa de Values_map_tuple_per_dimension_up_to. Por lo tanto, debería tener un parámetro de plantilla menos que el anterior.

Usando un map o set de C++ con datos geométricos

Sun, 19 Jun 2016 18:25:00 -0500

Uno de los bloques de construcción más típicos de las computaciones geométricas eficientes es un índice espacial. Usando un índice espacial, es posible realizar muchas operaciones simples rápidamente, como obtener un conjunto de puntos únicos. Tal operación puede usarse luego para cosas como construir una estructura de datos topológica o indexar objetos más complejos.

Sin embargo, implementar correctamente un índice espacial es un desastre y, francamente, es excesivo para muchas aplicaciones prácticas. Y aún así, las computaciones sin uno pueden ser increíblemente lentas. Así que a menudo recurro a un truco rápido—usar un set o map de la biblioteca estándar de C++ con una función de comparación personalizada. Un set o map ofrece acceso a sus elementos en tiempo logarítmico, muy parecido a la mayoría de los índices espaciales, y funciona de fábrica para los tipos de datos simples de toda la vida como float o int. Además, para poder usarlo con cualquier clase con la que estés trabajando, solo necesita un functor de comparación personalizado¹ que defina un ordenamiento de sus elementos².

Así que veamos un ejemplo de un código en el que estoy trabajando actualmente. Un Point_d de CGAL es una estructura de datos simple para un punto de d dimensiones. Personalmente quiero usar este tipo de puntos para acceder rápidamente a objetos geométricos únicos ubicados en esas posiciones, así que creé un functor de comparación personalizado para ellos. Ordena los puntos primero por su dimensión y luego lexicográficamente por sus coordenadas:

struct Point_d_comparator {
  bool operator()(const Point_d &p1, const Point_d &p2) const {
    
    if (p1.dimension() < p2.dimension()) return true;
    if (p1.dimension() > p2.dimension()) return false;
    
    Point_d::Cartesian_const_iterator p1_coordinate = p1.cartesian_begin()
    Point_d::Cartesian_const_iterator p2_coordinate = p2.cartesian_begin();
    while (p1_coordinate != p1.cartesian_end()) {
      if (*p1_coordinate < *p2_coordinate) return true;
      if (*p1_coordinate > *p2_coordinate) return false;
      ++p1_coordinate;
      ++p2_coordinate;
    } return false;
  }
};

En un ejemplo simple, tal functor de comparación puede usarse para definir un conjunto de puntos únicos (según se definen por sus coordenadas). Por ejemplo, esto te permite asignar identificadores únicos a una ubicación.

std::set<Point_d, Point_d_comparator> vertices;

En un ejemplo más complejo, el mismo functor de comparación puede usarse para indexar un conjunto de aristas (según se definen por un par único de puntos inicio-fin). Personalmente uso este tipo de estructura para enlazar un conjunto de polígonos adyacentes por sus aristas comunes y para comprobar si tal conjunto forma un cuasi-manifold en 3D. ¡Ten en cuenta que debes asegurarte de insertar los dos puntos extremos en un orden bien definido, como el más pequeño lexicográficamente primero!

std::map<Point_d, std::map<Point_d, int, Point_d_comparator>, Point_d_comparator> edges;

Para una futura entrada de blog, cómo hacer algo similar con un unordered_map de C++11 más eficiente (tiempo constante) y una función de hash personalizada.

Un functor es un objeto que se comporta como una función. En C++, un functor es una class o struct que hace esto sobrecargando el operador (). A diferencia de los punteros a función, son rápidos ya que se generan en tiempo de compilación. ↩
La mayoría de las personas eligen imitar el valor del operador < (menor que), que es lo que set y map hacen con los tipos simples. ↩

Configurando CGAL con Qt5 y QGLViewer en Mac

Wed, 18 May 2016 19:30:00 -0500

CGAL dejó de dar soporte a Qt4 con la versión 4.7 en octubre. Pero ay, su fórmula de Homebrew no se ha actualizado para reflejar esto. En términos prácticos esto significa que no puedes usar aplicaciones Qt con CGAL, incluyendo todos los bonitos demos de GUI de CGAL que vienen listos para usar de fábrica (en su versión de Homebrew). Esto es malo si quieres construir tus propias aplicaciones de GUI, o usar los demos como tutorial o como base para tu propio código.

Recientemente pasé algún tiempo tratando de hacer funcionar el demo de Linear Cell Complex en Mac con el mínimo de complicaciones. Como ese demo requiere Qt5 y QGLViewer, el mismo procedimiento debería funcionar para muchos otros demos, así que decidí documentarlo aquí. Sin embargo, ten en cuenta que esta solución requiere que desenlaces Qt4 para poder enlazar Qt5, lo que romperá cualquier fórmula de Homebrew que dependa de qt¹.

Así que, primero desenlaza Qt4 (es decir, elimina los enlaces simbólicos que Homebrew crea en /usr/local) usando:

$ brew unlink qt

Después, instala y enlaza Qt5. Como Qt5 entra en conflicto con Qt4 y por lo tanto normalmente no se pretende enlazarlo simbólicamente en /usr/local, necesitas usar --force:

$ brew install qt5
$ brew link qt5 --force

Homebrew quiere mantener su propia jerarquía en /usr/local, pero el script de CMake para Qt5 asume que los mkspecs y plugins de Qt5 son accesibles desde la carpeta raíz. Así que, crea un par de enlaces simbólicos desde la versión más reciente de Qt5 en el Cellar de Homebrew (actualmente 5.6.1-1) en /usr/local²:

ln -s /usr/local/Cellar/qt5/5.6.1-1/mkspecs /usr/local/mkspecs
ln -s /usr/local/Cellar/qt5/5.6.1-1/plugins /usr/local/plugins

Después, modifiqué la fórmula de Homebrew para QGLViewer para cambiar su dependencia de qt a qt5³. Algo similar podría hacerse para otras fórmulas que dependen de qt. Para esto, primero edita la fórmula:

$ brew edit libqglviewer

Y cambia depends_on "qt" a depends_on "qt5". Si no has configurado un editor de texto para Homebrew, usarás vim por defecto. Así que presiona I para cambiar al modo de inserción, cambia lo que necesites, después presiona ESC para salir del modo de inserción, y luego escribe :wq para guardar y salir.

Ahora que la fórmula ha sido modificada, puedes instalar QGLViewer (o cualquier otra fórmula que necesites) compilándola desde el código fuente usando:

$ brew install libqglviewer --build-from-source

Finalmente, puedes descargar CGAL e instalarlo desde el código fuente. Mi forma preferida de hacer esto es ir a una carpeta apropiada en tu computadora y clonar el repositorio de CGAL:

$ git clone https://github.com/CGAL/cgal.git

Luego configurarlo usando la GUI de CMake⁴ y compilarlo e instalarlo usando make:

$ cmake-gui .
$ make
$ sudo make install

En la GUI de CMake deberías poder seleccionar las opciones que necesitas, incluyendo WITH_CGAL_Qt5 y WITH_demos.

Actualización 27 jul 2016: Se agregaron instrucciones para enlazar simbólicamente los mkspecs y plugins de Qt5, y una nota sobre cmake-gui.

Idealmente, debería ser posible compilar CGAL con un Qt5 no enlazado usando -L/usr/local/opt/qt5/lib y -I/usr/local/opt/qt5/include. Sin embargo, esto no me funciona a mí. Por favor avísame si logras hacer que esto funcione. ↩
Gracias a stephane-lb en https://github.com/Homebrew/legacy-homebrew/issues/29938 por el consejo. Esto podría resolverse usando las rutas de Qt de CMake, pero ay, no pude lograr que funcionaran. ↩
O mejor aún, haz una rama de la fórmula y cámbiala ahí. ↩
Para ser honestos, es bastante molesto: el paquete de CMake de Homebrew no incluye su GUI. Así que quizás quieras instalar la versión oficial .pkg (que no causa problemas de compatibilidad con Homebrew) o usar el cmake de línea de comandos con los parámetros -D apropiados. ↩