Aplicaciones delphi para Linux, excelente
 

Hola Amigos,

Se que muchos de nosotros lo esperamos con ansias ya que nuestras aplicaciones firemonkey funcionaran en linux de forma nativa, les comparto el link por si no lo han visto


https://community.embarcadero.com/bl...ux-development


Saludos,

Firemonkey? Que yo sepa el soporte para Linux que viene en Delphi Tokyo es solo aplicaciones de consola. El enfoque es puramente para la creacion de servidores, nada de GUI

Aca hay algo de feedback de la Beta

:confused::confused:

En el articulo que vi no especificaba que era solo para aplicaciones de consola aunque el ejemplo al final era de consola, supongo que es primer paso ya que esta beta es reciente es para berlin 10.1.2 y todo se hará a través del PAServer desarrollado para linux así que no creo que duren mucho tiempo sin adaptarlo a las aplicaciones visuales ya que es la tendencia, y si microsoft esta apostando por integrar todas sus aplicaciones a las demás plataformas de la competencia iría dejando a Delphi muy atras. Inicialmente las distribuciones de linux que la soportaran serán Ubuntu y RetHat.

Viendo el articulo que ofreciste al parecer esa es otra herramienta hecha por alguien que trabaja en embarcadero.

Saludos,

y si, se están dando los pasos para ello, según este articulo podemos irnos preparando para ver nuestras aplicaciones corriendo de forma nativa en linux

https://community.embarcadero.com/bl...ring-for-linux

Lo mismo, el enfoque es puramente para crear servicios y backends. A mi me parece lo mas acertado, siempre se extraño bastante el no poder crear un buen servidor en Linux con Delphi; estabamos obligados a montar toda la infraestructura en Windows y en este sector se sabe que el rey es Linux

No veo sentido crear aplicaciones en modo consola o crear módulos de apache para linux. La librería que actualmente existen para entorno Web tanto en PHP o Java están a años luz comparado con las de delphi, por lo que el desarrollo como backend y consola sigo sin verle sentido.

Considero que Delphi, debería tomarse más en serio la plataforma de .Net Core de Microsoft que es Open Source, así como corregir los bugs y mejorar la VCL, e intentar migrar el FireMonkey para que funcione con .Net Core.

Mientras tanto que siga mejorando la vcl y los bugs del IDE.

Un saludo:)

No se trata de modulos apache solamente. Se trata de "todo" menos Vcl o FMX. A mi me parece bastante lo que se puede hacer

Tal y como ha comentado Agustín, el enfoque de Embarcadero es el de crear aplicaciones que hagan de Servidores para DataSnap y para Backend.
No está previsto que se generen aplicaciones visuales para Linux.

Al contrario.
La mayoría de servidores existentes actualmente son máquinas Linux/Unix frente a máquinas Windows, y es un campo en el que Embarcadero no puede entrar actualmente.
Con esta nueva caractrística la idea es poder desarrollar Backend en Delphi/Builder para que aplicacionmes desarrolladas en cualquier otro lenguaje (no sólo Delphi/Builder) se puedan conectar.

El PAServer se usa para el Deployment de la aplicación, de forma similar a como se hace ahora con OSX/IOS.

Para desarrollar nativamente para linux puedes usar lazarus.

Aquí está la explicación del Roadmap (en Inglés):

Coming Linux support, which we’ll soon start previewing. Having the ability of taking your server side code (Apache extensions, console applications, WebBroker projects, DataSnap server, RAD Server modules, custom middle-tier architectures), keep your data access components and deploy on Linux on-premise machines or cloud instances, will open up new possibilities for Delphi developers -- and C++Builder ones as well.

Si desarrollamos aplicaciones nativas en Linux, el Delphi debería poder cargar o importar las librerías de Linux, como si fuesen dll's en windows y poder reusar el código existente de Linux.

