path: root/tde-i18n-es/docs/tdevelop/tdevelop/unixdev.docbook

<appendix id="unixdev">

<appendixinfo>
  <authorgroup>
    <author><firstname>Bernd</firstname><surname>Pol</surname></author>
    <!-- ROLES_OF_TRANSLATORS -->
  </authorgroup>
</appendixinfo>

<title>Desarrollo en &UNIX;</title>

<indexterm zone="unixdev"><primary>desarrollo</primary></indexterm>
<indexterm zone="unixdev">
  <primary>&UNIX;</primary>
  <secondary>desarrollo</secondary></indexterm>

<sect1 id="history">
<title>Algunas puntualizaciones históricas</title>

<indexterm zone="history"><primary>historia</primary></indexterm>
<indexterm zone="history"><primary>lenguajes de guiones</primary></indexterm>
<indexterm zone="history">
  <primary>&UNIX;</primary>
  <secondary>historia</secondary></indexterm>
<indexterm zone="history">
  <primary>&UNIX;</primary>
  <secondary>tubería</secondary></indexterm>
<indexterm zone="history">
  <primary>&UNIX;</primary>
  <secondary>shell</secondary></indexterm>
<indexterm zone="history">
  <primary>shell</primary>
  <secondary>&UNIX;</secondary></indexterm>

<para>Desde el principio, &UNIX; ha mantenido dos modelos de desarrollo muy distintos. Uno es el mundo de los <emphasis>lenguajes de programación de sistemas y aplicaciones</emphasis>, donde parte del código fuente se convierte en código máquina por un programa traductor, normalmente un <emphasis>compilador</emphasis> o un <emphasis>intérprete</emphasis>. El lenguaje de programación C es un ejemplo de esto. &UNIX; fue el primer núcleo de sistema operativo escrito en un lenguaje de alto nivel como este en lugar de un ensamblador fuertemente orientado a la máquina, que era lo común antes de ese momento (de hecho, incluso se puede afirmar que el lenguaje C fue creado para escribir el núcleo de &UNIX; y sus programas asociados en un sistema DEC PDP-11). </para>
<para>El otro modelo de desarrollo es el mundo de los <emphasis>lenguajes de guión</emphasis> (o <emphasis>scripts</emphasis>). Este mundo evolucionó con la creación del intérprete de comandos de &UNIX;, que era la interfaz de usuario para comunicarse con el sistema operativo (y, al mismo tiempo, un lenguaje de programación de muy alto nivel). Un guión del intérprete de comandos se construye a partir de un conjunto de pequeños programas de utilidades, como <command>grep</command>, <command>sed</command> o <command>find</command>. Cada una de estas utilidades está diseñada para una tarea muy concreta. El truco consiste en que cada una de estas utilidades se puede conectar con otra mediante un sencillo mecanismo de transporte llamado <emphasis>tubería</emphasis>, que redirecciona la salida de la primera utilidad procesada hacia la entrada de la siguiente. De este modo, este sistema se convierte en una poderosa y muy flexible herramienta de programación. </para>
<para>Ambos mundos han evolucionado a medida que el tiempo ha ido transcurriendo. Mientras que C se sigue utilizando en la actualidad, principalmente como un lenguaje de programación de sistemas, una de sus variantes denominada C++, enriquecida con la orientación a objetos y extensiones genéricas, encontró su lugar en el desarrollo de aplicaciones complejas en la década de 1990. Existen muchos más lenguajes de programación, e incluso los más antiguos siguen estando presentes (FORTRAN77 y Ada, por ejemplo, todavía mantienen su poderío en las aplicaciones matemáticas). </para>
</sect1> <!-- history -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-scripting-languages">
<title>Lenguajes de guiones contemporáneos</title>
<para>En el área de los lenguajes de guiones, se ha producido un alejamiento del intérprete de comandos, que sufre de problemas de portabilidad, hacia lenguajes que unifican en sus bibliotecas estándares toda la funcionalidad que normalmente se suele requerir, siendo aún capaces de interactuar con el mundo exterior mediante el mecanismo de tuberías cuando es preciso. </para>
<para>Todos estos lenguajes de guiones tienen en común que son altamente portables entre variantes de &UNIX;, Microsoft &Windows;, &MacOS; o incluso VMS. Además, todos poseen implementaciones que se pueden distribuir libremente. </para>

