From: Leandro Lucarella Date: Sat, 6 Jun 2009 21:26:12 +0000 (-0300) Subject: Eliminar prefijo "ref_" de nombres de referencias X-Git-Tag: entrega-2010-10-08~57 X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/commitdiff_plain/e06143e98714199eba6570381554d812fd86556d?ds=sidebyside;hp=8bcc93e87bfa1ba45990d600ae79f0a782102818 Eliminar prefijo "ref_" de nombres de referencias No son necesarios y hacen más tedioso redactar texto con referencias. --- diff --git a/source/conclusion.rst b/source/conclusion.rst index f25361c..8016852 100644 --- a/source/conclusion.rst +++ b/source/conclusion.rst @@ -5,7 +5,7 @@ ESTADO: SIN EMPEZAR -.. _ref_conclusion: +.. _conclusion: Conclusión ============================================================================ diff --git a/source/d.rst b/source/d.rst index b4af95d..15334bd 100644 --- a/source/d.rst +++ b/source/d.rst @@ -5,7 +5,7 @@ ESTADO: TERMINADO -.. _ref_d: +.. _d_lang: El lenguaje de programación D ============================================================================ @@ -174,7 +174,7 @@ agrupadas por unidades funcional o paradigmas que soporta: -.. _ref_d_generic: +.. _d_generic: Programación genérica y meta-programación ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -426,7 +426,7 @@ Expresiones ``is``: -.. _ref_d_low_level: +.. _d_low_level: Programación de bajo nivel (*system programming*) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -501,7 +501,7 @@ Objetos y arreglos *livianos*: gettimeofday(&tv, null); Rendimiento: - la :ref:`ref_d_generic` permite realizar muchas optimizaciones ya que se + la :ref:`d_generic` permite realizar muchas optimizaciones ya que se resuelve en tiempo de compilación y por lo tanto aumentando la *performance* en la ejecución. @@ -524,7 +524,7 @@ Control de alineación de miembros de una estructura: -.. _ref_d_high_level: +.. _d_high_level: Programación de alto nivel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -533,7 +533,7 @@ Programa de alto nivel se refiere a construcciones más avanzadas que un loop. Expresiones semánticamente más ricas que permiten mayor expresividad al programador o le permiten focalizarse de mejora manera en los algoritmos independizándose del *hardware* o de como funciona una computadora. Es -exactamente el opuesto a :ref:`ref_d_low_level`. +exactamente el opuesto a :ref:`d_low_level`. En general estas características tiene como efecto secundario una mejora de la productividad de los programadores. D_ adopta herramientas de muchos diff --git a/source/dgc.rst b/source/dgc.rst index cb59594..929d48c 100644 --- a/source/dgc.rst +++ b/source/dgc.rst @@ -7,7 +7,7 @@ ESTADO: SIN EMPEZAR, REVISAR LO HECHO -.. _ref_dgc: +.. _dgc: Recolección de basura en D ============================================================================ @@ -23,7 +23,7 @@ TODO -.. _ref_dgc_actual: +.. _dgc_actual: Recolector de basura actual de D ---------------------------------------------------------------------------- diff --git a/source/gc.rst b/source/gc.rst index 7b36319..c32bfee 100644 --- a/source/gc.rst +++ b/source/gc.rst @@ -5,14 +5,14 @@ ESTADO: TERMINADO -.. _ref_gc: +.. _gc: Recolección de basura ============================================================================ -.. _ref_gc_intro: +.. _gc_intro: Introducción ---------------------------------------------------------------------------- @@ -195,7 +195,7 @@ normalmente se lo llama *mutator* (mutador). -.. _ref_gc_intro_mark: +.. _gc_intro_mark: Recorrido del grafo de conectividad ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -594,15 +594,15 @@ dejando sin marcar solamente las celdas *basura* (en blanco). -.. _ref_gc_intro_tricolor: +.. _gc_intro_tricolor: Abstracción tricolor ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Muchos algoritmos utilizan tres colores para realizar el marcado. El tercer color, gris generalmente, indica que una celda debe ser visitada. Esto -permite algoritmos :ref:`concurrentes ` -e :ref:`incrementales `, además de otro tipo de optimizaciones. +permite algoritmos :ref:`concurrentes ` +e :ref:`incrementales `, además de otro tipo de optimizaciones. Entonces, lo que plantea esta abtracción es una nueva partición del heap al momento de marcar, esta vez son 3 porciones: blanca, gris y negra. @@ -639,7 +639,7 @@ por sí ya presenta una ventaja sobre el marcado *bicolor*. -.. _ref_gc_intro_services: +.. _gc_intro_services: Servicios ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -704,7 +704,7 @@ siguientes: cambio en la conectividad del grafo, la eliminación de una arista (análogo a :math:`update(ref, null)` pero sin proporcionar información sobre la arista a eliminar). Esto es generalmente útil solo en - :ref:`conteo de referencias `. Para otros recolectores puede + :ref:`conteo de referencias `. Para otros recolectores puede significar que el usuario asegura que no hay más referencias a esta celda, es decir, análogo a eliminar el conjunto de aristas :math:`\big\lbrace (v, w) \in A , v \in Live \thickspace set , w \in @@ -723,7 +723,7 @@ usuario también. -.. _ref_gc_classic: +.. _gc_classic: Algoritmos clásicos ---------------------------------------------------------------------------- @@ -735,14 +735,14 @@ más simples a fin de facilitar la comprensión conceptual. -.. _ref_gc_rc: +.. _gc_rc: Conteo de referencias ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Se trata del algoritmo más antiguo de todos, implementado por primera vez por `John McCarthy`_ para Lisp_ a finales de 1950. Se trata de un método -:ref:`directo ` e :ref:`incremental ` por +:ref:`directo ` e :ref:`incremental ` por naturaleza, ya que distribuye la carga de la recolección de basura durante toda la ejecución del programa, cada vez que el *mutator* cambia la conectividad de algún nodo del grafo de conectividad. @@ -814,7 +814,7 @@ siguientes (acompañadas de una implementación básica):: -.. _ref_gc_rc_cycles: +.. _gc_rc_cycles: Ciclos ^^^^^^ @@ -849,7 +849,7 @@ la versión 5.3 (todavía no liberada al momento de escribir este documento) [PHP081]_. -.. _ref_gc_rc_example: +.. _gc_rc_example: Ejemplo ^^^^^^^ @@ -1607,7 +1607,7 @@ figura :vref:`fig:gc-rc-cycle`). -.. _ref_gc_mark_sweep: +.. _gc_mark_sweep: Marcado y barrido ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1616,7 +1616,7 @@ Este algoritmo es el más parecido a la teoría sobre recolección de basura. Consiste en realizar la recolección en 2 fases: marcado y barrido. La primera fase consiste en el proceso de marcar el grafo de conectividad del *heap* para descubrir qué celdas son alcanzables desde el *root set*, tal y como se -describió en :ref:`ref_gc_intro_mark`. +describió en :ref:`gc_intro_mark`. Una vez marcadas todas las celdas, se sabe que las celdas *blancas* son *basura*, por lo tanto el paso que queda es el *barrido* de estas celdas, @@ -1652,19 +1652,19 @@ A continuación se presentan los servicios básicos de este algoritmo:: free(cell) El algoritmo ``mark_sweep()`` es exactamente igual al presentado en -:ref:`ref_gc_intro_mark`. Es preciso notar que la fase de barrido +:ref:`gc_intro_mark`. Es preciso notar que la fase de barrido (``sweep_phase()``) debe tener una comunicación extra con el *low level allocator* para poder obtener todas las celdas de memoria que existen en el *heap*. A diferencia del conteo de referencias, este algoritmo es :ref:`indirecto -` y :ref:`no incremental `, ya que se realiza un +` y :ref:`no incremental `, ya que se realiza un recorrido de todo el *heap* de forma espaciada a través de la ejecución del programa. En general el *mutator* sufre pausas considerablemente mayores (en promedio) que con el conteo de referencias, lo que puede ser problemático para aplicaciones con requerimientos rígidos de tiempo, como aplicaciones *real-time*. Debido a la percepción de las pausas grandes, este tipo de -colectores se conocen como :ref:`stop-the-world ` (o +colectores se conocen como :ref:`stop-the-world ` (o *detener el mundo*). Una ventaja fundamental sobre el conteo de referencias es la posibilidad de @@ -1679,7 +1679,7 @@ linealmente. -.. _ref_gc_copy: +.. _gc_copy: Copia de semi-espacio ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1727,7 +1727,7 @@ cambia al ser movidas, es necesario actualizar la dirección de memoria de todas las celdas *vivas*. Para esto se almacena una dirección de memoria de redirección, *forwarding address*, en las celdas que mueven. La *forwarding address* sirve a su vez de marca, para no recorrer una celda dos veces (como -se explica en :ref:`ref_gc_intro_mark`). Cuando se encuentra una celda que ya +se explica en :ref:`gc_intro_mark`). Cuando se encuentra una celda que ya fue movida, simplemente se actualiza la referencia por la cual se llegó a esa celda para que apunte a la nueva dirección, almacenada en la *forwarding address*. Una vez finalizado este proceso, el *Fromspace* y *Tospace* @@ -1789,11 +1789,11 @@ Esta técnica tiene nombres variados en inglés: *semi-space*, *two-space* o simplemente *copying collector*. En este documento se denomina "copia de semi-espacio" porque los otros nombres son demasiado generales y pueden describir, por ejemplo, algoritmos donde no hay copia de celdas o donde no hay -2 semi-espacios (como se verá en :ref:`ref_gc_art`). +2 semi-espacios (como se verá en :ref:`gc_art`). -Al igual que el :ref:`ref_gc_mark_sweep` este algoritmo es :ref:`indirecto -`, :ref:`no incremental ` y :ref:`stop-the-world -`. Las diferencias con los esquemas vistos hasta ahora son +Al igual que el :ref:`gc_mark_sweep` este algoritmo es :ref:`indirecto +`, :ref:`no incremental ` y :ref:`stop-the-world +`. Las diferencias con los esquemas vistos hasta ahora son evidentes. La principal ventaja sobre el marcado y barrido (que requiere una pasada sobre el *live set*, el marcado, y otra sobre el *heap* entero, el barrido) es que este método require una sola pasada y sobre las celdas vivas @@ -2050,7 +2050,7 @@ nueva ubicación de ``h3``, como se muestra en la figura -.. _ref_gc_art: +.. _gc_art: Estado del arte ---------------------------------------------------------------------------- @@ -2093,7 +2093,7 @@ clase en particular). -.. _ref_gc_direct: +.. _gc_direct: Recolección directa / indirecta ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2103,15 +2103,15 @@ compilador o lenguaje instrumenta al *mutator* de forma tal que la información sobre el grafo de conectividad se mantenga activamente cada vez que hay un cambio en él. Normalmente se utiliza un contador de referencia en cada celda para este propósito, permitiendo almacenar en todo momento la cantidad de -nodos que apuntan a ésta (ver :ref:`ref_gc_rc`). Esto permite reclamar una +nodos que apuntan a ésta (ver :ref:`gc_rc`). Esto permite reclamar una celda instantáneamente cuando el *mutator* deja de hacer referencia a ella. Este tipo de recolectores son inherentemente :ref:`incrementales -`. +`. Por el contrario, los recolectores **indirectos** normalmente no interfieren con el *mutator* en cada actualización del grafo de conectividad (exceptuando algunos :ref:`recolectores incrementales -` que a veces necesitan instrumentar el *mutator* pero no para +` que a veces necesitan instrumentar el *mutator* pero no para mantener el estado del grafo de conectividad completo). La recolección se dispara usualmente cuando el *mutator* requiere alocar memoria pero no hay más memoria libre conocida disponible y el recolector se encarga de generar @@ -2119,11 +2119,11 @@ la información de conectividad desde cero para determinar qué celdas son *basura*. Esta es la madre de toda clasificación, también conocidos como :ref:`conteo de -referencias ` (directa) y *traicing garbage collection* +referencias ` (directa) y *traicing garbage collection* (indirecta). Prácticamente todos los recolectores menos el :ref:`conteo de -referencias ` están dentro de esta última categoría (como por -ejemplo, el :ref:`marcado y barrido ` y :ref:`copia de -semi-espacio `). +referencias ` están dentro de esta última categoría (como por +ejemplo, el :ref:`marcado y barrido ` y :ref:`copia de +semi-espacio `). Otros ejemplos de recolectores modernos *directos* son el recolector de basura de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo @@ -2131,7 +2131,7 @@ basura de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo -.. _ref_gc_inc: +.. _gc_inc: Recolección incremental ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2142,7 +2142,7 @@ causadas por el recolector (aunque generalmente el resultado es un mayor costo total de recolección en términos de tiempo). De los `algoritmos clásicos`_ el único que es incremental en su forma más -básica es el :ref:`conteo de referencias `. Otros recolectores +básica es el :ref:`conteo de referencias `. Otros recolectores pueden hacerse incrementales de diversas maneras, pero en general consta de hacer parte del trabajo de escanear el grafo de conectividad cada vez que el *mutator* aloca memoria. En general para hacer esto es también necesario @@ -2150,8 +2150,8 @@ instrumentar al *mutator* de forma tal que informe al recolector cada vez que cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en la próxima iteración. Para realizar esto en recolectores :ref:`indirectos -` se utiliza la :ref:`abstracción tricolor -`; cuando el *mutator* cambia una referencia, se marca +` se utiliza la :ref:`abstracción tricolor +`; cuando el *mutator* cambia una referencia, se marca *gris* la celda que la contiene, de modo que el recolector vuelva a visitarla. En general la eficiencia de los recolectores incrementales disminuye @@ -2166,7 +2166,7 @@ Ejemplos de recolectores que se encuentran dentro de esta categoría son -.. _ref_gc_concurrent: +.. _gc_concurrent: Recolección concurrente / paralela / *stop-the-world* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2242,7 +2242,7 @@ los hilos disponibles para realizar la recolección (ver figura Para lograr que un recolector sea concurrente generalmente el mecanismo es similar al necesario para hacer un :ref:`recolector incremental -`: hay que instrumentar al *mutator* para que informe al +`: hay que instrumentar al *mutator* para que informe al recolector cuando se realiza algún cambio en el grafo de conectividad, de forma tal que pueda volver a escanear el sub-grafo afectado por el cambio. @@ -2267,12 +2267,12 @@ ofrece paralelización del procesamiento del recolector en varios hilos) son o más núcleos (*cores*) independientes que trabajan a la misma frecuencia, pero dentro de un solo circuito integrado o procesador. -Todos los :ref:`algoritmos clásicos ` que se han citado son +Todos los :ref:`algoritmos clásicos ` que se han citado son del tipo *stop-the-world*. -.. _ref_gc_free_list: +.. _gc_free_list: Lista de libres / *pointer bump allocation* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2285,7 +2285,7 @@ completamente. En términos generales, hay dos formas fundamentales de organizar el *heap*, manteniendo una lista de libres o realizando *pointer bump allocation*, como -se explicó en :ref:`ref_gc_copy`. La primera forma consiste, a grandes rasgos, +se explicó en :ref:`gc_copy`. La primera forma consiste, a grandes rasgos, en separar el *heap* en celdas (que pueden agruparse según tamaño) y enlazarlas en una lista de libres. Al solicitarse una nueva celda simplemente se la desenlaza de la lista de libres. Por otro lado, cuando el @@ -2293,15 +2293,15 @@ recolector detecta una celda *muerta*, la vuelve a enlazar en la lista de libres. Este es un esquema simple pero con limitaciones, entre las principales, el costo de alocar puede ser alto si hay muchos tamaños distintos de celda y soportar tamaño de celda variable puede ser complejo o acarrear -muchas otras ineficiencias. :ref:`ref_gc_mark_sweep` en general usa este -esquema, al igual que :ref:`ref_gc_rc`. +muchas otras ineficiencias. :ref:`gc_mark_sweep` en general usa este +esquema, al igual que :ref:`gc_rc`. Otro forma de organizar el *heap* es utilizándolo como una especie de *stack* en el cual para alocar simplemente se incrementa un puntero. Este esquema es simple y eficiente, si el recolector puede mover celdas (ver -:ref:`ref_gc_moving`); de otra manera alocar puede ser muy costoso si hay que +:ref:`gc_moving`); de otra manera alocar puede ser muy costoso si hay que buscar un *hueco* en el heap (es decir, deja de reducirse a incrementar un -puntero). El clásico ejemplo de esta familia es :ref:`ref_gc_copy`. +puntero). El clásico ejemplo de esta familia es :ref:`gc_copy`. Sin embargo, entre estos dos extremos, hay todo tipo de híbridos. Existen recolectores basados en *regiones*, que se encuentran en un punto intermedio. @@ -2311,25 +2311,25 @@ las regiones en sí se administran como una lista de libres (como por ejemplo allocators* que alocan páginas completas (similar a las regiones) y dentro de cada página se alocan las celdas. Ambas, páginas y celdas, se administran como listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el -:ref:`recolector actual de D `). +:ref:`recolector actual de D `). -.. _ref_gc_moving: +.. _gc_moving: Movimiento de celdas ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Otra característica muy importante del recolector de basura es si mueve las celdas o no. En general el movimiento de celdas viene de la mano del esquema -de :ref:`pointer bump allocation `, ya que *compacta* todas +de :ref:`pointer bump allocation `, ya que *compacta* todas las celdas *vivas* al comienzo del *heap* luego de una recolección, permitiendo este esquema para alocar nuevas celdas, pero puede utilizarse en esquemas híbridos como recolectores basados en *regiones* (por ejemplo [BLAC08]_). Además los recolectores con movimiento de celdas deben ser :ref:`precisos -`, porque es necesario tener la información completa de los +`, porque es necesario tener la información completa de los tipos para saber cuando actualizar los punteros (de otra manera se podría escribir un dato de una celda que no era un puntero). Para que un recolector pueda mover celdas, aunque sea parcialmente, en recolectores *semi-precisos* @@ -2339,16 +2339,16 @@ referencia no-precisa a ella, y por lo tanto no puede ser movida (porque no se puede estar seguro si es posible actualizar dicha referencia). La ventaja principal de los colectores con movimiento es la posibilidad de -utilizar :ref:`pointer bump allocation ` y que es sencillo -implementar recolectores :ref:`generacionales ` sobre estos. +utilizar :ref:`pointer bump allocation ` y que es sencillo +implementar recolectores :ref:`generacionales ` sobre estos. -De los algoritmos clásicos sólo la :ref:`copia de semi-espacios ` -mueve celdas, el :ref:`conteo de referencias ` y :ref:`marcado -y barrido ` no lo hacen. Además hay otro algoritmo bastante +De los algoritmos clásicos sólo la :ref:`copia de semi-espacios ` +mueve celdas, el :ref:`conteo de referencias ` y :ref:`marcado +y barrido ` no lo hacen. Además hay otro algoritmo bastante básico que mueve celdas, el **marcado y compactado**. Éste no tiene 2 semi-espacios, directamente mueve las celdas compactándolas al comienzo del *heap*. El algoritmo es un poco más complejo que la :ref:`copia de -semi-espacios ` pero suele poder proveer una mayor localidad de +semi-espacios ` pero suele poder proveer una mayor localidad de referencia y *desperdicia* un semi-espacio que está inutilizado salgo en el momento de la recolección. Por ejemplo para Mono_, que antes usaba un recolector conservativo sin movimiento ([BOEHWD]_) se está implementando un @@ -2356,7 +2356,7 @@ recolector de este tipo [MOLAWE]_ [MOLA06]_. -.. _ref_gc_conserv: +.. _gc_conserv: Recolectores conservativos vs precisos ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2369,7 +2369,7 @@ o no. Esto trae una variada cantidad de problemas, como retención de celdas que en realidad son *basura* simplemente porque hay algún dato que coincide con la dirección de memoria en la que está almacenada esa celda *basura* [#gcflasepos]_. Además los recolectores puramente conservativos no puede mover -celdas (ver :ref:`ref_gc_moving`), porque no pueden arriesgarse a actualizar +celdas (ver :ref:`gc_moving`), porque no pueden arriesgarse a actualizar los punteros por el riesgo que existe de que sean falsos positivos. .. [#gcflasepos] Esto es lo que se conoce como un *falso positivo*, algo que @@ -2395,19 +2395,19 @@ de forma conservativa y otras de forma precisa, de manera de mitigar, aunque sea de forma parcial, los efectos adversos de los recolectores conservativos. Estos recolectores son conocidos como *semi-precisos*. Los recolectores semi-precisos pueden mover celdas si utilizan un mecanismo de *pinning* (ver -:ref:`ref_gc_moving`). +:ref:`gc_moving`). El ejemplo de recolector conservativo por excelencia es el recolector `Boehm-Demers-Wiser`_ ([BOEH88]_, [BOEH91]_, [BOEH93]_, [BOEHWD]_) aunque puede comportarse de forma semi-precisa si el usuario se encarga de darle la información de tipos (en cuyo caso el recolector deja de ser transparente para el usuario). Otros ejemplos de recolectores con cierto grado de -conservativismo son el :ref:`recolector actual de D ` +conservativismo son el :ref:`recolector actual de D ` y [BLAC08]_. -.. _ref_gc_part: +.. _gc_part: Recolección particionada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/intro.rst b/source/intro.rst index 4f12824..a8fb1ca 100644 --- a/source/intro.rst +++ b/source/intro.rst @@ -4,7 +4,7 @@ ESTADO: TERMINADO -.. _ref_intro: +.. _intro: Introducción ============================================================================ @@ -108,21 +108,21 @@ Organización Este trabajo se encuentra dividido en 7 cápitos que se describen a continuación: -1. :ref:`ref_intro`: breve descripción del problema a tratar, presentando +1. :ref:`intro`: breve descripción del problema a tratar, presentando los objetivos y alcances del trabajo. -2. :ref:`ref_d`: presenta las características principales del lenguaje, +2. :ref:`d_lang`: presenta las características principales del lenguaje, destacando aquellas de mayor relevancia para este trabajo. -3. :ref:`ref_gc`: presenta los algoritmos básicos de recolección de basura +3. :ref:`gc`: presenta los algoritmos básicos de recolección de basura y describe el estado del arte. -4. :ref:`ref_dgc`: explica los problemas particulares que presenta el +4. :ref:`dgc`: explica los problemas particulares que presenta el lenguaje para la recolección de basura, describe el diseño e implementación del recolector actual y presenta sus principales deficiencias. -5. :ref:`ref_analisis`: realiza un recorrido por los algoritmos presentados - en :ref:`ref_gc` analizando su viabilidad para aplicarse en D_. -6. :ref:`ref_solucion`: propone una solución a los problemas encontrados en - :ref:`ref_dgc` en base al análisis hecho en :ref:`ref_analisis`. -7. :ref:`ref_conclusion`: describe los resultados del trabajo, proponiendo +5. :ref:`analisis`: realiza un recorrido por los algoritmos presentados + en :ref:`gc` analizando su viabilidad para aplicarse en D_. +6. :ref:`solucion`: propone una solución a los problemas encontrados en + :ref:`dgc` en base al análisis hecho en :ref:`analisis`. +7. :ref:`conclusion`: describe los resultados del trabajo, proponiendo trabajos futuros y relacionados. diff --git a/source/referencias.rst b/source/referencias.rst index 8836d3a..6eeac58 100644 --- a/source/referencias.rst +++ b/source/referencias.rst @@ -3,7 +3,7 @@ .. target-notes:: -.. _ref_refs: +.. _refs: .. [BKIP08] Kris Macleod Bell, Lars Ivar Igesund, Sean Kelly, and Michael Parker. Learn to Tango with D. Apress, 2007. ISBN 1-59059-960-8. diff --git a/source/resumen.rst b/source/resumen.rst index 4e4fa94..67630a8 100644 --- a/source/resumen.rst +++ b/source/resumen.rst @@ -3,7 +3,7 @@ ESTADO: TERMINADO -.. _ref_resumen: +.. _resumen: Resumen ============================================================================ diff --git a/source/solucion.rst b/source/solucion.rst index b4bbf4e..37062cb 100644 --- a/source/solucion.rst +++ b/source/solucion.rst @@ -3,7 +3,7 @@ ESTADO: SIN EMPEZAR -.. _ref_solucion: +.. _solucion: Solución adoptada ============================================================================ diff --git a/source/viabilidad.rst b/source/viabilidad.rst index aa19f4f..a829fd5 100644 --- a/source/viabilidad.rst +++ b/source/viabilidad.rst @@ -5,7 +5,7 @@ ESTADO: SIN EMPEZAR -.. _ref_analisis: +.. _analisis: Análisis de viabilidad ============================================================================