Por lo que veo, el próximo Delphi para Linux, no es capaz de llamar a estas librerías y tampoco las puede importar. Es como si el Delphi para Linux fuese un framework interno, que no puede relacionarse con las librerías en Linux.

Esto a mi entender es una pena, porque no somos capaces de poder trabajar con estas librerías.

También veo una pena, que el Rad Server, solo funciona con una base de datos de Interbase, y no es posible montarla sobre otro motor de base datos, como Mysql, Postgres, MariaDB, etc,, que soy muchos más potentes que Interbase y gratuitas.

Tampoco sabemos con que infraestructura funciona Rad Server a la hora de generar sevicios web, es decir, si detrás está un servidor Apache, o Nginx, o Tomcat, o usa un servidor web interno, algo que sería muy preocupante.

Por mi parte, la parte de servicios web y aplicaciones empresariales o multicapa, las desarrollo con Java y llamo a estor servicios desde Delphi. Y funciona bastante bien.

Creo que estás equivocado en algunas de tus suposiciones.
Interbase es la Base de Datos que viene con Delphi/Builder (porque tiene que traer alguna), pero eso no quiere decir que no puedas trabajar con otros motores.

"Una imagen vale más que mil palabras", o eso dicen...



(Fíjate que además trae drivers nativos en muchas de ellas).

RAD Server se basa en FireDac, por lo tanto las conexiones a Base de Datos son las mismas...

Entiendo que el motor local de base de datos es Interbase y se puede conectar con cualquier base de datos. No?

Puedes usar cualquier Base de Datos / cualquier SGBD.
Interbase es un SGBD como cualquier otro. No tienes porqué usarlo ni en la parte cliente ni en la parte servidor.

Gracias por la aclaración. Creí que cuando se instalaba el Rad Studio Server, instalaba el Interbase. Después ya podías conectarte con cualquier motor para implementar los servicios.

Realmente no se si con la instalación lo instala o no. En todo caso la utilización es opcional.
El igual que cuando instalas Delphi o Builder, que durante la instalación te pregunta si quieres instalarlo o no, pero la decisión de instalarlo/utilizarlo es tuya.

Lo "unico" que no tiene Delphi para Linux es un Framework para crear GUI (ie Vcl o FMX). NADA te impide llamar a las APIs de linux para lograrlo. Obviamente que es muchisimo mas comodo desarrollar usando un Framework y no directamente con la API. Por ej. se puede evitar completamente la Vcl y crear una aplicacion windows programando a pelo con la API, que no es ni mas ni menos que el trabajo que hace la Vcl internamente

A eso me referia con que el soporte es para "todo", lo que le falta es un Framework para generar interfaz grafica. Pero todo lo que sea codigo RTL + DataSnap es portable directamente. Lo unico que no anunciaron (o yo no me entere) es si el compilador es ARC o no. Si es ARC quiza se deba tener en cuenta algunos puntos a la hora de migrar

Que yo sepa ARC —Automatic Reference Counting— es y seguirá siendo sólo para dispositivos móviles. Aunque resulta tentador que lo fuera ya para todas las plataformas.

Casimiro: ¿Cómo es Lazarus en ese aspecto? ¿Los objetos usan contadores de referencias automáticos como lo hacen los valores String? ¿En qué plataformas? ¿Sólo en dispositivos móviles, igual que Delphi? Creo que sería interesante conocerlo.

Saludos. :)

Embarcadero tiene dos problemas que impiden convertir los compiladores para Win32 y Win64 en compiladores ARC: el codigo existente que puede perder compatibilidad hacia atras; y problemas de performance. Performance sobre todo para servidores, en donde desde luego un manejo de la memoria "personalizado" seguro que es superior a uno "automatico"; sobre todo si eso implica usar operaciones thread-safe para ir incrementando y decrementando referencias, todo eso envuelto en un try-finally (lo cual genera mas y mas codigo maquina)

