Alguien que me ayude. Qué horrible. Millones. Billones de actividades pendientes.  256k de actividades pendientes. La bitácora de khpx tiene un cuarto de mega de tamaño. 256k bytes de texto. Parece poco pero es realmente grande. Si le das a la tecla down en un editor a ese archivo, puedes tardar 5 minutos en llegar al fondo (mentira: tienes que darle ~80 veces, eso tarda menos de un minuto!). Increible.

Nuevo sistema de cache

Instalé WP Fastest Cache en el sitio para que cuando llegue al front-page de hackernews no pase pena. Si llegas al front-page de hackernews muy posiblemente vas a tener 18k hits en algo así como 1 hora o algo más. Así que estoy preparado. Datos tomados en alguna parte del blog de este tipo (https://nicklafferty.com) que escribió Yo gasté $6 millones en Google ads. post que llegó a la front-page de hackernews , así que él sabe de lo que habla.

una historia de khpx

Duot Peret es una anomalía en el cubo 14-28-57 porque podría ser catalogado como un jefe tipo 5, en un cubo donde la mayoría son tipo 1. Su presencia desde hace 20 años en el planeta Hanso (Laicerne) ha pasado sorprendentemente desapercibida, o sospechosamente ignorada. Su nombre no aparece en el manual de Bak Sanak ni los Etier lo tienen catalogado. No hay una descripción en los sistemas sobre él, sino un protocolo o manual de operación. Es decir, cómo debe ser manejado diplomáticamente. En resumen, debe ser ignorado y no confrontado bajo ningún concepto.

Su control de Hanso es absoluto, siendo el único planeta del primer cubo bajo el yugo de un solo jefe. La duración de su gobierno ha llegado a nivel maduro, es decir, puede catalogarse como completamente asentado o afianzado, y su eliminación o extracción solo se puede lograr a través de medios naturales o por intervención externa. El protocolo indica que la posibilidad de ambas salidas es 0.

Hanso es un planeta con ilimitadas reservas de minerales y recursos agricolas que lo hacen inmensamente apetecible. Pero su ubicación en el borde del cubo alejado de otros planetas y sus fuertes defensas lo convierten en un duro y difícil objetivo. Ningún imperio galáctico ha mostrado el más minimo interes y la alianza con los etier hace su conquista y captura muy remota.

Hanso tiene su propio portal al cubo 15-28-57, pero debido al férreo control de Duot Peret, solo su regimen tiene acceso a este portal.

Hay 5 sistemas de defensas (SD1..SD5), ninguno confirmado por alguna entidad independiente. Esta información es anecdótica, lo que se puede oir en cualquier taberna del cubo. Ninguna academia, agencia o entidad suministrará corroboración alguna. En estos medios, Hanso es un planeta sin ningún interes conocido.

SD1

SD1 es este documento el que Ud. está leyendo, llamado Protocolo 122-34-36. La información suministrada no ha sido comprobada por lo que es un mecanismo de posible contrainformación. No ha sido validada por academia, agencia o entidad alguna. Ningún dato en este protocolo ha sido validado.

SD2

Los habitantes de Hanso dicen desconocer a Duot Peret. No hay, según ellos, autoridad unificada. Cada nación cuenta con su forma de gobierno, y hay varias federaciones que los unen, no necesariamente a todos. Su contacto con los imperios galácticos y sistemas vecinos es casi nulo. Ellos no reconocen el nombre Hanso, el planeta para ellos es Laicerne. Según ellos Hanso es un planeta diferente pero en el sistema solo hay 4 planetas y los otros 3 son gigantes gaseosos inhabitables. Este sistema de defensa, al igual que SD1, provee una capa de incertidumbre que diluye cualquier intento de penetración de los sistemas locales desde adentro. Si un sistema no es reconocido como existente no se puede permear.

SD3

El espacio interno de Hanso está controlado por naves XDFX-25, XDFK-25 y XDFM-25. Esto provee un escudo impenetrable al planeta y evita cualquier ataque. Para pasar esta defensa se requiere una flota imperial de primera categoria. Mantener esta costosa flota es una evidencia de los recursos de los que dispone Duot Peret, y lo decidido que está a mantener a sus enemigos alejados de Hanso. Este nivel de defensa ha sido confirmado por diferentes fuentes.

SD4

El sistema local de Hanso (3 grandes planetas estériles, Guregat, Guremok y Guregem) está dominado por un manto de neutrones que inutiliza todas las frecuencias de radio, todos los equipos electrónicos, todos los sistemas electricos. Computadoras y sistemas son inútiles dentro de esta área. Una nave que intente acercarse requiere un neutralizador de protones, tecnología costosa y difícil de conseguir. Este sistema de defensa ha sido reportado por diferentes fuentes, su existencia ha sido medianamente verificada.

SD5

Sobre la naturaleza de SD5 hay más especulaciones que sobre cualquiera de los otros SD{1..4}. Desde un agujero negro portátil que es capaz de enviarte al otro lado de la galaxia, a una legión de Veit-veits domesticados que devoran a cualquiera que intente acercarse al planeta sin autorización. Este sistema de defensa ha sido reportado por diferentes fuentes, pero los reportes son contradictorios. Su existencia no ha sido verificada en su totalidad.

Fin del protocolo

Nota del autor: para contexto sobre esta entrada ver la entrada anterior.

Replit usó amenazas legales para eliminar mi proyecto de código abierto. Como dicen en los comentarios, esta discusión es bien entretenida. El autor trabajó como pasante en la empresa Repl.it , que se dedica a proveer un ambiente de desarrollo que soporta decenas de lenguages de programación. El pasante, en un fin de semana hizo “algo” parecido, llamado riju, código abierto y alojado originalmente en github. Aquí están los detalles técnicos. Repl.it acusa al pasante de robarse ideas, de copiarse propiedad de Repl.it , etc. Ciertamente un pasante debería alejarse de replicar o utilizar ideas similares a la compañía donde trabajó, porque hay un problema ético en eso. El CEO de Repl.it tiene un sólido punto aquí. Pero.

¿Por qué Repl.it podría estar asustado, como para tener una reacción tan agresiva? Hay clones de esta aplicación como arroz. En los correos dicen que riju es basicamente un clone (no comercial y sin intención aparente de convertise en un producto), pero dado que los inversionistas de Repl.it han invertido $20 millones, el CEO de Repl.it simplemente está protegiendo a los inversionistas de competencia desleal. Él acusa al pasante de robarse las ideas que se discutieron internamente. Todo esto no justifica la agresividad. Una actitud positiva, conciliadora hubiera sido más apropiada. Este CEO es una patán.

Este es el caso de un excelente programador acosado por un CEO idiota. Yo voy a seguir la carrera del primero, e ignorar al segundo.

Aparte todo lo que se ha comentado en reddit y en Hacker News, yo creo que podemos aprender una lección aquí. El mensaje, el aprendizaje, es el siguiente: puedes conseguir $20 millones de financiamiento por una idea que se puede desarrollar en un fin de semana.

Discusión en reddit y en Hacker News.

Factorio Dev Blog

Llegó a mis ojos via este artículo el sitio Friday Facts, el blog de desarrollo de Factorio, un juego donde construyes y mantienes fábricas, con punto de vista semi isométrico, gráficos de bajo nivel, etc. Tiene 2m de descargas, y está rankeado como uno de los juegos más populares de Steam. Yo lo he descargado y realmente no es lo mío, a pesar de que khpx tiene quests en los que debes administrar/mantener fábricas (o industrias como se llama dentro de khpx)

Estuve hojeando el blog con displicencia, cuando ví esto en el capítulo fff-115:

“Los tiempos de compilación en C++ apestan. El hecho de tener que esperar 3 minutos y medio cada vez que se recompila Factorio me impacienta y me hace poco efectivo. Aparte de las razones bien conocidas, existe el problema de que el STL (standard template library) y los headers de boost no se preocupan mucho por la optimización de la inclusión [de archivos], por lo que incluir un solo archivo de estos puede llevar a cientos de miles de líneas en el módulo. Esto hace la compilación más lenta incluso cuando se preprocesa en headers precompilados. Esto me dio la idea de escribir nuestro propio subconjunto de STL+boost (las partes que más usamos).”

Esto me paralizó porque khpx usa masivamente STL. Pero dos segundos después me tranquilicé, no solamente porque preocuparme por esto sería como preocuparse por el problema #692 cuando estoy resolviendo el problema #8, sino porque yo tengo una distribución de archivos bastante agresiva y la compilación en sí no debería ser problema sino el linkeo. Además, yo uso Visual Studio que soporta headers precompilados, lo cual acelera bastante el proceso.

Ahora se me ocurre que una de mis críticas a la engine permafrost (ver mi post anterior) es la reinvención de la rueda, programar desde cero funciones que están disponibles en STL (o en otras librerías), y una de las razones para hacer esto podría ser la optimización. Pero, reflexionando sobre el tema, concluyo que sigue siendo ridículo. Los desarrolladores de Factorio lo reconocen en el post mencionado, diciendo que reprogramar las funciones de STL+boost es cuestión de años.

La reflexión fue interesante de todas maneras y me sirve de alerta para el futuro. Todo este tema justifica una vez más porqué es importante leer dev blogs, lo que te permite descubrir cosas por adelantado, cosas en las que jamás he pensado, y evita que te lleves sorpresas cuando ya tienes el agua al cuello.

Enlaces: Factorio, Factorio dev blog Friday Facts, artículo sobre Friday Facts.

Protocolo 122-34-36

Duot Peret es una anomalía en el cubo 14-28-57 porque podría ser catalogado como un jefe tipo 5, en un cubo donde la mayoría son tipo 1. Su presencia desde hace 20 años en el planeta Hanso (Laicerne) ha pasado sorprendentemente desapercibida, o sospechosamente ignorada. Su nombre no aparece en el manual de Bak Sanak ni los Etier lo tienen catalogado. No hay una descripción en los sistemas sobre él, sino un protocolo o manual de operación. Es decir, cómo debe ser manejado diplomáticamente. En resumen, debe ser ignorado y no confrontado bajo ningún concepto.

Mi próximo post forma parte del wiki de khpx, y se refiere a un inusual boss localizado en el cubo inicial. El párrafo anterior es la introducción a este boss, el primero que los jugadores deberían confrontar. Leyendo la forma enciclopédica, o quizás tipo informe de inteligencia militar en que está escrito, me recordó un sitio que estuve hojeando hace algunos meses atrás. Se trata de La fundación SCP , una colección de historias sobre personajes, artefactos e inclusive ideas de manipulación delicada y que requiere ser contenidas, aseguradas y protegidas. Si no entiendes de qué hablo, paséate por el sitio, quedarás atrapado, o quizás no.

Volviendo a Duot Peret, dice que es un boss inusual porque ningún jugador en el cubo inicial tiene capacidad de vencerlo, de hecho un jugador va a requerir al menos visitar los primeros 5 cubos (es decir se convierte en un jugador tipo 5) para poder planificar un ataque a la guarida de Duot Peret, el planeta Hanso.

Pero: si hay una forma de penetrar Hanso y sus tesoros en tipo 1.

Pero: Hanso puede ser vital para llegar al tercer cubo tempranamente.

Pero: no todos los caminos que conducen a Hanso, llegan a Hanso.

Duot Peret es mi versión de Hogger, el primer boss de wow (World of Warcraft), cuyo encuentro, y primer combate, era legendario en aquéllos tiempos cuando wow era un juego legendario. Pero Duot Peret es en cierta forma más tortuoso, inalcanzable, apetecible sobretodo, y al mismo tiempo, intrigante.

Más en la siguiente entrada.

Estaba analizando este código fuente de un juego RTS (real time strategic, o juego de estrategia a tiempo real), y mi opinión en general coincide con los comentarios que aparecen en este hilo de discusión en hackers news (también en reddit, pero hace un año).

Bueno, no exactamente “excelente” pero tiene un buen nivel de calidad. El programador es un profesional. Me llama la atención la forma consistente y repetitiva tanto en hn como en reddit de comentarios como “bravo!”, “Nice and clean code”, “awesome”, “amazing”, en forma uniforme y generalizada. Bien inusual. Más bien raro.

Algunas observaciones:

Buena organización (mencionado en los comentarios y también por el programador). Esto claramente es lo que impacta desde el comienzo. Los juegos son piezas de software bien complicadas, por lo que mantener una consistente y clara forma de organizar los distintos componentes es la clave. He visto docenas de juegos que hacen un genuino intento en lograr esto, fracasando la mayor parte de las veces. En khpx los resultados han sido mixtos y mi apreciación es que al igual del manejo de las estructuras de datos, lograr una organización óptima, eficiente, clara, que facilite el mantenimiento del código no solamente es difícil, sino que consume una inmensa y costosisima cantidad de tiempo. Yo he ido dilatando esta labor pero es algo que hay que atacar a tiempo antes de perder el control del engine.

Uso de goto. Algunos comentadores aplaudieron el uso de “goto” de forma de generar una salida única para las funciones. Es decir, el código está lleno de cosas como esta:

static bool rstate_init (...)
{
    if(!rstate->sq_lock)
        goto fail_sq_lock;
    ...
    if(!rstate->sq_cond)
        goto fail_sq_cond;
    ...
fail_sq_cond:
    SDL_DestroyMutex(rstate->sq_lock);
fail_sq_lock:
    return false;
}

Y la respuesta es que es más fácil de seguir, o que es más facil agregar instrucciones en un punto único de salida. En mi opinión un “goto” nunca es más facil de seguir, y genera rápidamente código espaguetti indescifrable. Además, no se supone que las funciones deben tener unas 30-50 líneas (no más de 100)? Y que las funciones deben tener 1 quizás 2 actividades que realizar? Entonces por qué un único punto de salida es importante si debería haber en una función 1-2 salidas? De acuerdo a mi script bash, en la permafrost-engine hay 667 “goto”s. En khpx hay 0.

Es un proyecto grande, pues tiene 127k líneas de código (sin incluir scripts y utilities). khpx luego de 3 años tiene la mitad, algo más de 60k. En el hilo de reddit mencionan 38KLOC (hace un año), no sé cómo hacen el conteo de líneas de código. Yo hago un conteo crudo con mi script todo propósito / todo terreno en una línea de código Bash:

find . -type f -exec cat {} + | wc -l

Reinvención de la rueda. Esto es algo que yo he estado evadiendo al máximo en khpx, por ello utilizo algunas librerías como Dear Imgui y el STL (el standard template library). Nadie discute que el STL está suficientemente probado y optimizado. No hay razón para utilizar algo diferente. permafrost-engine re-implementa todo, incluyendo vectores, queues, y… ta ta: malloc, su propio sistema de manejo de memoria. Nada más por eso yo descartaría esta engine. Ni idea por qué los aplausos.

Poca documentación, y los pocos comentarios sufren el síndrome de inutilidad:

/* Submit and run the queued batch to completion */
render_thread_start_work();

Uso de macros. No usar macros es una buena práctica. permafrost-engine usa macros masivamente. Hay 1357 “#define”s. No sé, yo voy a seguir “no usándolos”, o usándolos al minimo: hay 170 defines en khpx.

Indirección redirigida. Si buscamos el caracter ‘&’ en permafrost-engine el resultado son 8282 matches. En khpx es 1350. ¿Pero por qué? Porque esta engine usa cosas como “&task->ctx” al máximo. Festival universal ilustrado de apuntadores. No hay nada malo per se en ello. Pero es una mala práctica en 2021.

Extra. Por cierto, ¿recuerdan mi post sobre *scanf? En permafrost-engine hay 53 ocurrencias, en khpx hay 0.

Variables / data structures globales. Excelente manejo. Todas están definidas como “static” y confinadas a su archivo. En khpx las estructuras de datos vuelan por todo el engine sin control de acceso alguno. Este es un punto que en algún momento tengo que corregir, por dificil que me parezca en este momento.

Conclusiones

Como digo al comienzo es un trabajo profesional y la engine es de alta calidad. Salvo los comentarios anteriores, fue una buena experiencia revisar el código y lo recomiendo altamente. De hecho voy a utilizar ideas de esta engine para resolver el problema que tiene khpx al manejar las estructuras de datos.