Bueno, como ya os comenté en la entrada anterior, hablamos y hablaremos sobre Windows 8 y su orientación a los Tablet en este blog.
Por lo tanto, la entrada del título la podéis leer aquí.
Bueno, como ya os comenté en la entrada anterior, hablamos y hablaremos sobre Windows 8 y su orientación a los Tablet en este blog.
Por lo tanto, la entrada del título la podéis leer aquí.
Ya sabéis que me gusta meter baza en los nuevos productos de Microsoft más que a un pollo la mierda. No creo que os pille de sorpresa, pero en este caso estamos hablando de caviar Beluga ya que encima tenemos dominio y web propia.
Sí, lo que leéis, el RFOG ha sido invitado a participar en un blog de temática exclusiva sobre Windows 8 y su orientación hacia los Tablet. Sin restricción de temática, sin censura y con libertad total de publicar lo que quiera (no, que no se os abran los ojos como platos, de momento no voy a poner porno).
Bueno, después de la presentación chula, vienen los detalles. Nos hemos juntado cuatro interfectos de entre los indeseables de la internet y que encima somos granos en el culo de las grandes corporaciones y nos hemos decidido a poner los puntos sobre las íes en el tópico descrito más arriba. La idea fue originalmente de Juan Luis Chulilla, quien la propuso a Ctitanic y a mi. No hace falta decir que tardamos 100 milisegundos en decir que sí, que es el tiempo medio de reacción entre el ojo y el cerebro (para aquellos que tengan neuronas, claro). Luego se nos unió Mahjong, y así formamos el cuarteto concertante (la referencia es de Verne).
Dicho y hecho, sólo faltaba arremangarse y empezar a escribir, así que el sitio ya contiene entradas chulas, aunque todavía anda algo en obras y debéis poneos casco no sea que se os caiga algún ladrillo en la cocorota.
Para aquellos que todavía estéis en Babia, os comento. Windows 8 es la siguiente versión de Windows 7, y viene en modo dual. Es decir, que trae dosShell de usuario. La primera es la que todos ya conocemos, con su menú inicio, su explorador y su Internet Explorer, con las mejoras pertinentes. Lo pongo en cursiva porque hay mucha gente a la que la Ribbon en el Explorador no les mola nada… a mí sí.
La segunda interfaz se llama Metro y está destinada a los Tablet, sean del tipo que sean. Si habéis visto Windows Phone ya tenéis una idea de qué es. Como siempre con las tecnologías de Microsoft, debajo hay más de lo que parece, y también ahora ocurre así.
A simple vista Metro parece nada más que una interfaz de apretar botones, pero dentro existe un motor basado en DirectX muy potente e interesante, envuelto en una capa que se programa con C# y una variante de C++/CLI. Y no es .NET, es nativa. De esto os contaré más aquí, pero en otro momento.
Finalmente también hay una preview de la siguiente versión de Visual Studio que es capaz de generar ejecutables para esta nueva plataforma, y de esto también hablaré por aquí.
Bueno, lo dicho, daos una vuelta por WinTablet.info.
Microsoft ya está planeando y compilando la siguiente versión de Visual Studio, que ellos han llamado temporalmente vNext o, recientemente, 2011, para indicarnos que se trata de la siguiente versión. No hay nada definitivo, ni fecha de salida ni qué va a traer, pero haciendo un poco de gurú, y teniendo en cuenta el ciclo bianual de salida, posiblemente tengamos algo el año que viene por estas fechas o un poco antes. Y no, no estoy haciendo uso de ninguna información privilegiada, que últimamente a los MVP nos dicen lo mismo que a los demás.
No obstante ya se empiezan a publicar algunas novedades sobre lo que va a traer. No son definitivas y quizás al final no las incluyan, pero tienen cosas bastante interesantes. Pese a referiros a los enlaces originales, os cuento yo aquí algunas cosillas. Iremos cronológicamente conforme han ido saliendo, ya que el interés también va en ese sentido.
Según Sumit Kumar, van a potenciarlo hasta el nivel de C# y más allá. Vamos a tener color para más elementos semánticos, de hecho hablan de hasta veinte tokens a los que podremos aplicar diferentes colores. Es decir, podremos distinguir a simple vista si un nombre es una variable local o global, una macro, una plantilla, un parámetro, un espacio de nombre, una enumeración… cosa que no está nada mal.
También habilitan la selección de una misma referencia en todo el código fuente. Es decir, cuando pongamos el cursor sobre un símbolo, dicho símbolo se selecciona en todo el texto.
También traerá un analizador heurístico en los desplegables, que se abrirán automáticamente y nos mostrarán los tipos más comunes y más probables pese a que empecemos a teclearlos mal.
Y, para equipararse a otros lenguajes, se añaden los Code Snippets, que son bloques de código listos para insertar.
Ne da un poco de corte explicar lo de arriba, porque todo eso ya lo hace Visual Assist de Whole Tomato… pero bien está que lo traiga de forma nativa… si funciona. Recordemos que no es la primera vez que el IntelliSense falla por completo en un producto de Microsoft. Esperemos que esta vez acierten a la primera.
Otra cosa que nos cuenta Sumit, y que personalmente yo no le veo mucho sentido, es que el Explorador de Soluciones traerá una vista de clases. Es decir, cuando abramos un fichero en dicha ventana, tendremos acceso a todas las clases y todos los símbolos de forma automática.
Si queréis ver las capturas de pantalla de todo lo que he explicado, haced clic en el enlace de arriba y veréis todo eso en marcha.
Amit Mohindra nos explica otras novedades en torno al IDE. La más destacable es que ahora no existe asistente para actualizar la solución. Es decir, si abrimos una solución escrita con Visual Studio 2008 o superior, no nos pedirá actualizarla y podremos usarla aprovechando las mejoras del nuevo IDE, y todavía podremos seguir abriéndola con la versión anterior.
Aquí surge un problema potencial, y es el uso de los nuevos compiladores. Es decir, imaginad que no tenemos instalado Visual Studio 2008 en la máquina en la que abrimos la solución pero sí Visual Studio vNext… Pues bien, existirá la forma de utilizar el nuevo compilador. Este tema está todavía pendiente de estudio, por lo que no está claro cómo lo van a hacer.
Otra cosa interesante va a ser la creación de plantillas de proyectos. En versiones anteriores había que crear una serie de ficheros bastante complicados de entender. Ahora esto podrá hacerse mediante un asistente. Aquí y aquí se explican algunas cosas más sobre esto.
Siguiendo con la lista de novedades, y conforme se van publicando en los blogs de Microsoft, ahora nos toca hablar de una característica que yo considero muy pero que muy potente en relación a la ejecución de código en paralelo.
Recientemente Microsoft ha sacado una biblioteca que ha dado en llamar C++AMP, y de la que podemos leer por aquí. Ignoro si forma parte de algún estándar (lo siento, ando un poco desactualizadillo en estos temas), pero creo que sí, al menos en su especificación si no en la implementación. Las siglas se conocen como Accelerated Massive Parallelism, y tiene que ver con los procesadores de uso generl multinúcleo y los vectoriales SIMD (de los cuales forman parte los chips de las tarjetas de vídeo modernas).
Evidentemente esto no sirve para un programa de gestión de datos, pero sí para juegos y otras aplicaciones que necesiten un rendimiento alto y que realicen tareas que se puedan ejecutar en paralelo. Digamos que es la solución que Microsoft está implementando en el mundo nativo (C++) como solución a los problemas actuales de paralelismo, y personalmente no lo veo nada mal.
Pues bien, DanielMoth nos cuenta que en vNext tendremos una nueva palabra reservada llamada restrict y que nada tiene que ver con su equivalente de C99, que MS no implementa. Básicamente la idea es utilizar dicho término para indicar dónde se debe ejecutar un método, si en el procesador principal o en el SIMD (tarjeta de vídeo).
Es decir, si nosotros ponemos algo como
void myFunction(int a) restrict(cpu)
{
}
Le estamos diciendo al compilador que esta función deberá ser ejecutada por la CPU del sistema, mientras que si lo indicamos así:
void myFunction(int a) restrict(direct3d)
{
}
Estaremos indicando que eso se debe ejecutar en el procesador gráfico.
E incluso es posible algo como esto:
void myFunction(int a) restrict(direct3d, cpu) //o restrict(cpu, direct3d)
{
}
Que indica que se podrá o deberá ejecutar en ambos procesadores.
Lo chulo de esto es que se trata de una indicación transparente para el programador, y que debe ser la implementación la que se encargue de toda la martingala para que pueda ejecutarse en uno o en otro sitio.
También podremos sobrecargar el método, de forma que podríamos tener tres funciones idénticas pero con diferente restricción, de forma que sería el compilador y el motor de tiempo de ejecución el que decidiera qué y cómo ejecutar.
Toda una chulada.
De todos modos, esto está un poco en el aire, y todavía no tienen claro algunas partes de la implementación y cómo va a terminar funcionando, pero es una característica muy guapa. Ojalá implementen algo similar para los threads y la sincronización.
Otra cosa que sí han hecho es optimizar el PPL (otra librería de ejecución en paralelo, esta con algo más de solera), ganando en algunos casos hasta un 20% de mejoras en el rendimiento con sólo recompilar el código existente con la nueva implementación de PPL que traerá vNext. Aquí lo tenéis con más detalle.
Ya está aquí, ya ha llegado, la que prácticamente es la versión más mierdosa que jamás han sacado de C++Builder.
Pensaba que no se podía caer más bajo en ofrecer una versión de una herramienta de desarrollo, pero lo cierto es que sí, y se llama C++Builder XE2.
Ya estamos acostumbrados al ciclo de salida anuales de los productos de Embarcadero, con versión tras versión de un producto bastante inacabado y que sólo comienza a funcionar bien tras dos o tres parches, como es el caso de la última versión hasta ahora, la XE, que sólo ha comenzado a ser más o menos estable tras el Update 3, pero sin que solucionen bugs históricos como los que impiden trabajar con las versiones no parcheadas de Boost o que hacen casi inusables las que ofrecen parcheadas, eso sin contar con el pobre rendimiento de los ejecutables…
Pues bien, la única mejora destacable, y destacable de verdad, en C++Builder XE2, es que puede generar ejecutables para OS X. Sí, lo que leéis. Pero ¿vosotros habéis visto un ejecutable corriendo sobre OS X y compilado con esta herramienta? Si la respuesta es afirmativa es que sois bastante más suertudos que yo, porque, pese a tener la versión de prueba, no lo he conseguido.
El sistema de compilación cruzada funciona más o menos así:
Hay una nueva biblioteca visual que se llama FireMonkey y que es calcada a la VCL pero con la característica de que es multiplataforma, por lo que debéis olvidaros de simplemente recompilar vuestros anteriores proyectos. Hay que construirlos desde cero con esta nueva biblioteca. La ventaja es que los componentes se llaman casi igual y puede serte válido mucho código ya escrito.
Bueno, una vez que tienes instalada esta versión de Bulider, tienes que instalar una especie de servidor en el MAC donde vayas a depurar. Sí, C++Builder no se ejecuta dentro de un MAC, sino que sigue siendo una aplicación nativa Windows. Sí que puedes hacerlo desde una máquina virtual, pero ojo con la licencia de activación, que se suele perder cada cierto tiempo por algún problema con el sistema de ficheros, y tienes que reactivar el producto, y cuando llegas a cierto límite tienes que al menos enviar un correo explicando qué te pasa y por qué quieres más activaciones.
Una vez que tienes instalado y lanzado el servidor en tu MAC (tras leerte bastante documentación y tras varias pruebas en falso), tienes que añadir la plataforma en tu proyecto FireMonkey (nombre ridículo donde lo haya). Luego tienes que crear un perfil y asociarlo al proyecto. Y finalmente ejecutarlo.
Vale. Todo el tema del perfil y demás está hecho de aquella manera, con una especie de asistente mierdoso y con poca documentación, pero una vez lo tienes todo hecho… no te funcionará. Ni siquiera compilará.
¿Por qué? Muy sencillo: aparte del tema de la pérdida de la licencia, el IDE del RAD Studio no es compatible con carpetas compartidas de una máquina virtual. Igual que ocurre con Visual Studio, que parecen productos calcados…
Vale, tienes que tener tu proyecto en una carpeta local de la máquina virtual. Ahora sí que compila. Pero al lanzar el ejecutable, el lado servidor empieza a soltar error sobre error con librerías no instaladas, recursos faltantes y demás que hacen que, al menos yo, deje de mirar esta mierda de producto.
Lo dicho: si vais a comprar la versión de C++Builder porque genera ejecutables de plataforma cruzada, no lo hagáis hasta por lo menos la versión XE1000000000 o superior, porque simplemente da asquito.
Eso sin mencionar que la compilación tanto para Windows como para MAC es de 32 bits. Sí, lo dicho, C++Builder todavía no trae compilador de 64 bits (aunque Delphi XE2 sí que lo trae, pero no para OS X).
Vamos, lo dicho, una mierda pinchada en un palo.