La unica razon por la cual el resto de los compiladores son ARC es porque los compraron asi

Yo tambien creo que lo mejor es que todos sigan el mismo esquema de memoria. Para el programador casual es inadvertido. Pero para los bibliotecarios es un problema. Basta con hurgar un poco en el propio codigo de la RTL, se ven bastantes condicionales {$IFDEF} ARC.

Y es que si bien es bastante transparente, a veces el modelo de memoria subyacente puede condicionar el codigo

Lo del performance es falso. Es todo al revez.

Un recolector de basura es más eficiente para servidores que el reference counting o el manejo manual.

El problema de los GC es que (tal vez, depende del tipo que se use) introducen pausas y que consumen más memoria. Por eso, el modelo de ARC es ideal para móviles: No introduce pausas (que sería más notable en un equipo que casi en su totalidad funciona como interface de usuario) y consume menos memoria (que se traduce en mayor longevidad en la batería y economía de recursos).

Pero los GC son más eficientes en un entorno de servidor porque pueden operar en "batch" sobre un mayor rango de memoria (por ejemplo, sobre .NET), e incluso puede delegarse a un hilo aparte.

Esto conduce a la idea contra-intuitiva que Java arrasa en desempeño a otros entornos (osea, en workloads de servidor), porque tiene uno de los VM/GC mejor tuneados de la industria.

Esto es GC 101:
http://www.iecc.com/gclist/GC-faq.ht...on%20questions

http://www.memorymanagement.org/

----

Tengan en cuenta que un VM/GC vs manual es similar a un lenguaje alto nivel vs. assembler:

Asi como es posible que un humano escriba el mejor assembler posible, pero esto seria un humano MUY ESCASO y que en la realidad la *mayoria* seran derrotados por el assembler de un compilador decente <- porque este compilador decente a sido escrito por *ese tipo de humanos escasos*.

Entonces, un GC/VM derrota al promedio de los humanos a la hora de manejar la memoria. Mientras es posible escribir un código superior, hacerlo todo el tiempo correctamente es MUY dificil y escaso.

Ademas, aunque Delphi es mas de alto nivel que C/C++ sin perder su capacidad de ser eficiente tiene el problema de que carece de un protocolo/idioma universal como el RIIA, dejando en manos del programador promedio todo el proceso.

Exacto, se puede desarrollar utilizando las APIs de Linux pero de lo que se trata es del desarrollo RAD y que abarque la mayor cantidad de plataformas y dispositivos por lo que un Framework para abstraer las plataformas sin tantas directivas de compilación (De eso debería encargarse el framework) es lo ideal. Mi opinion es que Firemonkey y delphi tienen futuro a largo plazo solo si los dueños se concentran y enfocan los recursos en diseñarlo como si fuera un gran edificio aunque solo se puedan construir dos o tres plantas inicialmente como hizo Microsoft en su tiempo con .net Framework. con la ventaja de que Firemonkey ya contiene una buena cantidad de código que puede utilizarse para dicho Framework y separar la interfaz visual para que invoque las funciones de dicho framework ademas de matar dos pájaros de un mismo tiro con los servidores. Quizás eso suene costoso y es a lo que le temen.



Es cierto que Idera puede utilizar el framework de Microsoft pero esto se trata de negocios y confiar mucho en la competencia no conviene tanto. ademas de lo ligero que puede ser dicho framework ya que solo tendría lo necesario, .net Core es mucho mas ligero que su antecesor pero siempre hay algo que se puede mejorar. La funcionalidad y rapidez siempre son bienvenidas y desde mi punto de vista es un camino viable.

.NET Core no pinta nada aqui, entre otras cosas porque asume un GC. Ademas ya estan usando LLVM, que es una mejor opcion para el tipo de lenguaje que es Delphi

