diff --git a/docs/.vitepress/configs/navbar.ts b/docs/.vitepress/configs/navbar.ts
index fd272ab..4778041 100644
--- a/docs/.vitepress/configs/navbar.ts
+++ b/docs/.vitepress/configs/navbar.ts
@@ -6,28 +6,23 @@ export const navbar: DefaultTheme.NavItem[] = [
link: 'https://faq.utnso.com.ar/blog'
},
{
- text: 'Docs',
- items: [
- {
- text: 'Primeros pasos',
- link: '/primeros-pasos/',
- activeMatch: '/primeros-pasos/'
- },
- {
- text: 'Guías',
- link: '/guias/',
- activeMatch: '/guias/',
- },
- {
- text: 'Consultas',
- link: '/consultas',
- activeMatch: '/consultas',
- },
- {
- text: '¿Quiénes somos?',
- link: '/quienes-somos',
- },
- ],
+ text: 'Primeros pasos',
+ link: '/primeros-pasos/',
+ activeMatch: '/primeros-pasos/'
+ },
+ {
+ text: 'Guías',
+ link: '/guias/',
+ activeMatch: '/guias/',
+ },
+ {
+ text: 'Consultas',
+ link: '/consultas',
+ activeMatch: '/consultas',
+ },
+ {
+ text: '¿Quiénes somos?',
+ link: '/quienes-somos',
},
{
text: 'Inscripciones',
diff --git a/docs/.vitepress/configs/sidebar.ts b/docs/.vitepress/configs/sidebar.ts
index 6c5e790..139eadc 100644
--- a/docs/.vitepress/configs/sidebar.ts
+++ b/docs/.vitepress/configs/sidebar.ts
@@ -32,7 +32,7 @@ export const sidebar: DefaultTheme.Sidebar = [
},
{
text: 'Primeros pasos',
- collapsed: true,
+ collapsed: false,
items: [
{
text: '¿Dónde me anoto?',
@@ -48,7 +48,23 @@ export const sidebar: DefaultTheme.Sidebar = [
},
{
text: 'Crear tu primer proyecto C',
- link: '/primeros-pasos/entorno-desarrollo'
+ link: '/primeros-pasos/primer-proyecto-c'
+ },
+ {
+ text: 'Git para el Trabajo Práctico',
+ link: '/primeros-pasos/git'
+ },
+ {
+ text: 'Manejo de Punteros',
+ link: '/guias/programacion/punteros',
+ },
+ {
+ text: 'Guía de Sockets',
+ link: '/guias/linux/sockets',
+ },
+ {
+ text: 'Guía de Serialización',
+ link: '/guias/linux/serializacion',
},
{
text: 'Trabajo Práctico 0',
@@ -58,20 +74,20 @@ export const sidebar: DefaultTheme.Sidebar = [
},
{
text: 'Consola de Linux y Git',
- collapsed: true,
+ collapsed: false,
items: [
{
text: 'Guía de uso de Bash',
link: '/guias/consola/bash'
},
- {
- text: 'Git para el Trabajo Práctico',
- link: '/guias/consola/git'
- },
{
text: 'Rutas Relativas y Absolutas',
link: '/guias/consola/rutas'
},
+ {
+ text: 'Guía de despliegue de TP',
+ link: '/guias/herramientas/deploy'
+ },
{
text: 'Mario Bash',
link: 'https://faq.utnso.com.ar/mariobash'
@@ -84,16 +100,12 @@ export const sidebar: DefaultTheme.Sidebar = [
},
{
text: 'Programación en C',
- collapsed: true,
+ collapsed: false,
items: [
{
text: 'Repaso de Arquitectura',
link: 'https://faq.utnso.com.ar/guia-repaso-arquitectura'
},
- {
- text: 'Manejo de Punteros y Memoria Dinámica',
- link: '/guias/programacion/punteros',
- },
{
text: 'Buenas Prácticas de C',
link: '/guias/programacion/buenas-practicas'
@@ -103,13 +115,9 @@ export const sidebar: DefaultTheme.Sidebar = [
link: '/guias/programacion/main'
},
{
- text: 'Cómo hacer una consola interactiva',
+ text: 'Hacer una consola interactiva',
link: '/guias/programacion/readline'
},
- {
- text: 'Video de Shared Libraries',
- link: '/guias/programacion/shared-libraries'
- },
{
text: 'Tutorial interactivo de C',
link: 'https://www.learn-c.org/'
@@ -118,18 +126,10 @@ export const sidebar: DefaultTheme.Sidebar = [
},
{
text: 'Syscalls de Linux',
- collapsed: true,
+ collapsed: false,
items: [
{
- text: 'Guía de Sockets',
- link: '/guias/linux/sockets',
- },
- {
- text: 'Guía de Serialización',
- link: '/guias/linux/serializacion',
- },
- {
- text: 'Charla de Threads y Sincronización',
+ text: 'Charla de Threads y Sincro',
link: '/guias/linux/threads',
},
{
@@ -140,12 +140,8 @@ export const sidebar: DefaultTheme.Sidebar = [
},
{
text: 'Herramientas útiles',
- collapsed: true,
+ collapsed: false,
items: [
- {
- text: 'Guía para crear proyectos C',
- link: 'https://raniagus.github.io/so-project-template/'
- },
{
text: 'Debugging en Eclipse',
link: '/guias/herramientas/debugger'
@@ -158,10 +154,6 @@ export const sidebar: DefaultTheme.Sidebar = [
text: 'Unit Testing con CSpec',
link: '/guias/herramientas/cspec'
},
- {
- text: 'Guía de despliegue de TP',
- link: '/guias/herramientas/deploy'
- },
],
},
]
diff --git a/docs/.vitepress/theme/index.js b/docs/.vitepress/theme/index.js
index 8040b6a..e311246 100644
--- a/docs/.vitepress/theme/index.js
+++ b/docs/.vitepress/theme/index.js
@@ -1,17 +1,32 @@
import DefaultTheme from 'vitepress/theme';
+import { onMounted, watch, nextTick } from 'vue';
+import { useRoute } from 'vitepress';
+import mediumZoom from 'medium-zoom';
import Image from './components/Image.vue';
import Link from './components/Link.vue';
import YouTube from './components/YouTube.vue';
-import './styles/custom.scss';
-import './styles/print.scss';
+import './index.scss';
export default {
...DefaultTheme,
- enhanceApp: (ctx) => {
+ enhanceApp(ctx) {
//DefaultTheme.enhanceApp(ctx);
ctx.app.component('Image', Image);
ctx.app.component('Link', Link);
ctx.app.component('YouTube', YouTube);
},
+ setup() {
+ const route = useRoute();
+ const initZoom = () => {
+ mediumZoom('.main img', { background: 'var(--vp-c-bg)' });
+ };
+ onMounted(() => {
+ initZoom();
+ });
+ watch(
+ () => route.path,
+ () => nextTick(() => initZoom())
+ );
+ },
}
diff --git a/docs/.vitepress/theme/styles/print.scss b/docs/.vitepress/theme/index.scss
similarity index 65%
rename from docs/.vitepress/theme/styles/print.scss
rename to docs/.vitepress/theme/index.scss
index f0ad0c6..0238aac 100644
--- a/docs/.vitepress/theme/styles/print.scss
+++ b/docs/.vitepress/theme/index.scss
@@ -10,3 +10,11 @@
page-break-inside: avoid;
}
}
+
+.medium-zoom-overlay {
+ z-index: 30;
+}
+
+.medium-zoom-image {
+ z-index: 31;
+}
diff --git a/docs/.vitepress/theme/styles/custom.scss b/docs/.vitepress/theme/styles/custom.scss
deleted file mode 100644
index 5dfce7d..0000000
--- a/docs/.vitepress/theme/styles/custom.scss
+++ /dev/null
@@ -1 +0,0 @@
-/* .vitepress/theme/custom.css */
diff --git a/docs/consultas.md b/docs/consultas.md
index 712d81a..1d8294e 100644
--- a/docs/consultas.md
+++ b/docs/consultas.md
@@ -137,9 +137,17 @@ de soporte en [Discord](https://faq.utnso.com.ar/discord-invite).
::: tip
-Este video les puede ayudar a reportar mejor los errores que encuentren:
+Si necesitan compartirnos un error de compilación desde Visual Studio Code, nos
+servirá de gran ayuda contar con la salida del compilador. Para obtenerla,
+podemos navegar a la pestaña de _Terminal_ y **copiar el texto** que aparece al
+ejecutar la tarea de compilación:
-
+
+
+Un texto de error es mucho más útil que una captura de pantalla, ya que nos
+permite copiarlo e investigarlo sin tener que transcribirlo manualmente. Además,
+si alguien más tiene el mismo problema, va a poder encontrar la solución
+utilizando el buscador del foro.
:::
diff --git a/docs/guias/consola/rutas.md b/docs/guias/consola/rutas.md
index ab6221b..856e659 100644
--- a/docs/guias/consola/rutas.md
+++ b/docs/guias/consola/rutas.md
@@ -70,48 +70,75 @@ directorio actual de nuestro proceso. Este no necesariamente es el mismo
directorio desde el que ejecutamos el proceso (porque pudo haber hecho un
`chdir()`), pero por lo general sí lo va a ser.
-## Eclipse
+## Visual Studio Code
-Pero más de una vez nos pasa que, trabajando con Eclipse, los path relativos se
-resuelven bien ejecutando nuestro proceso desde Eclipse, pero falla cuando lo
-ejecutamos desde la consola.
+Pero más de una vez nos pasa que, trabajando con Visual Studio Code, los path
+relativos se resuelven bien ejecutando nuestro proceso desde el editor, pero
+falla cuando lo ejecutamos desde la consola.
El problema, acá, es el CWD en cada caso.
Cuando vamos a ejecutar desde la consola, por lo general vamos al directorio
-`Debug/` que contiene nuestro ejecutable, y le damos `./miEjecutable` para
-correrlo. En ese caso, el CWD es nuestro directorio Debug/, y todas las rutas
+`bin` que contiene nuestro ejecutable, y le damos `./miEjecutable` para
+correrlo. En ese caso, el CWD es nuestro directorio `bin`, y todas las rutas
relativas se resuelven a partir de allí.
-Pero eclipse no hace eso, o al menos no por defecto. Si vamos a las Run
-Configurations de eclipse (`Run` > `Run configurations...`) y seleccionamos la
-de algún proyecto que ya hayamos ejecutado, vamos a encontrar que la pestaña de
-"Arguments" es algo así:
-
-
-
-¡Ahí está! Abajo de todo dice que el working directory de nuestro proceso va a
-ser `${workspace_loc:NUESTRO_PROYECTO}`, que es la forma horrenda que tiene
-eclipse para decir "el directorio raíz del proyecto". De hecho, si miramos la
-pestaña "Main" de las `Run Configurations`, podemos observar algo raro arriba de
-todo:
+Pero la configuración de Visual Studio Code provista por la cátedra,
+por defecto, utiliza otra ruta para ejecutar el programa. Si nos fijamos en la
+carpeta `.vscode` de nuestro proyecto, vamos a encontrar un archivo llamado
+`launch.json`. Una vez lo abramos, veremos algo así:
+
+```json
+{
+ // See https://go.microsoft.com/fwlink/?linkid=830387
+ // for the documentation about the launch.json format
+ "version": "0.2.0",
+ "configurations": [
+ {
+ "name": "run",
+ "type": "cppdbg",
+ "request": "launch",
+ "program": "${workspaceFolder}/bin/${workspaceFolderBasename}", // [!code focus]
+ "args": [],
+ "stopAtEntry": false,
+ "cwd": "${workspaceFolder}", // [!code focus]
+ "environment": [],
+ "externalConsole": false,
+ "MIMode": "gdb",
+ "setupCommands": [
+ {
+ "description": "Enable pretty-printing for gdb",
+ "text": "-enable-pretty-printing",
+ "ignoreFailures": true
+ }
+ ],
+ "preLaunchTask": "build"
+ }
+ ]
+}
+```
-
+¡Ahí está! El campo `cwd` es la carpeta desde la cual Visual Studio Code va a
+"hacerle `cd`". En este caso, siempre va a ser la carpeta en donde se encuentra
+nuestro proyecto.
-Nuestra aplicación no es coercion (el nombre del proyecto al que le saqué la
-captura), si no Debug/coercion. Ese es el comando que eclipse "va a ejecutar en
-la consola". Digamos, eclipse va a hacer una especie de `cd` al directorio que
-marca como "Working directory", y desde ahí va a ejecutar lo que diga en el
-campo `C/C++ Application`:
+Entonces, si nosotros queremos ejecutar nuestro programa desde la consola de la
+misma forma que lo hace Visual Studio Code, vamos a tener que hacerlo de la
+siguiente manera:
```bash
-cd coercion
-./Debug/coercion
+cd mi-proyecto
+./bin/mi-proyecto
```
-Entonces, como nosotros desde la consola solemos entrar a Debug en lugar de
-ejecutar desde el directorio raíz del proyecto, ahí es donde aparecen las
-diferencias con las rutas relativas.
+::: tip
+
+En realidad, lo que hace Visual Studio Code es ejecutar el programa utilizando
+`gdb` para poder hacer debugging; y, como pueden ver en el campo `program`,
+utiliza una ruta absoluta para llegar al binario. Pero, a fines prácticos, el
+resultado es el mismo.
+
+:::
## Del otro lado del espejo
diff --git a/docs/guias/estructura/codigo-compartido.md b/docs/guias/estructura/codigo-compartido.md
new file mode 100644
index 0000000..4188a0e
--- /dev/null
+++ b/docs/guias/estructura/codigo-compartido.md
@@ -0,0 +1,206 @@
+# Código compartido entre módulos
+
+Cuando empecemos a desarrollar cada módulo, notaremos que hay algunas funciones
+que se repiten entre sí. El ejemplo más común son las definiciones del protocolo
+de comunicación (como iniciar un servidor, conectarse como cliente, serializar y
+deserializar mensajes, etc).
+
+Si queremos reutilizar este código en los distintos proyectos del TP, podemos
+crear una **static library**, que es un archivo comprimido en formato `.a` el
+cual contiene código compilado que puede ser incluido a un ejecutable en tiempo
+de **compilación**[^1].
+
+## Crear un proyecto tipo static library
+
+### Inicialización
+
+Al igual que con un proyecto común, vamos a crear una carpeta y posicionarnos en
+ella:
+
+```bash
+mkdir utils
+cd utils
+```
+
+Pero esta vez el template que descarguemos será diferente:
+
+```bash
+wget -qO- https://faq.utnso.com.ar/static-library.tar.gz | tar -xzvf - --strip-components 1
+```
+
+Si vemos el contenido de la carpeta, notaremos que es similar al de un proyecto
+común, pero difiere en que no tiene un archivo `main.c`:
+
+```bash
+.
+├── .gitignore
+├── makefile
+├── settings.mk
+├── src
+│ └── utils
+│ ├── hello.c
+│ └── hello.h
+└── .vscode
+ ├── c_cpp_properties.json
+ ├── launch.json
+ └── tasks.json
+```
+
+En su lugar, tenemos un par de archivos `hello.c` y `hello.h`, que nos servirán
+de ejemplo para ver cómo importar la static library en otro proyecto.
+
+### Agregar al workspace
+
+De la misma forma que hicimos con los módulos, vamos a agregar la carpeta de la
+static library al workspace de Visual Studio Code yendo a la pestaña de
+`File` > `Add Folder to Workspace...`:
+
+
+
+## Vincular la static library a un módulo
+
+Buenísimo, agregamos la carpeta, pero... ¿cómo hacemos que los demás módulos
+apunten a ella? Para esto, vamos a seguir un par de pasos:
+
+### Editar la configuración del proyecto
+
+En cada módulo vamos a encontrar un archivo `settings.mk`, el cual es como una
+especie de archivo de configuración del proyecto. En dicho archivo, vamos a
+editar las siguientes variables:
+
+```makefile
+# Libraries
+LIBS=commons pthread readline m // [!code --]
+LIBS=utils commons pthread readline m // [!code ++]
+
+# Custom libraries' paths
+STATIC_LIBPATHS= // [!code --]
+STATIC_LIBPATHS=../utils // [!code ++]
+```
+
+::: tip
+
+- La variable `LIBS` es una lista de bibliotecas que el proyecto necesita para
+ compilar. El archivo `makefile` del proyecto se encarga de leer dicha lista y
+ agregar las bibliotecas correspondientes al comando de compilación mediante el
+ flag `-l`.
+
+```bash
+gcc -lcommons -lpthread -lreadline -lm <...>
+```
+
+- Por otro lado, `STATIC_LIBPATHS` es una lista de rutas a directorios que
+ contienen bibliotecas estáticas. El archivo `makefile` del proyecto se encarga
+ de leer dicha lista y agregar las rutas correspondientes al comando de
+ compilación mediante el flag `-L`, asumiendo que las bibliotecas se encuentran
+ en la carpeta `bin` de dichos proyectos.
+
+ ```bash
+ gcc -L../utils/bin <...>
+ ```
+
+- Además, asumimos que vamos a querer importar el código de la static library
+ que se encuentra en la carpeta `src` de la misma, por lo que también incluimos
+ el flag `-I` para que el compilador busque los archivos `.h` en dicha carpeta.
+
+ ```bash
+ gcc -I../utils/src <...>
+ ```
+
+:::
+
+### Editar la configuración de Visual Studio Code
+
+Finalmente, vamos a editar el archivo `c_cpp_properties.json` que se encuentra
+en la carpeta `.vscode` de **cada módulo** para que el editor reconozca los
+archivos `.h` de la static library:
+
+::: code-group
+
+```json [c_cpp_properties.json]
+{
+ "configurations": [
+ {
+ "name": "Linux",
+ "includePath": [
+ "${workspaceFolder}/../utils/src", // [!code ++]
+ "${workspaceFolder}/src"
+ ],
+ "defines": [],
+ "compilerPath": "/usr/bin/gcc",
+ "cStandard": "gnu17",
+ "cppStandard": "gnu++17",
+ "intelliSenseMode": "linux-gcc-x64"
+ }
+ ],
+ "version": 4
+}
+```
+
+:::
+
+
+## Incluir en el código
+
+Finalmente, para incluir el código de la static library en el módulo,
+simplemente vamos a referenciar los archivos `.h` partiendo desde la carpeta
+`src` de la static library. Por ejemplo:
+
+
+::: code-group
+
+```c:line-numbers [main.c]
+#include // [!code ++]
+
+int main(void) {
+ hello_world(); // [!code ++]
+ return 0;
+}
+```
+:::
+
+
+::: tip TIP
+
+El template permite agrupar el código en varias carpetas:
+
+```
+utils
+ └── src
+ ├── dto
+ │ ├── handshake.c
+ │ └── handshake.h
+ ├── sockets
+ │ ├── cliente.c
+ │ ├── cliente.h
+ │ ├── servidor.c
+ │ └── servidor.h
+ └── utils
+ ├── string.c
+ └── string.h
+```
+Para luego incluirlos de esta forma:
+
+```c
+#include
+#include
+#include
+#include
+#include
+```
+
+Esto está bueno por si queremos usar el mismo nombre de archivo en distintos
+lugares sin que haya **colisiones de nombres**.
+
+:::
+
+## Conclusión
+
+Con estos pasos, ya deberíamos tener un proyecto de tipo static library que
+podemos importar en otros módulos. Esto nos va a permitir reutilizar código
+entre los distintos proyectos del TP.
+
+
+
+[^1]: Esto es diferente a una **shared library**, cuyo código puede ser enlaza
+ recién en tiempo de **ejecución**.
diff --git a/docs/guias/estructura/crear-modulos.md b/docs/guias/estructura/crear-modulos.md
new file mode 100644
index 0000000..ab47941
--- /dev/null
+++ b/docs/guias/estructura/crear-modulos.md
@@ -0,0 +1,125 @@
+# Crear e importar varios módulos
+
+En esta guía vamos a aprender a configurar nuestro propio _workspace_ en Visual
+Studio Code para poder trabajar cómodamente en todos los módulos del Trabajo
+Práctico de forma simultánea.
+
+## Crear todos los módulos
+
+Para empezar, debemos clonarnos el repositorio del Trabajo Práctico provisto en
+la [organización de la cátedra](https://faq.utnso.com.ar/github) utilizando el
+comando `git clone`.
+
+Dentro de la carpeta del repositorio, vamos a ir creando un proyecto C para cada
+módulo del Trabajo Práctico de la misma forma que lo hicimos en la
+[guía de primeros pasos](/primeros-pasos/primer-proyecto-c):
+
+```bash
+mkdir kernel
+cd kernel
+wget -qO- https://faq.utnso.com.ar/project.tar.gz | tar -xzvf - --strip-components 1
+cd ..
+# y así sucesivamente para cada módulo
+```
+::: tip
+
+`cd ..` nos permite volver a la carpeta del repositorio para poder crear el
+siguiente módulo. Si quieren aprender a familiarizarse más con la consola, les
+recomendamos seguir el tutorial interactivo
+[Mario Bash](https://faq.utnso.com.ar/mariobash).
+
+:::
+
+## Crear el workspace
+
+El siguiente paso será abrir Visual Studio Code, y **desde una ventana vacía**
+nos iremos a la pestaña de `File` > `Add Folder to Workspace...`:
+
+
+
+Luego se nos desplegará un menú para seleccionar las carpetas que queremos
+agregar al workspace. Vamos a ir una por una seleccionando cada carpeta de cada
+módulo que creamos.
+
+Una vez hecho esto, deberíamos poder irnos a la pestaña de `Run and Debug` y
+seleccionar cualquier módulo para compilar y ejecutar, de la misma forma que
+hicimos en el [TP0](/primeros-pasos/tp0):
+
+
+
+> En lugar de `run (client)` y `run (server)`, vamos a tener `run (kernel)`,
+> `run (memoria)`, `run (filesystem)`, etc...
+
+## Guardar el workspace
+
+Finalmente, para no tener que hacer esto cada vez que abramos Visual Studio
+Code, vamos a guardar el workspace. Para eso, nos vamos a la pestaña de
+`File` > `Save Workspace As...` y guardamos el archivo con el nombre que
+queramos, por ejemplo, `tp.code-workspace`.
+
+### Antes de terminar...
+
+Para que el workspace funcione correctamente, les recomendamos agregar la
+siguiente configuración al archivo `tp.code-workspace` que creamos:
+
+::: code-group
+
+```json:line-numbers [tp.code-workspace]
+{
+ "settings": { // [!code ++]
+ "debug.onTaskErrors": "abort", // [!code ++]
+ "files.associations": { // [!code ++]
+ "*.h": "c", // [!code ++]
+ }, // [!code ++]
+ "C_Cpp.errorSquiggles": "disabled", // [!code ++]
+ }, // [!code ++]
+ "folders": [
+ {
+ "name": "kernel",
+ "path": "kernel"
+ },
+ // ... y el resto de módulos
+ ]
+}
+```
+
+::: tip
+
+- `debug.onTaskErrors` nos permite definir la acción a realizar en caso de que
+ alguna tarea previa a ejecutar el debugger falle (en nuestro caso,
+ compilarlo). Recomendamos abortar la ejecución ya que no queremos estar
+ debuggeando sobre una versión desactualizada del proyecto si éste no compila.
+
+- `files.associations` nos sirve para que el editor reconozca todos los
+ archivos `*.h` como código C (y no código C++, que es el valor por defecto).
+ De no hacer esto, el editor lo va a hacer individualmente por cada archivo
+ `*.h` que abramos, lo cual puede ser bastante molesto.
+
+- `C_Cpp.errorSquiggles` nos permite deshabilitar algunos mensajes de error que
+ nos pueden llegar a aparecer por utilizar algunas features de `gcc` que
+ pueden usar pero no forman parte del estándar de C[^1], como por ejemplo las
+ [nested functions](https://www.youtube.com/watch?v=1kYyxZXGjp0). Además,
+ esto permite que el editor tome en cuenta solo los errores al compilar, que
+ son los verdaderamente importantes.
+
+:::
+
+¡Y listo! Una vez hecho esto, podemos commitear el archivo `tp.code-workspace`
+para que nuestros compañeros de grupo puedan importar el workspace directamente.
+
+## Próximos pasos
+
+¡Buenísimo! Ya configuramos los módulos, pero ¿qué pasa si quiero hacer código
+compartido entre los mismos? ¿Debo copiar y pegar el código en cada módulo?
+
+Bueno, no necesariamente. En la [siguiente guía] vamos a crear e incluir una
+biblioteca estática para poder compartir código entre módulos.
+
+[siguiente guía]: /guias/estructura/codigo-compartido
+
+
+
+
+[^1]: Existe una feature request al respecto en el repo de Visual Studio Code,
+ les invitamos a dar su +1 para que se pueda incorporar esta feature en un
+ futuro: [microsoft/vscode-cpptools#1035](https://github.com/microsoft/vscode-cpptools/issues/1035)
diff --git a/docs/guias/herramientas/deploy.md b/docs/guias/herramientas/deploy.md
index 2cf5428..072b69a 100644
--- a/docs/guias/herramientas/deploy.md
+++ b/docs/guias/herramientas/deploy.md
@@ -23,7 +23,7 @@ para entregar.
Para empezar, recomendamos ampliamente haber generado un
[Personal Access Token de GitHub](https://docs.github.com/es/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)
-que **expire al día siguiente**[^2] y tenerlo a mano antes de entrar al
+que **expire al día siguiente**[^1] y tenerlo a mano antes de entrar al
laboratorio para poder clonar el repositorio del TP. Sí, tarda 5 minutos en
crearse, pero si multiplicamos ese tiempo por los 80 grupos por entrega se va a
notar de cuánto tiempo ahorrado para todos estamos hablando.
@@ -121,7 +121,7 @@ laboratorio), la forma más sencilla de hacerlo es utilizando
::: warning IMPORTANTE
**El puerto 22 es un puerto reservado exclusivamente para conexiones por SSH.**
-Deben usarlo solamente para conectarse por SSH con PuTTY.
+Deben usarlo solamente para conectarse por SSH con PuTTY.
Para conectar los módulos del TP entre sí es recomendable usar números de puerto
por encima de 1024, ya que es poco probable que estén siendo usados por otro
@@ -134,12 +134,9 @@ proceso (ej: 8000, 8001, etc).
A partir de acá, lo que queda es usar la consola para clonar, compilar,
configurar y levantar sus módulos. Algunas cosas a recordar en esta parte:
-1. Clonar el repo
-2. Instalar las bibliotecas necesarias (incluyendo las
- [commons](https://faq.utnso.com.ar/commons#guía-de-instalación))
- [^3].
-3. Compilar los módulos (recuerden que para poder compilar tienen que subir los
- makefiles[^4] ya que no está permitido subir archivos binarios al repo).
+1. Clonar el [script de despliegue](https://faq.utnso.com.ar/deploy)
+2. Ejecutarlo como se lo indicamos en el README del grupo
+3. Ingresar el Personal Access Token de GitHub cuando se lo pida
4. Llenar archivos de config con la IP y el Puerto de cada módulo.
Una vez tengan todo listo, avísennos y comenzamos.
@@ -222,10 +219,10 @@ entregas:
| :-----------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| En local mis módulos se conectan, pero en las VMs de prueba no. | Tener parametrizado estáticamente en el código (también conocido como _hardcodeado_) `"localhost"` a la hora de conectar módulos. | Sacar el `"localhost"` y configurar [getaddrinfo]() con los flags correctos. |
| Local funciona bien, pero en la entrega tengo comportamientos no determinísticos. | Local hay un solo CPU para todas las vms, pero en la entrega hay varios porque son varias máquinas. Ese paralelismo puede hacer que sus condiciones de carrera brillen más que con un solo CPU. | Probarlo distribuido con [Helgrind](/guias/herramientas/valgrind) (pueden levantar dos VMs server en sus máquinas si no pueden ir a Medrano) y usar semáforos. |
-| Cuando bajo mi módulo servidor tengo que esperar 30 segundos porque sino no se me conectan los módulos. | Es una medida de seguridad de Linux para que no puedan robar paquetes enviados a tu servidor.[^5] | Configurar [setsockopt](https://stackoverflow.com/a/24194999) para marcar a la IP y el puerto como reusables (ignorando el riesgo de seguridad que puede implicar), **o** ir tanteando con [lsof](/guias/consola/bash.html#lsof) para saber si el puerto ya fue liberado sin tener que volver a levantar el módulo. |
+| Cuando bajo mi módulo servidor tengo que esperar 30 segundos porque sino no se me conectan los módulos. | Es una medida de seguridad de Linux para que no puedan robar paquetes enviados a tu servidor.[^2] | Configurar [setsockopt](https://stackoverflow.com/a/24194999) para marcar a la IP y el puerto como reusables (ignorando el riesgo de seguridad que puede implicar), **o** ir tanteando con [lsof](/guias/consola/bash.html#lsof) para saber si el puerto ya fue liberado sin tener que volver a levantar el módulo. |
| No puedo compilar mis módulos y no sé qué hacer. | Falta subir los makefiles del proyecto al repositorio o instalar la shared library. | Revisar el [paso 2](#pasos-a-seguir) de esta guía. |
| No tengo información suficiente para darme cuenta si la prueba anduvo o no. | No puse logs suficientes en mi TP porque creí que no era necesario. | **Agregarlos**. Sin logs no tenemos manera de saber que las cosas que tenían que pasar en la prueba pasaron. La foto final no garantiza que el trayecto haya sido el correcto. |
-| Tardo demasiado en darme cuenta si la prueba anduvo o no porque está llena de logs irrelevantes. Tengo que comentarlos uno por uno y después acordarme de descomentarlos para seguir debuggeando. | Demasiado [printf debugging](https://stackoverflow.com/a/189570) | Aprovechar que las commons proveen varios [niveles de logueo](https://faq.utnso.com.ar/commons/blob/1136796838552318f475352a5983d926d16cc967/src/commons/log.h#L50-L52) para mostrar solo la información relevante y ocultar los logs "de debug" al correr la prueba[^6]. |
+| Tardo demasiado en darme cuenta si la prueba anduvo o no porque está llena de logs irrelevantes. Tengo que comentarlos uno por uno y después acordarme de descomentarlos para seguir debuggeando. | Demasiado [printf debugging](https://stackoverflow.com/a/189570) | Aprovechar que las commons proveen varios [niveles de logueo](https://faq.utnso.com.ar/commons/blob/1136796838552318f475352a5983d926d16cc967/src/commons/log.h#L50-L52) para mostrar solo la información relevante y ocultar los logs "de debug" al correr la prueba[^3]. |
## Paso 4: Des-pliegue - Recomendado
@@ -243,26 +240,14 @@ del cuatri y qué relaciones encontraron con la teoría.
-[^2]:
+[^1]:
Tener una fecha de expiración corta para nuestros tokens siempre es una
buena práctica de seguridad.
-[^3]:
- Si cuentan con una shared library propia, deberán copiar los headers (".h")
- en `/usr/include` y la biblioteca compilada (".so") en `/usr/lib`. Las
- commons se instalan
- [de la misma forma](https://github.com/sisoputnfrba/so-commons-library/blob/1136796838552318f475352a5983d926d16cc967/src/makefile#L33-L34)
- ;)
-
-[^4]:
- En Eclipse, los makefiles son varios archivos que se encuentran en la
- subcarpeta `Debug/` y se llaman `makefile` o tienen la extensión ".mk". Para
- poder compilar es necesario subirlos **todos**.
-
-[^5]:
+[^2]:
Más info en [este issue](https://github.com/sisoputnfrba/foro/issues/1624#issuecomment-611745367)
-[^6]:
+[^3]:
Incluso pueden agregar el nivel de logueo como una variable del config y
parsearlo con
[log_level_from_string](https://github.com/sisoputnfrba/so-commons-library/blob/b7a25d7924a6abba83a8bb48904a539b99f9fa27/src/commons/log.h#L115-L119)
diff --git a/docs/guias/index.md b/docs/guias/index.md
index 0a194df..e42541c 100644
--- a/docs/guias/index.md
+++ b/docs/guias/index.md
@@ -12,7 +12,7 @@ página.
:::
-
+
{{ group.text }}
diff --git a/docs/guias/programacion/main.md b/docs/guias/programacion/main.md
index b87271d..53796f2 100644
--- a/docs/guias/programacion/main.md
+++ b/docs/guias/programacion/main.md
@@ -10,7 +10,7 @@ comandos de una terminal.
Por ejemplo, si tomamos el cliente del TP0:
```bash
-./Debug/client
+./bin/client
```
Sin embargo, uno a veces necesita parametrizar algunos valores para que difieran
@@ -35,20 +35,20 @@ Entonces, si modificamos al cliente del TP0 para que tome una ruta por `main()`
podemos hacerlo de la siguiente manera:
```c
-int main(int argc, char** argv) {
+int main(int argc, char** argv) { // [!code focus]
//resto del TP0 de antes
- t_config* config = crear_config(argv[1]);
+ t_config* config = crear_config(argv[1]); // [!code focus]
//resto del TP0 de después
-}
+} // [!code focus]
```
Y lo ejecutamos como:
```bash
-./Debug/cliente ./una/ruta/a/mi/archivo.cfg
+./bin/client ./una/ruta/a/mi/archivo.cfg
```
- `argc` es la cantidad de argumentos que se agregan por línea de comando
@@ -59,67 +59,81 @@ Y lo ejecutamos como:
El motivo por el que el segundo elemento del array es la ruta que ingresamos es
porque el primer elemento es siempre el comando en sí mismo (en este caso,
-`./Debug/cliente`).
+`./bin/cliente`).
Esto incluso lo podemos mejorar controlando que la cantidad de parámetros sea la
indicada manejando `argc`:
-```c{2-4}
+```c{2-5}
int main(int argc, char** argv) {
- if (argc < 2) {
- return EXIT_FAILURE;
- }
+ if (argc < 2) { // [!code focus]
+ fprintf(stderr, "Uso: %s \n", argv[0]); // [!code focus]
+ return EXIT_FAILURE; // [!code focus]
+ } // [!code focus]
//resto del TP0 de antes
- t_config* config = crear_config(argv[1]);
+ t_config* config = crear_config(argv[1]); // [!code focus]
//resto del TP0 de después
}
```
-¡Eso es todo! Bueno, casi todo... ¿Cómo podemos lograr esto desde el IDE?
+¡Eso es todo! Bueno, casi todo... ¿Cómo podemos lograr esto desde el editor?
:thinking:
-## Pasar argumentos desde Eclipse
-
-Vamos a entrar a las `Run Configurations...`:
-
-
-
-Y en la configuración del proyecto nos moveremos a la pestaña `Arguments`, en
-donde vamos a poner nuestros argumentos separados por espacios:
-
-
-
-En caso de usar una [ruta relativa](/guias/consola/rutas), es muy importante
-partir desde el `Working directory` que está configurado ahí más abajo.
-
-Por ejemplo, la variable `${workspace_loc:NOMBRE_DEL_PROYECTO}` apunta hacia la
-carpeta en donde se encuentra el proyecto Eclipse.
-
-## Pasar argumentos desde Visual Studio Code
+## Visual Studio Code
En el caso de que ya tengamos configurado el debugger, podremos encontrar en
nuestro archivo `launch.json` una variable `args`, en donde vamos a
poner nuestra lista de argumentos en formato de array de strings.
-```json{5}
+```json
{
- "configurations": [
+ // See https://go.microsoft.com/fwlink/?linkid=830387
+ // for the documentation about the launch.json format
+ "version": "0.2.0",
+ "configurations": [ // [!code focus]
+ {
+ "name": "run",
+ "type": "cppdbg",
+ "request": "launch",
+ "program": "${workspaceFolder}/bin/${workspaceFolderBasename}",
+ "args": [ "./una/ruta/a/mi/archivo.cfg" ], // [!code focus]
+ "stopAtEntry": false,
+ "cwd": "${workspaceFolder}", // [!code focus]
+ "environment": [],
+ "externalConsole": false,
+ "MIMode": "gdb",
+ "setupCommands": [
{
- // ...
- "args": [ "./una/ruta/a/mi/archivo.cfg" ],
- "cwd": "${workspaceFolder}",
- // ...
+ "description": "Enable pretty-printing for gdb",
+ "text": "-enable-pretty-printing",
+ "ignoreFailures": true
}
- ]
+ ],
+ "preLaunchTask": "build"
+ }
+ ] // [!code focus]
}
```
-En caso de usar una [ruta relativa](/guias/consola/rutas), es muy importante
+En caso de usar una ruta relativa[^1], es muy importante
asegurarnos que la variable `cwd` apunte al valor correcto. En este ejemplo,
-`${workspaceFolder}` es otra variable que apunta hacia la carpeta que tiene
-abierta Visual Studio Code[^1].
+`${workspaceFolder}` es otra variable que apunta hacia la ruta absoluta del
+directorio abierto por Visual Studio Code[^2].
+
+::: tip
+
+Si queremos pasar más de un argumento, simplemente agregamos más elementos al
+array separados por comas:
+
+```json
+"args": [ "arg1", "arg2", "arg3" ],
+```
+
+:::
+
+[^1]: [Guía de Rutas relativas y absolutas](/guias/consola/rutas)
-[^1]: [Visual Studio Code Variables Reference](https://code.visualstudio.com/docs/editor/variables-reference)
+[^2]: [Documentación de las variables de Visual Studio Code (en inglés)](https://code.visualstudio.com/docs/editor/variables-reference)
diff --git a/docs/guias/programacion/shared-libraries.md b/docs/guias/programacion/shared-libraries.md
deleted file mode 100644
index daf2dca..0000000
--- a/docs/guias/programacion/shared-libraries.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Shared Libraries
-
-Un video cortito sobre como crear una biblioteca compartida (Shared Library) con
-Eclipse IDE para C, integrarla en un proyecto en C sobre Eclipse IDE. Viene con
-un par de aclaraciones de cómo Eclipse traspasa esas configs al compilador GCC
-para entender un poco más los mensajes de error.
-
-
-
-**¿Qué comando usamos para ejecutar el proyecto en la consola?**
-
-```bash
-LD_LIBRARY_PATH=/home/utnso/eclipse-workspace/pepes-threads/Debug ./pepes-main/pepes-main
-```
-
-Es importante que la variable es solo para el programa que estamos ejecutando,
-pero hay formas de que quede seteada en la consola mientras está encendida, o
-incluso, aunque la VM se apague!
-
-Si querés saber más sobre las variables de entorno, pegale una leída a la última
-sección de nuestra
-[guía de uso de Bash](/guias/consola/bash#variables-de-entorno).
diff --git a/docs/primeros-pasos/entorno-desarrollo.md b/docs/primeros-pasos/entorno-desarrollo.md
deleted file mode 100644
index 8404e90..0000000
--- a/docs/primeros-pasos/entorno-desarrollo.md
+++ /dev/null
@@ -1,99 +0,0 @@
-# Crear tu primer proyecto C
-
-Una vez [instaladas las VMs](/primeros-pasos/entorno-linux) (o el entorno Linux que hayas
-elegido), debemos continuar con un par de configuraciones antes de arrancar a
-desarrollar.
-
-## Descargar las Commons
-
-Para facilitar el desarrollo del TP, desde la cátedra proveemos una biblioteca
-con TADs de uso común (por ejemplo, colecciones vistas en Algoritmos como listas
-y queues), funciones para simplificar el manejo de strings y fechas, entre
-otras: las Commons.
-
-Para descargarla, vamos a abrir una consola y nos vamos a clonar
-[el repo](https://faq.utnso.com.ar/commons) para instalarlas
-en modo debug[^1]:
-
-```bash
-git clone https://github.com/sisoputnfrba/so-commons-library
-cd so-commons-library
-make debug
-make install
-```
-
-::: tip
-
-En los
-[archivos `*.h` del repo](https://faq.utnso.com.ar/commons-src)
-vas a encontrar todas las funciones que pueden usar junto con una breve
-descripción.
-
-:::
-
-## Crear un proyecto en Eclipse
-
-Ahora sí, una vez instaladas las commons, vamos a probar de incluirlas en
-nuestro primer proyecto en **Eclipse**.
-
-
-
-¿Por qué Eclipse? Con una configuración mínima, incluye por defecto una gran
-cantidad de features para ayudarnos a desarrollar el TP como, por ejemplo,
-Makefiles para compilar el código sin tener que usar `gcc` directamente desde la
-consola, un [debugger integrado](/guias/herramientas/debugger),
-[ejecución con Valgrind](/guias/herramientas/valgrind)...
-
-Además, los ayudantes ya estamos familiarizados con su uso, por lo que ante
-cualquier [duda o consulta](/consultas) vamos a saber por dónde orientarlos.
-
-::: tip
-
-En la sección de "herramientas" de las guías podrás encontrar más contenido para
-conocer las features más útiles de Eclipse.
-
-:::
-
-## Configurar Git
-
-Por último, antes de empezar a subir nuestro código en GitHub, vamos a
-configurar nuestro usuario de Git para que al hacer `git commit` quede
-registrado nuestro nombre y email:
-
-```bash
-git config --global user.email "tumail@tucasilla.com"
-git config --global user.name "Tu Nombre"
-```
-
-::: warning IMPORTANTE
-
-El email configurado debe ser uno de los mails verificados en tu
-[cuenta de GitHub](https://github.com/settings/emails).
-
-:::
-
-También podemos configurar el gestor de credenciales para que almacene
-nuestro [token](https://github.com/settings/tokens) la próxima vez que lo
-ingresemos al hacer `git pull` o `git push`:
-
-```bash
-git config --global credential.helper store
-```
-
-De esta forma, una vez lo ingresemos por primera vez no será necesario volverlo
-a hacer cada vez que querramos interactuar con el repo del Trabajo Práctico.
-
-
-## Próximos pasos
-
-- Para ir entrando más de lleno en el Lenguaje C, recomendamos arrancar a
- chusmear nuestra sección de guías de programación en C.
-- También este [tutorial interactivo de C](https://www.learn-c.org/) (en inglés)
- puede ser de utilidad.
-- Si te sentís con confianza, arranquemos con el [TP0](/primeros-pasos/tp0).
-
-
-
-[^1]:
- ¿Por qué en modo debug? Es una herramienta que nos ayudará
- [más adelante](/guias/herramientas/debugger) (?)
diff --git a/docs/primeros-pasos/entorno-linux.md b/docs/primeros-pasos/entorno-linux.md
index 160115f..101fc41 100644
--- a/docs/primeros-pasos/entorno-linux.md
+++ b/docs/primeros-pasos/entorno-linux.md
@@ -188,4 +188,7 @@ Para eso, te dejamos acá algunos links que te pueden ser útiles:
- [Micro-repaso de Arquitectura](https://faq.utnso.com.ar/guia-repaso-arquitectura)
- [Guía de uso de Bash](/guias/consola/bash)
-- [Git para el trabajo práctico](/guias/consola/git)
+
+También, más adelante, usaremos la terminal para interactuar con
+[Git](/primeros-pasos/git), una herramienta de versionado de código que nos va a
+permitir trabajar en equipo de forma más eficiente.
diff --git a/docs/guias/consola/git.md b/docs/primeros-pasos/git.md
similarity index 96%
rename from docs/guias/consola/git.md
rename to docs/primeros-pasos/git.md
index f54a52d..714d595 100644
--- a/docs/guias/consola/git.md
+++ b/docs/primeros-pasos/git.md
@@ -68,13 +68,20 @@ Si es la primera vez que usamos Git, va a ser necesario configurar nuestro
nombre y el email con el que estaremos trabajando utilizando:
```bash
-git config --global user.name "NOMBRE"
-git config --global user.email "EMAIL"
+git config --global user.email "tumail@tucasilla.com"
+git config --global user.name "Tu Nombre"
```
Si quisieras que la configuración de nombre y mail haga efecto únicamente sobre
el repositorio actual, podés omitir el flag `--global`.
+::: warning IMPORTANTE
+
+Para el TP, el email configurado debe ser uno de los mails verificados en tu
+[cuenta de GitHub](https://github.com/settings/emails).
+
+:::
+
### git clone
Nos permite "clonar" un repositorio remoto, lo que significa que nos deja
diff --git a/docs/primeros-pasos/primer-proyecto-c.md b/docs/primeros-pasos/primer-proyecto-c.md
new file mode 100644
index 0000000..c73cefe
--- /dev/null
+++ b/docs/primeros-pasos/primer-proyecto-c.md
@@ -0,0 +1,210 @@
+# Crear tu primer proyecto C
+
+Una vez [instaladas las VMs](/primeros-pasos/entorno-linux) (o el entorno Linux que hayas
+elegido), debemos continuar con un par de configuraciones antes de arrancar a
+desarrollar.
+
+## Descargar la so-commons-library
+
+Para facilitar el desarrollo del TP, desde la cátedra proveemos una biblioteca
+con [TADs] de uso común: la _commons library_. Esta biblioteca nos va a proveer
+colecciones vistas en AyED, como listas y queues, y funciones para simplificar
+el manejo de strings y fechas, entre otras.
+
+[TADs]: https://es.wikipedia.org/wiki/Tipo_de_dato_abstracto
+
+Para descargarla, vamos a abrir una consola y nos vamos a clonar
+[el repo](https://faq.utnso.com.ar/commons) para instalarlas
+en modo debug[^1]:
+
+```bash
+git clone https://github.com/sisoputnfrba/so-commons-library
+cd so-commons-library
+make debug
+make install
+```
+
+::: tip
+
+En los
+[archivos `*.h` del repo](https://faq.utnso.com.ar/commons-src)
+vas a encontrar todas las funciones que pueden usar junto con una breve
+descripción.
+
+:::
+
+## Descargar el template oficial
+
+Ahora sí, una vez instaladas las commons, vamos a probar de incluirlas en
+nuestro primer proyecto en **Visual Studio Code**.
+
+Para eso, abrimos una nueva consola y creamos un nuevo directorio para nuestro
+proyecto. Luego, nos vamos a mover a ese directorio y, una vez allí, vamos a
+descargar el template oficial:
+
+```bash
+mkdir ejemplo
+cd ejemplo
+wget -qO- https://faq.utnso.com.ar/project.tar.gz | tar -xzvf - --strip-components 1
+```
+
+::: tip
+
+También podés crear un nuevo proyecto desde GitHub incluyendo el template
+[c-base-project](https://faq.utnso.com.ar/project) a la hora de crear un
+nuevo repositorio:
+
+
+
+Y luego clonar el repositorio recién creado ejecutando `git clone`.
+
+:::
+
+Si ejecutamos `tree -a`, vamos a ver que se nos descargaron varios archivos:
+
+```txt
+.
+├── .gitignore
+├── makefile
+├── README.md
+├── settings.mk
+├── src
+│ └── main.c
+└── .vscode
+ ├── c_cpp_properties.json
+ ├── launch.json
+ ├── settings.json
+ └── tasks.json
+
+2 directories, 9 files
+```
+
+## Abrir el proyecto en Visual Studio Code
+
+Ahora, vamos a abrir el directorio que creamos en Visual Studio Code. Podemos
+hacerlo desde el editor moviéndonos a `File` > `Open Folder` o utilizando el
+comando:
+
+```bash
+code .
+```
+
+Veremos que se nos abre el editor con el proyecto que acabamos de descargar:
+
+
+
+## Cómo compilar
+
+El template ya cuenta con una tarea de compilación que podemos ejecutar desde
+el editor moviéndonos a la pestaña _Terminal_ y haciendo click en _Run Build
+Task_, o utilizando el shortcut `Ctrl+Shift+B`. Vamos a ver que se nos genera
+una carpeta `bin` con el binario del proyecto compilado:
+
+
+
+### Errores de compilación
+
+En caso de que la compilación falle, vamos a poder ver los errores y navegar
+entre ellos desde la pestaña de _Problems_:
+
+
+
+::: warning IMPORTANTE
+
+Recuerden ir recompilando el proyecto **activamente**, ya que es la única forma
+de recibir feedback inmediato del compilador y corregir los errores de sintaxis
+que puedan aparecer.
+
+Una vez corregidos los errores, debemos volver a compilar el proyecto para
+que el editor actualice la lista de errores y warnings.
+
+:::
+
+Existen distintos tipos de errores:
+
+:x: Los que aparecen en **rojo**. Éstos impiden que el proyecto se compile, por
+ejemplo, errores de sintaxis o referencias a variables que no existen.
+
+:warning: Los que aparecen en **amarillo**. Éstos no impiden que el proyecto se
+compile, pero es **altamente recomendable** corregirlos, ya que muy
+probablemente signifiquen que algo no está funcionando como esperamos, por
+ejemplo, tener una variable no se esté utilizando.
+
+::: tip
+
+Si querés que el chequeo de tu código sea más estricto y evitar olvidarte de
+corregir los warnings, existe un flag de `gcc` que permite transformarlos en
+errores: `-Werror`
+
+Podemos agregarlo fácilmente al final de las variables `CDEBUG` y `CRELEASE` del
+archivo `settings.mk`:
+
+```makefile
+# Compiler flags
+CDEBUG=-g -Wall -DDEBUG -fdiagnostics-color=always // [!code --]
+CDEBUG=-g -Wall -DDEBUG -fdiagnostics-color=always -Werror // [!code ++]
+CRELEASE=-O3 -Wall -DNDEBUG -fcommon // [!code --]
+CRELEASE=-O3 -Wall -DNDEBUG -fcommon -Werror // [!code ++]
+```
+
+:::
+
+::: details Cómo reportar errores
+
+Si necesitan compartirnos un error de compilación desde Visual Studio Code, nos
+servirá de gran ayuda contar con la salida del compilador. Para obtenerla,
+podemos navegar a la pestaña de _Terminal_ y **copiar el texto** que aparece al
+ejecutar la tarea de compilación:
+
+
+
+Un texto de error es mucho más útil que una captura de pantalla, ya que nos
+permite copiarlo e investigarlo sin tener que transcribirlo manualmente. Además,
+si alguien más tiene el mismo problema, va a poder encontrar la solución
+utilizando el buscador del foro.
+
+:::
+
+## Cómo ejecutar
+
+Finalmente, para ejecutar el proyecto, nos moveremos a la pestaña
+de _Run and Debug_ y haremos a hacer click en el botón de _Run_:
+
+
+
+Si aparece un mensaje diciendo _Hola, Operativos!!_, ¡felicidades! Ya tenés tu
+primer proyecto en C funcionando.
+
+::: tip
+
+Al hacer click en el botón de _Run_, ocurren dos cosas:
+
+1. Se compila el proyecto ejecutando la build task que vimos en el paso
+ anterior.
+2. Se ejecuta el binario generado en la carpeta `bin` con el nombre del
+ proyecto.
+
+Los invitamos a abrir una consola y ejecutar el binario manualmente para
+corroborar que se ejecuta de la misma forma en que lo hace el editor:
+
+```bash
+make
+./bin/ejemplo
+```
+
+:::
+
+
+## Próximos pasos
+
+- En la siguiente sección vamos a ver cómo utilizar [Git](/primeros-pasos/git)
+ para el TP de Operativos.
+- Por otro lado, para ir entrando más de lleno en el Lenguaje C, podés empezar
+ con nuestra sección de
+ [guías de programación en C](/guias/#programación-en%20c).
+
+
+
+[^1]:
+ ¿Por qué en modo debug? Es una herramienta que nos ayudará
+ [más adelante](/guias/herramientas/debugger) (?)
diff --git a/docs/primeros-pasos/tp0.md b/docs/primeros-pasos/tp0.md
index cae4557..4a37399 100644
--- a/docs/primeros-pasos/tp0.md
+++ b/docs/primeros-pasos/tp0.md
@@ -1,6 +1,6 @@
# Trabajo Práctico 0
-> Versión 2.3.0
+> Versión 2.4.0
El TP0 es una práctica inicial para empezar a familiarizarse con algunas de las
herramientas necesarias para el trabajo práctico cuatrimestral como es la
@@ -35,13 +35,13 @@ otro concepto en los [medios de consulta de la práctica](/consultas).
## Requisitos
- [Contar con un entorno Linux](/primeros-pasos/entorno-linux)
-- [Tener configuradas las commons y git](/primeros-pasos/entorno-desarrollo)
+- [Tener configuradas las commons y git](/primeros-pasos/primer-proyecto-c)
+- Haber leído las guías de [sockets](/guias/linux/sockets) y
+ [serialización](/guias/linux/serializacion)
- Tener a mano el [repo del TP0](https://faq.utnso.com.ar/tp0)
## Etapa 1: Setup inicial
-### Crear un workspace
-
Primero, abramos una consola y, de la misma forma que bajamos el proyecto de las
commons, bajemos el del TP0:
@@ -50,34 +50,25 @@ git clone https://github.com/sisoputnfrba/tp0
cd tp0
```
-Luego, en el Eclipse vamos a movernos hacia
-`File > Switch Workspace > Other...`:
-
-
-
-Y vamos a seleccionar la carpeta donde clonamos el repositorio del TP0:
-
-
-
-### Agregar los proyectos al workspace
-
-Ahora, para agregar los proyectos al workspace, nos vamos a mover hacia
-`File > Open Projects From File System...`:
+Luego, abramos el proyecto desde Visual Studio Code utilizando el workspace ya
+configurado en el repo:
-
+```bash
+code tp0.code-workspace
+```
-Nos aparecerá el siguiente menú, sobre el cual...
+::: tip
-
+También podemos abrir el proyecto abriendo Visual Studio Code y seleccionando
+`File > Open Workspace from File...` y seleccionando el archivo
+`tp0.code-workspace` que se encuentra en la carpeta del TP0.
-1. Elegiremos de nuevo la carpeta del workspace desde el botón `Directory...`
-2. Dejaremos tildados solamente los proyectos `server` y `client`
-3. Haremos click en `Finish` para continuar
+:::
-A la izquierda, en la pestaña `Project Explorer`, nos van a aparecer ambos
-proyectos listos para arrancar con el TP0:
+Una vez abierto el workspace, vamos a ver que tenemos dos módulos: `client` y
+`server`, con su propio código fuente y configuraciones:
-
+
## Etapa 2: Comandos básicos
@@ -105,10 +96,10 @@ para que:
Creado nuestro logger, usemos `log_info()` para loggear el string `"Soy un Log"`
y cerremos el logger al final del programa con `log_destroy()`.
-Compilemos usando el :hammer: (o apretando `Ctrl` + `B`) y démosle Run al
-programa con :arrow_forward: (o `Ctrl` + `F11`).
+Compilemos y ejecutemos el programa moviéndonos a la sección "Run and Debug" en
+la barra lateral izquierda, seleccionando "run (client)":
-
+
### Archivos de configuración
@@ -124,8 +115,8 @@ obtengamos el valor de la key `CLAVE` en formato string.
::: tip
-Para saber dónde guardar el archivo config y cómo hace Eclipse para leerlo,
-podés consultar la [guía de paths](/guias/consola/rutas).
+Para saber dónde guardar el archivo config y cómo hace Visual Studio Code para
+leerlo, podés consultar la [guía de paths](/guias/consola/rutas).
:::
@@ -217,6 +208,9 @@ Si en alguna etapa del TP el programa no se comporta como esperaban, pueden
intentar ejecutarlo línea por línea siguiendo el
[tutorial de debugging en Eclipse](/guias/herramientas/debugger).
+Si bien estamos usando Visual Studio Code, el tutorial es aplicable a cualquier
+IDE que quieran utilizar.
+
:::
::: tip
@@ -310,6 +304,102 @@ hacerlo, pueden consultar nuestra
:::
+## Etapa 4: Desplegar en la Ubuntu Server
+
+Por último, vamos a practicar un poco lo que vamos a hacer al momento de la
+entrega del TP cuatrimestral: desplegar cada uno de los módulos en forma
+distribuida, cada una en su propia máquina virtual.
+
+Para ello, vamos a empezar por descargar la imagen de Ubuntu Server provista
+por la cátedra en la sección de
+[Máquinas Virtuales](/recursos/vms#ubuntu-server-64-bit).
+
+Estas VMs son las mismas que están instaladas en los laboratorios de la
+facultad, por lo que podemos estar seguros de que vamos a tener una experiencia
+similar a la entrega del TP.
+
+### Configuación de la red
+
+Una vez que tengamos la VM instalada, vamos a necesitar configurar la red para
+que pueda comunicarse con otras máquinas virtuales en nuestra red local.
+
+Para ello iremos a la configuración de la Ubuntu Server y en el apartado de
+"Network" (o "Red") elegiremos el "Bridged Adapter" (en español, "Adaptador
+Puente"):
+
+
+
+### Conexión por SSH
+
+Una vez que tengamos la red configurada, podríamos iniciar la VM y utilizar la
+consola que nos provee VirtualBox para trabajar en ella. Sin embargo, esto no es
+muy cómodo ya que no podemos copiar y pegar texto, ni tampoco abrir varias
+ventanas.
+
+Para solucionar esto, nos vamos a conectar a la VM por SSH. Para ello, ni bien
+iniciemos sesión veremos la IP que se le asignó a la VM:
+
+
+
+Vamos a usar esa IP, que siempre empieza con `192.168.0`, para conectarnos a la
+VM desde nuestra consola.
+
+Tanto en Windows como en Linux, podemos abrir una consola powershell o bash y
+usar el comando `ssh`:
+
+```sh
+ssh utnso@192.168.0.XXX
+# Reemplazar XXX por el número que vimos en la VM
+```
+
+Nos va a pedir la contraseña de la VM, que por defecto ya sabemos cuál es :wink:
+
+### Despliegue del repositorio
+
+Para desplegar el TP0 en la VM, vamos a repetir los mismos pasos que hicimos
+en la guía anterior y la etapa 1, pero sin interfaz gráfica. Es decir, vamos a:
+
+1. Instalar la [so-commons-library]
+2. Clonar el repo del TP0 (que en este caso va a ser un repo **privado suyo**).
+3. Movernos a la carpeta `client` y `server` y compilar el código fuente
+ ejecutando el comando `make`.
+
+[so-commons-library]: https://faq.utnso.com.ar/commons
+
+::: warning
+
+En este caso, como el repositorio es privado, vamos a necesitar configurar las
+credenciales de git para poder clonarlo. Recomendamos generar temporalmente un
+[Personal Access Token de GitHub] que podamos copiar y pegar en la consola para
+poder clonar el repo.
+
+:::
+
+[Personal Access Token de GitHub]: https://docs.github.com/es/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token
+
+
+### Clonar la VM
+
+Para simular que contamos con dos máquinas distintas, lo que haremos será clonar
+la VM que ya tenemos configurada. Para ello, vamos a hacer click derecho en la
+VM > "Clone..." y seguir los pasos para clonar la VM. Recomendamos usar la
+opción "Linked clone" ya que el proceso de clonado es más rápido y ocupa menos
+espacio:
+
+
+
+Una vez hecho esto, vamos a consultar la IP de la VM
+del `server` y agregarla al archivo de configuración del `client` para que se
+puedan comunicar.
+
+::: tip
+
+Las VMs están configuradas para ejecutar el comando
+[`ifconfig`](/guias/consola/bash.html#ifconfig) para que puedan ver la IP de la
+VM ni bien inicien sesión.
+
+:::
+
## Notas finales
El transcurso de esta guía de primeros pasos fue un poco largo, ¡pero
@@ -319,12 +409,13 @@ aprendimos un montón! Recapitulemos un poco:
- Aprendimos a usar funciones de las commons que nos van a ser muy útiles.
- Aprendimos sobre reservar memoria, liberarla y leer por consola.
- Pudimos mandar mensajes por red a otro programa.
+- Aprendimos cómo desplegar el TP en una VM sin interfaz gráfica.
Esto fue todo, pero recuerden que el TP0 es solo una introducción a todas las
herramientas que podemos usar.
Por lo tanto, les pedimos que consulten las guías y video tutoriales linkeados
-en la pestaña de "Guías" de la barra de navegación de esta página para mejorar
-constantemente y llegar bien holgados a fin de cuatrimestre.
+en la sección [Guías](/guias/) de esta página para mejorar constantemente y
+llegar bien holgados a fin de cuatrimestre.
**¡Hasta la próxima amigos!**
diff --git a/docs/public/img/guias/estructura/codigo-compartido/vscode-add-folder-to-workspace.png b/docs/public/img/guias/estructura/codigo-compartido/vscode-add-folder-to-workspace.png
new file mode 100644
index 0000000..71f78d8
Binary files /dev/null and b/docs/public/img/guias/estructura/codigo-compartido/vscode-add-folder-to-workspace.png differ
diff --git a/docs/public/img/guias/estructura/crear-modulos/github-clone.png b/docs/public/img/guias/estructura/crear-modulos/github-clone.png
new file mode 100644
index 0000000..0240557
Binary files /dev/null and b/docs/public/img/guias/estructura/crear-modulos/github-clone.png differ
diff --git a/docs/public/img/guias/estructura/crear-modulos/vscode-add-folder-to-workspace.gif b/docs/public/img/guias/estructura/crear-modulos/vscode-add-folder-to-workspace.gif
new file mode 100644
index 0000000..f428881
Binary files /dev/null and b/docs/public/img/guias/estructura/crear-modulos/vscode-add-folder-to-workspace.gif differ
diff --git a/docs/public/img/guias/estructura/crear-modulos/vscode-run-debug.gif b/docs/public/img/guias/estructura/crear-modulos/vscode-run-debug.gif
new file mode 100644
index 0000000..af2c1a7
Binary files /dev/null and b/docs/public/img/guias/estructura/crear-modulos/vscode-run-debug.gif differ
diff --git a/docs/public/img/primeros-pasos/primer-proyecto-c/github-create-repo-from-template.png b/docs/public/img/primeros-pasos/primer-proyecto-c/github-create-repo-from-template.png
new file mode 100644
index 0000000..5ab8196
Binary files /dev/null and b/docs/public/img/primeros-pasos/primer-proyecto-c/github-create-repo-from-template.png differ
diff --git a/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-copy-compiler-output.gif b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-copy-compiler-output.gif
new file mode 100644
index 0000000..a362b70
Binary files /dev/null and b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-copy-compiler-output.gif differ
diff --git a/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-open-project.gif b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-open-project.gif
new file mode 100644
index 0000000..da7d001
Binary files /dev/null and b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-open-project.gif differ
diff --git a/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-problems.gif b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-problems.gif
new file mode 100644
index 0000000..0f14545
Binary files /dev/null and b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-problems.gif differ
diff --git a/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-run-build-task.gif b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-run-build-task.gif
new file mode 100644
index 0000000..8917367
Binary files /dev/null and b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-run-build-task.gif differ
diff --git a/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-run-debug.gif b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-run-debug.gif
new file mode 100644
index 0000000..c487b93
Binary files /dev/null and b/docs/public/img/primeros-pasos/primer-proyecto-c/vscode-run-debug.gif differ
diff --git a/docs/public/img/primeros-pasos/tp0/vm-clone.png b/docs/public/img/primeros-pasos/tp0/vm-clone.png
new file mode 100644
index 0000000..b895389
Binary files /dev/null and b/docs/public/img/primeros-pasos/tp0/vm-clone.png differ
diff --git a/docs/public/img/primeros-pasos/tp0/vm-ip.png b/docs/public/img/primeros-pasos/tp0/vm-ip.png
new file mode 100644
index 0000000..0efe681
Binary files /dev/null and b/docs/public/img/primeros-pasos/tp0/vm-ip.png differ
diff --git a/docs/public/img/primeros-pasos/tp0/vm-network.png b/docs/public/img/primeros-pasos/tp0/vm-network.png
new file mode 100644
index 0000000..09e2434
Binary files /dev/null and b/docs/public/img/primeros-pasos/tp0/vm-network.png differ
diff --git a/docs/public/img/primeros-pasos/tp0/vscode-file-explorer.png b/docs/public/img/primeros-pasos/tp0/vscode-file-explorer.png
new file mode 100644
index 0000000..3e9b03e
Binary files /dev/null and b/docs/public/img/primeros-pasos/tp0/vscode-file-explorer.png differ
diff --git a/docs/public/img/primeros-pasos/tp0/vscode-run-debug.gif b/docs/public/img/primeros-pasos/tp0/vscode-run-debug.gif
new file mode 100644
index 0000000..af2c1a7
Binary files /dev/null and b/docs/public/img/primeros-pasos/tp0/vscode-run-debug.gif differ
diff --git a/docs/public/img/primeros-pasos/tp0/workspace-01.png b/docs/public/img/primeros-pasos/tp0/workspace-01.png
deleted file mode 100644
index 41f93e7..0000000
Binary files a/docs/public/img/primeros-pasos/tp0/workspace-01.png and /dev/null differ
diff --git a/docs/public/img/primeros-pasos/tp0/workspace-02.png b/docs/public/img/primeros-pasos/tp0/workspace-02.png
deleted file mode 100644
index be935ae..0000000
Binary files a/docs/public/img/primeros-pasos/tp0/workspace-02.png and /dev/null differ
diff --git a/docs/public/img/primeros-pasos/tp0/workspace-03.png b/docs/public/img/primeros-pasos/tp0/workspace-03.png
deleted file mode 100644
index e6b6cdd..0000000
Binary files a/docs/public/img/primeros-pasos/tp0/workspace-03.png and /dev/null differ
diff --git a/docs/public/img/primeros-pasos/tp0/workspace-04.png b/docs/public/img/primeros-pasos/tp0/workspace-04.png
deleted file mode 100644
index eaf2d3c..0000000
Binary files a/docs/public/img/primeros-pasos/tp0/workspace-04.png and /dev/null differ
diff --git a/docs/public/img/primeros-pasos/tp0/workspace-05.png b/docs/public/img/primeros-pasos/tp0/workspace-05.png
deleted file mode 100644
index 3e554f4..0000000
Binary files a/docs/public/img/primeros-pasos/tp0/workspace-05.png and /dev/null differ
diff --git a/docs/public/img/primeros-pasos/tp0/workspace-06.png b/docs/public/img/primeros-pasos/tp0/workspace-06.png
deleted file mode 100644
index 5bea59a..0000000
Binary files a/docs/public/img/primeros-pasos/tp0/workspace-06.png and /dev/null differ
diff --git a/package.json b/package.json
index f90250b..7a1b718 100644
--- a/package.json
+++ b/package.json
@@ -24,6 +24,7 @@
"@types/markdown-it-footnote": "^3.0.0",
"@types/node": "^18.11.18",
"markdown-it-footnote": "^3.0.3",
+ "medium-zoom": "^1.1.0",
"sass": "^1.55.0",
"vitepress": "^1.0.0-rc.41"
}
diff --git a/yarn.lock b/yarn.lock
index 9a76619..70b859d 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -725,6 +725,11 @@ markdown-it-footnote@^3.0.3:
resolved "https://registry.yarnpkg.com/markdown-it-footnote/-/markdown-it-footnote-3.0.3.tgz#e0e4c0d67390a4c5f0c75f73be605c7c190ca4d8"
integrity sha512-YZMSuCGVZAjzKMn+xqIco9d1cLGxbELHZ9do/TSYVzraooV8ypsppKNmUJ0fVH5ljkCInQAtFpm8Rb3eXSrt5w==
+medium-zoom@^1.1.0:
+ version "1.1.0"
+ resolved "https://registry.yarnpkg.com/medium-zoom/-/medium-zoom-1.1.0.tgz#6efb6bbda861a02064ee71a2617a8dc4381ecc71"
+ integrity sha512-ewyDsp7k4InCUp3jRmwHBRFGyjBimKps/AJLjRSox+2q/2H4p/PNpQf+pwONWlJiOudkBXtbdmVbFjqyybfTmQ==
+
minisearch@^6.3.0:
version "6.3.0"
resolved "https://registry.yarnpkg.com/minisearch/-/minisearch-6.3.0.tgz#985a2f1ca3c73c2d65af94f0616bfe57164b0b6b"