<sect2 id="unixdev-SL-Perl">
<title>&perl;</title>

<indexterm zone="unixdev-SL-Perl"><primary>Perl</primary></indexterm>
<indexterm zone="unixdev-SL-Perl">
  <primary>lenguajes de guiones</primary>
  <secondary>Perl</secondary></indexterm>

<para><ulink url="http://www.perl.com">&perl;</ulink> se ha hecho popular como lenguaje de procesamiento de textos y de administración del sistema. Durante los inicios de la Web, los guiones CGI escritos en &perl; constituyeron un método ampliamente usado para crear páginas web dinámicas a partir del contenido de bases de datos. En la actualidad este método ha sido reemplazado principalmente por la extensión <command>mod_perl</command> del servidor web &apache;. Entre las virtudes de &perl; destacan su soporte integrado para trabajar con expresiones regulares avanzadas y su rica colección de módulos que pueden ser libremente distribuidos. </para>
<para>Para obtener más información consulte la página web <ulink url="http://cpan.org">Comprehensive Perl Archive Network (<acronym>CPAN</acronym>)</ulink>. </para>
</sect2> <!-- unixdev-SL-Perl -->

<sect2 id="unixdev-SL-Python">
<title>Python</title>

<indexterm zone="unixdev-SL-Python"><primary>Python</primary></indexterm>
<indexterm zone="unixdev-SL-Python">
  <primary>lenguajes de guiones</primary>
  <secondary>Python</secondary></indexterm>

<para><ulink url="http://www.python.org">&python;</ulink> brilla por la elegancia de su sistema de clases y por la facilidad y flexibilidad con la que se puede acceder a bibliotecas externas de un modo que parezca que se trata de clases y funciones normales de &python;. Al contrario que &perl;, &python; posee una clara y concisa &API; integrada, que lo ha convertido en el lenguaje elegido para integrar en guiones a los programas de C y C++. </para>
</sect2> <!-- unixdev-SL-Python -->

<sect2 id="unixdev-SL-PHP">
<title>PHP</title>

<indexterm zone="unixdev-SL-PHP"><primary>PHP</primary></indexterm>
<indexterm zone="unixdev-SL-PHP">
  <primary>lenguajes de guiones</primary>
  <secondary>PHP</secondary></indexterm>

<para><ulink url="http://www.php.net">&php;</ulink> fue diseñado como un lenguaje que se podía integrar directamente en las páginas &HTML;, por lo que se usa principalmente en la generación de contenidos dinámicos para la web. </para>
</sect2> <!-- unixdev-SL-PHP -->
</sect1> <!-- unixdev-scripting-languages -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1 id="unixdev-hl-script">
<title>Lenguajes de guiones de más alto nivel</title>

<para>Las aplicaciones de &UNIX; de más alto nivel suelen carecer de la velocidad y de la flexibilidad de los mecanismos de guiones orientados a caracteres que posee el intérprete de comandos. Esto es especialmente cierto en el mundo de las interfaces gráficas de usuario (&GUI;), como por ejemplo, &kde;. </para>
<para>Han existido intentos de proporcionar mecanismos similares que funcionaran a un nivel de aplicación más alto, principalmente <link linkend="unixdev-corba">CORBA</link> y, en el entorno &kde;, <link linkend="unixdev-dcop">&DCOP;</link>. </para>

<sect2 id="unixdev-corba">
<title>El protocolo CORBA</title>

<indexterm zone="unixdev-corba"><primary>CORBA</primary></indexterm>
<indexterm zone="unixdev-corba">
  <primary>lenguajes de guiones</primary>
  <secondary>CORBA</secondary></indexterm>