así es mamcx, a lo que me refiero es que los dueños de Delphi deberían ir pensando en elaborar su propio framework desde hace ya mucho tiempo; claro hay que entender lo económico pero a veces fijándonos en los errores de los otros podemos aprender para no cometerlos. haciendo un framework lite inicial que no abarque el universo pero si que sea flexible a futuras ampliaciones que encajen naturalmente

LLVM tiene sus ventajas, pero podrá ser sostenible con los tantos cambios que van surgiendo en este sector?.

¡Ojalá! Porque Embarcadero le está apostando mucho a esa cosa. ^\||/

???

LLVM es prácticamente un estándar de la industria (junto a GCC). Lo dificil es para cualquier otro alcanzarlo! De hecho, es seguro que es un compilador mas eficiente, capaz y potente que el de delphi. Es inevitable que lo sea: Todo el mundo le mete la mano para lograrlo. Quizas solo GCC le da batalla.

De todas maneras hay que entender que uno de los atractivos de Delphi/Pascal es su velocidad de compilacion, y usar cualquier otro backend tiene implicaciones no solo en esto sino en la semantica del codigo.

Hacer estos cambios son muy problemáticos, porque la mayoria esperaria que se conserve toda la semantica del código legado, lo que surge entonces: Para que hacer nuevo algo, para que tenga que emular lo viejo que ya esta resuelto con lo viejo?

Si se meten en un proyecto asi, es para hacer algo radical. Sino, no tiene sentido.

Es correcto lo que dices pero la cuestión es si será sostenible, Microsoft lo sopeso en su momento antes de crear .net framework y lo que sucede ahora es que el mercado tecnológico se esta expandiendo muy rápido distintos sistemas operativos populares, distintos dispositivos populares y cada año que pase la tendencia es a la diversidad, ya no estamos en la época de solo programar para los pcs. Delphi seguirá adaptándose a estos cambios pero a que precio?.

Mi opinión es que con un framework ligero bien pensado cualquier cambio que surja no afectaría tanto el esquema del lenguaje mas bien el framework, claro los programadores de aplicaciones tendrían una curva de aprendizaje inicial, pero con Firemonkey he visto muchas cosas nuevas y de hecho muchas cosas que parecen similares a vcl y funcionan distinto, dejando fuera lo que tiene que ver con dispositivos móviles.

100% de acuerdo contigo, y creo que el objetivo de todo lenguaje debe ser eficiencia, facilidad y elegancia a la hora de resolver problemas. Delphi siempre a tenido la aceptación por ser un lenguaje que facilita por mucho lo que se hace con C++; C# a tenido éxito por ser un lenguaje elegante a la hora de resolver los problemas que con java parecen mas complejos que con C++ ademas de la eficiencia C# vs Java. cambiar la sintaxis de Delphi seria quitarle la esencia pero algún equilibrio habrá que buscar para que sea sostenible seguir con LLVM.

Hablando de lenguajes, ha, del verbo haber (hacer clic en el botón Conjugar). ;)

Gracias por la corrección Al González ^\||/

De nada. Todo sea para que estos foros no se degraden como sucedió con Facebook. :)

No entiendo que es lo que propones y pareces que estas confundido como se relacionan las diversas partes de un compilador.

El "back-end", como LLVM o un bytecode de .NET/Java/etc no necesariamente están amarrados al "front-end" de un lenguaje. Son una especificación de bajo nivel. El caso de LLVM esta diseñado para ser el back-end de cualquier tipo de lenguaje, aunque tiene bias para los que son tipo C/C++/Pascal. En el caso de los bytecodes que corren en .NET/Java estos tienen un bias muy alto hacia lenguajes con GC y mas costo al interfazar con codigo nativo, asi que son menos optimos para algo como Delphi (osea, es *posible* pero no *practico*).

Delphi no debe tener nada de problema, excepto el que deban hacer la implementacion de esta hacia LLVM.

Si estudias como implementar un lenguaje, veras que lo mas pesado esta en el back-end. Y LLVM es muy bueno. No hay nada de donde se pueda suponer que LLVM es un problema, e incorporarlo es menos dificil que tener que replicar lo que hace.