<indexterm zone="unixdev-corba">
  <primary>comunicación</primary>
  <secondary>CORBA</secondary></indexterm>

<para><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm">CORBA</ulink> (<emphasis>Common Object Request Broker Architecture</emphasis>) es un intento de permitir que las aplicaciones de un sistema puedan funcionar conjuntamente a través de redes. Fue ideado de forma independiente por el comité de estándares privado <ulink url="http://www.omg.org">OMG</ulink> (Object Management Group). </para>
<para>Los programas basados en CORBA usan el protocolo estándar IIOP para comunicarse. Las implementaciones basadas en IIOP están disponibles para un amplio abanico de sistemas operativos, lenguajes de programación y redes, por lo que son altamente portables. </para>
<para>El principal inconveniente de CORBA es su escasa velocidad. Mientras esto se puede tolerar en redes locales, se convierte en un verdadero cuello de botella para las comunicaciones entre aplicaciones de un entorno sin red local, como &kde;, que se ejecuta en una única máquina. </para>

</sect2> <!-- unixdev-corba -->

<sect2 id="unixdev-dcop">
<title>La interfaz &DCOP;</title>

<indexterm zone="unixdev-dcop"><primary>DCOP</primary></indexterm>
<indexterm zone="unixdev-dcop">
  <primary>lenguajes de guiones</primary>
  <secondary>DCOP</secondary></indexterm>
<indexterm zone="unixdev-dcop">
  <primary>comunicación</primary>
  <secondary>DCOP</secondary></indexterm>

<para>Otra evolución de lenguajes de guión parecidos a &UNIX; es el protocolo <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"><emphasis>DCOP</emphasis></ulink>, que fue ideado para que la comunicación entre aplicaciones de &kde; no adoleciera de las limitaciones de CORBA. </para>
<para>&DCOP; significa <emphasis>protocolo de comunicación del escritorio</emphasis>, y está implementado como un sencillo mecanismo IPC/RPC construido para operar mediante conectores. En efecto, esto proporciona facilidades similares a las del tradicional sistema de tuberías de &UNIX;. </para>
<para>Los lenguajes de guiones tradicionales del intérprete de comandos están basados en pequeños y brillantes programas de utilidades, que fueron diseñados para trabajar sobre una base estrictamente de texto. &DCOP; permite a los complejos programas gráficos comunicarse entre ellos de un modo bastante parecido. Esto permite, por ejemplo, que un programa de &kde; envíe mensajes a otro programa de &kde;, o que reciba datos de él según sus necesidades. </para>
<para>No obstante, existen ciertos inconvenientes. Para usar &DCOP; un programa debe estar diseñado para contener una interfaz &DCOP; especial. Además, el proceso de comunicación &DCOP; es algo lento (aunque mucho más rápido que CORBA). Pero a cambio devuelve gran parte del poder y flexibilidad de los guiones de &UNIX; a los programas de alto nivel basados en interfaces gráficas de usuario. </para>
<para>Para obtener más información, consulte el artículo <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html">DCOP: Desktop COmmunications Protocol</ulink>, o <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html">The &DCOP; Desktop Communication Protocol library</ulink>, la referencia del &API; de la biblioteca dcop de &kde;. </para>
</sect2> <!--  unixdev-dcop -->

</sect1> <!--  unixdev-hl-script -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-buildsystems">
<title>Sistemas de construcción</title>

<para>Excepto para casos muy simples, un proyecto de programación consistirá en gran cantidad de bloques de construcción de código fuente, cada uno de ellossituado en un archivo distinto para que resulte más fácil de mantener. Para que funcione, es necesario traducir todo esto de modo efectivo a unas pocas unidades de código máquina, de tal modo que permita al sistema operativo cargar y ejecutar el programa. </para>
<para>Para conseguir esto, las herramientas básicas que se necesitan son <itemizedlist>
  <listitem><para>un <emphasis>editor de texto</emphasis> para escribir los archivos de código fuente, </para></listitem>
  <listitem><para>un programa de traducción, normalmente un <emphasis>compilador</emphasis> para convertir el código fuente en archivos de código objeto, </para></listitem>
  <listitem><para>un <emphasis>bibliotecario</emphasis> que recopila archivos de código objeto en bibliotecas para reutilizarlos fácilmente sin necesidad de volver a compilarlos, </para></listitem>
  <listitem><para>un <emphasis>enlazador</emphasis>, que enlaza varios archivos de código objeto y bibliotecas en un único ejecutable, </para></listitem>
  <listitem><para>un <emphasis>sistema «make»</emphasis>, que proporciona varios medios para gestionar todas estas cosas, y tampoco hay que olvidar </para></listitem>
  <listitem><para>un <emphasis>depurador</emphasis> para (con fortuna) encontrar todos los errores del programa, y posiblemente otras herramientas de diagnóstico para conseguir que todo funcione a la perfección. </para></listitem>
</itemizedlist>
</para>

<para>Cuando tenga un gran proyecto que consista posiblemente en cientos de archivos de código fuente, el proceso de compilación se volverá bastante laborioso. No querrá recompilar todos esos archivos cada vez que cambie solo alguno de ellos. Por el contrario, solo querrá compilar los archivos que resulten afectados por las modificaciones. Generalmente no resulta siempre fácil de determinar cuáles de los archivos deben ser recompilados. </para>
<para>Cuando, por ejemplo, modifique el prototipo de una función en un archivo de cabecera, necesitará compilar cada archivo que incluya dicha cabecera. Si su proyecto contiene muchos de estos archivos, es probable que se olvide de alguno de ellos si tiene que realizar esta tarea manualmente. Precisamente por este motivo se hace necesario algún tipo de automatización. </para>

<sect2 id="unixdev-buildsystems-make">
<title>El proceso «make»</title>

<indexterm zone="unixdev-buildsystems-make">
  <primary>make</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>Makefile</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>regla</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>recompilaciones</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>objetivo</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>dependencias</primary></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary>comandos</primary></indexterm>

<para>Una herramienta que se encarga de las recompilaciones es <command>make</command>. Sigue la pista de todo el trabajo utilizando un conjunto de <emphasis>reglas</emphasis> que describen qué hacer en caso de que parte de la información haya cambiado (normalmente un archivo de código fuente o de código objeto). Todas las reglas que pertenezcan a un determinado proyecto se guardan en lo que se denomina un <filename>Makefile</filename>, que es procesado por <command>make</command> cada vez que necesite actualizar su trabajo. </para>
<para>Cada regla consiste en varios bloques de construcción, como <itemizedlist>
  <listitem><para>un <emphasis>objetivo</emphasis>, &ie;, el archivo a construir </para></listitem>
  <listitem><para>un juego de <emphasis>dependencias</emphasis>, básicamente los nombres de todos los archivos de los que depende el objetivo (&eg;, el nombre de un archivo de código fuente, del que el objetivo será el nombre del archivo objeto a construir), y </para></listitem>
  <listitem><para>los <emphasis>comandos</emphasis> que deben ejecutarse para completar el <quote>make</quote> del objetivo (&ie;, para compilarlo o para enlazar otros archivos de código objeto para generar el archivo ejecutable del programa). </para></listitem>
</itemizedlist>
</para>
<para>En esencia, el comando <command>make</command> leerá estas reglas una tras otra, comprobará cada archivo en la lista de dependencias de un determinado objetivo, y hará un «make» de este objetivo de nuevo si alguno de estos archivos ha cambiado, usando para ello los comandos listados en cada regla. </para>
<para>Existen varias posibilidades adicionales para controlar este proceso, por lo que un <filename>Makefile</filename> puede convertirse en algo bastante complejo. No vamos a entrar en detalles sobre esto ahora. No obstante, le recomendamos que se familiarice con la sintaxis de <command>make</command>. Incluso si no suele usarlo directamente, la comprensión de los principios del sistema de construcción puede resultar bastante útil. Consulte el <ulink url="info://make/Top"><quote>Manual GNU de make</quote></ulink> para obtener más información. </para>
<para>Para detalles de &tdevelop; más específicos, consulte el capítulo <link linkend="project-management">Construcción y gestión de proyectos</link> de este manual. </para>
<para>Existen varios manuales disponibles; consulte las <link linkend="automake-references">referenciass</link> en el capítulo sobre construcción y gestión de proyectos. </para>
</sect2> <!-- unixdev-buildsystems-make -->