O podrias aclarar que es lo que propones?

OK creo que me confundí un poco con LLVM, pero a lo que me refiero es si embarcadero podría de forma más rápida ir reduciendo la cantidad de bugs que pueden surgir atendiendo a muchas plataformas a la vez, sin dividir el código que esta detrás en más capas de responsabilidades que creo es lo que hace el framework, por favor me corriges si estoy confundido para así ir dejando el código más limpio en el tiempo, si luego aparecen mil tipos de dispositivos con otras plataformas más con la estructura que ellos han realizado podrán anticiparse mas a posibles bugs?

Primero, no es tanto el # de dispositivos sino sus arquitecturas.

No hay nada en el horizonte cercano que sea más allá de ARM, Intel/AMD y soporte a GPUS (Cuda, Vulcan) que no esta ahora presente. Incluso en embeidos prácticamente ARM es la plataforma dominante a futuro, y lo que sea con rasperry & similares pues no es el mercado de Delphi.

Hay algunas cosas que podrian surgir, como los NVMe y otras cosas un poco esotericas, pero igual no es el mercado de Delphi e igualmente LLVM se porta a esas cosas si hay interes real.

Lo que realmente es un problema no es tanto los procesadores y sus arquitecturas, sino el adaptarse a los OS y en especial a los toolkits graficos.

Eso es un problema que las maquinas virtuales NO RESUELVEN, y es engorroso sea como sea. COn todo si Delphi ya esta en iOS/Android no hay otro toolkit que se vislumbre en el futuro que valga la pena.

---

El problema de fondo aquí es más de enfoque de Embarcadero en calidad vs. nuevas características que en si el compilador.

Aun si fuera mas abierto (open source) igual al ser un nicho no tendría el caudal de apoyo necesario, a menos que otro participante (como por ejemplo MS) le diera por meterle mano. Y sin embargo, no veo que se puede hacer con el problema de la multiplataforma.

Es que la parte no-visual es "trivial" en comparación con el acceso a la GUI/Apis nativas, y no se me ocurre que exista una forma eficaz de resolver el tema aparte de "sudor, lagrimas & mucho esfuerzo".

---
En resumen: Delphi ya esta a medio paso usando LLVM. Mejor back-end para *Delphi* es improbable que exista. El hacer una capa que simplifique portar es "trivial" si ignoramos la parte visual, el acceso a APIs nativas y el entramaje de apis de terceros de esas plataformas y solo estamos hablando del lenguaje como si.

Pero NO HAY solucion para mas alla de la compatibilidad basica de los lenguajes.

Es por donde va mi razonamiento mamcx

Ahí esta el punto clave, el API funcional y Gráfico de cada sistema operativo a menos que no haya una standardization como si fueran tomas que el SO utilice, encubriendo sus interioridades para encender la parte visual sin mucho sudor y dudo que la haya porque esto también va a depender del hardware del dispositivo, ademas de que cada nueva tecnología en SO no es para acomodar a los programadores sino a los usuarios, si le sumamos que por cuestiones de tiempo de lanzamiento y competitividad mercadotécnica deben lanzar sun invenciones en el menor tiempo posible; seguirá así por mucho tiempo por no decir para siempre

¿Nadie ha nombrado GTK+? :rolleyes:

Ahora mismo consultando qué es eso. Lo he visto escrito varias veces, pero con el nombrecito que tiene me había dado algo de pereza investigar. :o

El problema es que comoquiera la estandarización por más esfuerzos que se hagan, existen diferentes criterios, diferentes visiones y hasta diferentes objetivos, para muestra

https://www.systeminside.net/por-que...fa-escritorio/

Observando esa libreria GTK+ es una muy buena iniciativa pero en este mundo donde hay tantos intereses es difícil hacer un mundo mejor.