</sect1> <!-- unixdev-buildsystems -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-guidevelopment">
<title>Desarrollo &GUI;</title>

<indexterm zone="unixdev-guidevelopment">
  <primary>GUI</primary></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary>interfaz gráfica de usuario</primary></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary>interfaz de usuario</primary>
  <secondary>GUI</secondary></indexterm>

<para>Los desarrolladores de aplicaciones se han visto cada vez más incomodados al tener que crear, no solo las librerías y la lógica de sus programas, sino también al hecho de tener que proporcionar una interfaz de construcción personalizada que sea fácil de utilizar, intuitiva y funcional. Muchos programadores no están preparados para el desarrollo de interfaces gráficas, por lo que es habitual que las interfaces de usuario que crean estén pobremente diseñadas. </para>
<para>Durante años, algunos principios de diseño comunes han ido evolucionando, y es altamente recomendable seguirlos. De este modo, sus interfaces de usuario tendrán una apariencia común que el usuario de su aplicación agradecerá. </para>
<para>Existe una guía de estilo para el desarrollo de interfaces de &kde; que puede encontrar en <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html">Recomendaciones para interfaces de usuario de &kde;</ulink> en la página web del desarrollador de &kde;. </para>
<para>Puede encontrar una breve introducción a los principios de diseño de &GUI; <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm">aquí</ulink>. </para>

</sect1> <!-- unixdev-guidevelopment -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-ide">
<title>Integración de conceptos y herramientas &ndash; el IDE</title>

<indexterm zone="unixdev-ide">
  <primary>IDE</primary></indexterm>
<indexterm zone="unixdev-ide">
  <primary>entorno de desarrollo integrado</primary></indexterm>
<indexterm zone="unixdev-ide">
  <primary>desarrollo</primary>
  <secondary>IDE</secondary></indexterm>
<indexterm zone="unixdev-ide">
  <primary>entorno</primary>
  <secondary>IDE</secondary></indexterm>

<para>Existen herramientas separadas disponibles para casi todos los pasos del proceso de programación: planificación, edición, gestión de archivos y proceso de compilación, depuración, documentación y demás. Pero cuando el proyecto crece, los procesos de programación pueden llegar a convertirse en engorrosos. </para>
<para>La mayor parte de este trabajo repetitivo debe realizarse durante las fases de diseño, compilación y depuración de un programa. Se puede ahorrar gran parte de este trabajo mediante el uso de plantillas y guiones. Y otra buena parte teniendo todas estas herramientas listas para usar y haciendo que se comuniquen entre ellas bajo una interfaz común. </para>
<para>Por ejemplo, ¿no sería conveniente que un depurador fuera capaz de abrir un determinado archivo de código fuente en un editor y que colocara el cursor directamente en la posición de un error que acaba de encontrar? </para>
<para>Los <emphasis>Entornos de Desarrollo Integrados</emphasis> (&IDE;) se idearon para adaptarse a estas necesidades. Este &IDE; integra todas las plantillas, herramientas y guiones que suelen ser necesarios durante el proceso de desarrollo en un úncio entorno de trabajo. </para>
<para>&tdevelop; es uno de estos &IDE; para la plataforma &kde;. Proporciona un amplio abanico de herramientas que facilitan el desarrollo y el mantenimiento de proyectos, incluso para distintos lenguajes de programación y diversas plataformas. </para>

<sect2 id="unixdev-ide-tdevelop">
<title>Características básicas de &tdevelop; &kdevrelease;</title>

<indexterm zone="unixdev-ide-tdevelop">
  <primary>&tdevelop;</primary>
  <secondary>características</secondary></indexterm>
<indexterm zone="unixdev-ide-tdevelop">
  <primary>características</primary></indexterm>

<!-- ### copied from web page, needs to be updated -->

<itemizedlist>
  <listitem>
  <para>Gestiona todas las <emphasis>herramientas de desarrollo</emphasis> necesarias para programar en C++, como un compilador, un enlazador, un depurador y un sistema de construcción.</para>
  </listitem>
  <listitem>
  <para>Proporciona un <emphasis>&appwizard;</emphasis> que genera aplicaciones de ejemplo completamente funcionales.</para>
  </listitem>
  <listitem>
  <para>Permite al usuario seleccionar un <emphasis>editor integrado</emphasis> basado en el editor para programadores &kwrite; de &kde;, el <application>QEditor</application> de Trolltech, u otros.</para>
  </listitem>
  <listitem>
  <para>Un <emphasis>generador de clases</emphasis> para crear nuevas clases e integrarlas en el proyecto actual.</para>
  </listitem>
  <listitem>
  <para><emphasis>Gestión de archivos</emphasis> para el código fuente, cabeceras, documentación, &etc;, a incluir en el proyecto.</para>
  </listitem>
  <listitem>
  <para>Asistencia para <emphasis>crear manuales de usuario para la aplicación</emphasis> escritos con las herramientas de &kde;.</para>
  </listitem>
  <listitem>
  <para><emphasis>Documentación para la &API;</emphasis>, basada en &HTML; y generada automáticamente para las clases del proyecto, con referencias cruzadas a las bibliotecas usadas.</para>
  </listitem>
  <listitem>
  <para><emphasis>Soporte para internacionalización</emphasis>, que permite a los traductores añadir fácilmente su propio idioma a un proyecto, incluyendo soporte para &kbabel;.</para>
  </listitem>
  <listitem>
  <para>Soporte para manejar un proyecto mediante uno de varios <emphasis>sistemas de versiones</emphasis> (&eg;, &CVS;), proporcionando una interfaz fácil de usar para las funciones más necesarias.</para>
  </listitem>
  <listitem>
  <para>Una interfaz integrada de <emphasis>depuración</emphasis>.</para>
  </listitem>
  <listitem>
  <para>Un emulador integrado de la <emphasis>consola</emphasis>.</para>
  </listitem>
  <listitem>
  <para><emphasis>Resalte de sintaxis</emphasis> en los textos de código fuente.</para>
  </listitem>
  <listitem>
  <para>Una utilidad de <emphasis>terminación automática de código</emphasis> para las variables y métodos de las clases, argumentos de funciones, y demás.</para>
  </listitem>
  <listitem>
  <para><emphasis>Plantillas para la creación de distintos proyectos</emphasis> (módulos para &kcontrol;, añadidos para &kicker; (panel), KIOSlaves, extensiones para &konqueror; y estilos de escritorio, entre otros).</para>
  </listitem>
  <listitem>
  <para>Cuatro <emphasis>vistas de navegación en árbol</emphasis> para cambiar con facilidad entre archivos de código fuente, archivos de cabecera, clases y documentación, eliminando la necesidad de un gestor de archivos externo.</para>
  </listitem>
  <listitem>
  <para><emphasis>Soporte para compilación cruzada</emphasis>, con la posibilidad de especificar distintos compiladores, banderas de compilación, arquitecturas de destino, &etc;</para>
  </listitem>
  <listitem>
  <para>Soporte para <emphasis>proyectos Qt/Embedded</emphasis> (como los de Zaurus e iPAQ).</para>
  </listitem>
  <listitem>
  <para><emphasis>Inclusión de otros programas</emphasis> que necesite para desarrollar, añadiéndolos al menú <guimenuitem>Herramientas</guimenuitem>, según sus necesidades personales.</para>
  </listitem>
</itemizedlist>

</sect2> <!-- unixdev-ide-tdevelop -->

</sect1> <!-- unixdev-ide -->

</appendix> <!-- unixdev -->