... pero con un peligro: si no logro mover eficientemente el compilador a un dominio de aplicación paralelo y descargable, probablemente haya que reescribir la tabla de símbolos y el generador, para no usar reflexión. Lo del generador es sencillo, pues está muy aislado del resto del compilador, pero la tabla de símbolos es casi el compilador.
De todos modos, teniendo en cuenta el poco tiempo total invertido, estoy satisfecho. No es el lenguaje que me gustaría dejar como "testamento técnico", pero he aprendido unas cuantas cosas, que me serán muy útiles.
Por cierto, lo que sí estoy mirando, en relación con las "adiciones funcionales" a lenguajes imperativos, es intentar "elevar" el nivel de las declaraciones estructurales. Quiero decir: un LF usa mucho pattern matching, pero en un lenguaje imperativo, averiguar mucho sobre la "estructura" está mal visto, porque hasta cierto punto se carga la encapsulación. Y en todo caso, usar campos o incluso propiedades es una técnica de muy bajo nivel: hay que añadir "pegamento", casi siempre. ¿Habría una técnica de más alto nivel para crear "estructuras" con capacidad implícita de pattern matching? ¿Cuánto pegamento ahorraría?
... pero con un peligro: si no logro mover eficientemente el compilador a un dominio de aplicación paralelo y descargable, probablemente haya que reescribir la tabla de símbolos y el generador, para no usar reflexión.
No creo que tengas muchos problemas. No es demasiado complicado. Hay ejemplos en la Web que te dan todo hecho. Si no los encuentras te los busco.
Las llamadas entre domínios son lentísimas, pero tu vas a hacer muy pocas, así que te da igual.
Yo ya he encontrado una solución obvia a mis problemas con las clases: no usar las instrucciones de objetos del CIL y gestionar yo mismo la memoria a bajo nivel. Así tengo libertad total. Estaba equivocado pensando que no se podía.
¿Te has currado tu el editor?
Yo no he encontrado ningun editor Open Source que me convenza :(
Por cierto, lo que sí estoy mirando, en relación con las "adiciones funcionales" a lenguajes imperativos, es intentar "elevar" el nivel de las declaraciones estructurales. Quiero decir: un LF usa mucho pattern matching, pero en un lenguaje imperativo, averiguar mucho sobre la "estructura" está mal visto, porque hasta cierto punto se carga la encapsulación.
Yo aquí no tengo problema por que mi lenguaje es relacional y las relaciones tienen una estructura explícita. El álgebra relacional es de muy alto nivel.
No se si sabrás que una vez existió un Relational Lisp que daba resultados espectaculares en tiempos de desarrollo.
Sí, en un "rapto de inspiración" de tres días. Desde ese momento no lo he tocado, excepto para añadir alguna chorradita. No es lo que quisiera: tenía pensado montar un sistema model-view-controller, pero por miedo a la posible ineficiencia de .NET (luego vi que no), utilicé un "gap buffer" modificado para almacenar las líneas: las líneas van cada una en un string, pero se llega a ellas a través de un array. Y el array tiene la zona "libre" en el centro: a partir de la línea activa hay un "gap" y la última línea es siempre la última entrada del array. Es una porquería porque esto impide manejar más de una vista sobre el mismo código (como en VS, que puedes tener dos paneles abiertos en posiciones distintas del mismo fichero).
Pero en general, creo que se entiende el código. Si quieres, lo empaqueto y te lo mando. El editor acepta un "scanner" enchufable para descomponer en palabras, cadenas y esas cosas.
Ahora lo hubiera hecho diferente, pero es que han pasado dos años desde entonces, y ya tengo un poco más de confianza en .NET. Mi mayor preocupación era el "picadillo" de cadenas que se puede montar y cómo afectaría al garbage collector.
Por cierto, yo estuve viendo Scintilla, y el propio editor de SharpDevelop, pero me dio miedo el modelo de programación. En SharpDevelop dibujan cada carácter por separado (¡!), lo cual, probablemente, provoca que GDI+ cree cadenas innecesarias... aparte de que tienes que entrar y salir del controlador un millón de veces (¿conoces el viejo truco de agrupar el dibujo de líneas con PolyPolyLine?). Este editor, por el contrario, trocea sólo lo inevitable (por cambios en color). Lo que sí ocurre es que te obliga a usar tipos de letras monoespacio, pero no creo que sea grave (tengo por ahí también una DLLImport para averiguar eso desde .NET).
las líneas van cada una en un string, pero se llega a ellas a través de un array. Y el array tiene la zona "libre" en el centro: a partir de la línea activa hay un "gap" y la última línea es siempre la última entrada del array. Es una porquería porque esto impide manejar más de una vista sobre el mismo código (como en VS, que puedes tener dos paneles abiertos en posiciones distintas del mismo fichero).
Yo empecé a hacer un editor, pero por falta de tiempo lo tengo aparcado. El mío si es MCV inspirado en el de SharpDevelop.
Yo en vez de un array uso una lista que funciona como un B-Tree que había hecho para mi base de datos y va de coña.
Para la línea activa uso dos List char>. En uno está el trozo de la línea hasta el cursor y en el otro el resto al revés, lo típico.
Pero en general, creo que se entiende el código. Si quieres, lo empaqueto y te lo mando. El editor acepta un "scanner" enchufable para descomponer en palabras, cadenas y esas cosas.
Te estaría muy agradecido. Si consigo mejorarlo te paso los cambios, o mejor lo metemos en Codeplex o un sitios de esos.
Mi mayor preocupación era el "picadillo" de cadenas que se puede montar y cómo afectaría al garbage collector.
No creo que sea un problema.
En SharpDevelop dibujan cada carácter por separado (¡!), lo cual, probablemente, provoca que GDI+ cree cadenas innecesarias...
Si, el editor de SharpDevelop es muy lento. Si lo usas con un ordenador antiguo se nota bastante.
(¿conoces el viejo truco de agrupar el dibujo de líneas con PolyPolyLine?).
No, le echaré un vistazo.
Yo a lo más a lo que he llegado es a usar BitBlit para el scroll.
Lo que sí ocurre es que te obliga a usar tipos de letras monoespacio, pero no creo que sea grave (tengo por ahí también una DLLImport para averiguar eso desde .NET).
Yo empecé a hacerlo solo para monoespacio aunque lo dejé preparado para que en un futuro pudiese funcionar con cualquier fuente. Con monoespacio iría bastante más rápido.
Para averiguar si la fuente es monoespacio uso un procedimiento bastante artesanal: mido el ancho en pixels de la cadena "W" y lo comparo con el ancho de la cadena "i". Si es igual es que es monoespacio O:-)
Acabo de echarle un vistazo a mi editor abandonado y ya ni me acordaba de como iba. Las líneas van en un objeto Line que es un array de objetos Segment. Cada segmento es un trozo de línea con el mismo color y tipo de letra. Además el segmento almacena el ancho en pixels para que el repintado sea más rápido.
Tengo una clase para partir las lineas en segmentos según los parámetros típicos (keywords, comentarios y todo eso) y se puede heredar de ella para hacer lo que te de la gana con el formato.
A ver si consigo hacer un Frankenstein entre mi editor a medio hacer y el tuyo :-)
Querido Ian, soy el posteador de las erratas, y acabo de descubrir que las tienes hasta en el blog: Hilo 'espasa afilada', post numero 9, primera linea: donde dice 'curdo ADO.NET' debe decir 'curso ADO.NET' Todos somos humanos y tenemos los dedos lo suficientemente gordos para pulsar dos tecla a la vez.
Perdona, no te enfades. Era una broma "en familia". Si hubiese sido de otro tipo, no te lo habría dicho (¡pero no pasaría nada, todos metemos la gamba!), pero en este caso, además, era evidente que la D y la S están juntas en el teclado (y la B y la V, lo cuál es más puñetero). Mira cómo se te volvió a deslizar el dedo al escribir "espasa afilada" (no puede ser el diccionario enciclopédico tras afinar el filo: esas suelen ser armas contundentes, no cortantes).
Por favor, no lo tomes a mal. Un simple vistazo a mis "posts" revela muchos más errores de ese tipo... y de otros menos justificables. Y no creo que sea problema de "dedos gordos": es el mal diseño de los teclados de portátil y el problema histórico del puñetero diseño QWERTY (¿sabías que el teclado QWERTY se diseñó para disminuir la velocidad de tecleo y evitar los frecuentes atascos de tipos de las primeras mecanógrafas?).
No esperaba esta respuesta en absoluto, no me molestaste nada, al contrario, mi mensaje era una broma sobre la broma, 'sarcasmo' creo que se llama, suelo hacerlo y la gente que me conoce lo encuentra bastante gracioso, aunque es cierto que al releerlo ahora suena un poco 'resabiado' o molesto, no fue esa nunca mi intencion. Aunque tal vez tu mensaje sea tambien una broma de la broma sobre la broma y he sido yo el que ha picado ahora.
12 Comments:
Muy chulo
... pero con un peligro: si no logro mover eficientemente el compilador a un dominio de aplicación paralelo y descargable, probablemente haya que reescribir la tabla de símbolos y el generador, para no usar reflexión. Lo del generador es sencillo, pues está muy aislado del resto del compilador, pero la tabla de símbolos es casi el compilador.
De todos modos, teniendo en cuenta el poco tiempo total invertido, estoy satisfecho. No es el lenguaje que me gustaría dejar como "testamento técnico", pero he aprendido unas cuantas cosas, que me serán muy útiles.
Por cierto, lo que sí estoy mirando, en relación con las "adiciones funcionales" a lenguajes imperativos, es intentar "elevar" el nivel de las declaraciones estructurales. Quiero decir: un LF usa mucho pattern matching, pero en un lenguaje imperativo, averiguar mucho sobre la "estructura" está mal visto, porque hasta cierto punto se carga la encapsulación. Y en todo caso, usar campos o incluso propiedades es una técnica de muy bajo nivel: hay que añadir "pegamento", casi siempre. ¿Habría una técnica de más alto nivel para crear "estructuras" con capacidad implícita de pattern matching? ¿Cuánto pegamento ahorraría?
... pero con un peligro: si no logro mover eficientemente el compilador a un dominio de aplicación paralelo y descargable, probablemente haya que reescribir la tabla de símbolos y el generador, para no usar reflexión.
No creo que tengas muchos problemas. No es demasiado complicado. Hay ejemplos en la Web que te dan todo hecho. Si no los encuentras te los busco.
Las llamadas entre domínios son lentísimas, pero tu vas a hacer muy pocas, así que te da igual.
Yo ya he encontrado una solución obvia a mis problemas con las clases: no usar las instrucciones de objetos del CIL y gestionar yo mismo la memoria a bajo nivel. Así tengo libertad total. Estaba equivocado pensando que no se podía.
¿Te has currado tu el editor?
Yo no he encontrado ningun editor Open Source que me convenza :(
Por cierto, lo que sí estoy mirando, en relación con las "adiciones funcionales" a lenguajes imperativos, es intentar "elevar" el nivel de las declaraciones estructurales. Quiero decir: un LF usa mucho pattern matching, pero en un lenguaje imperativo, averiguar mucho sobre la "estructura" está mal visto, porque hasta cierto punto se carga la encapsulación.
Yo aquí no tengo problema por que mi lenguaje es relacional y las relaciones tienen una estructura explícita. El álgebra relacional es de muy alto nivel.
No se si sabrás que una vez existió un Relational Lisp que daba resultados espectaculares en tiempos de desarrollo.
HaskellvCjfp.pdf
¿Te has currado tu el editor?
Sí, en un "rapto de inspiración" de tres días. Desde ese momento no lo he tocado, excepto para añadir alguna chorradita. No es lo que quisiera: tenía pensado montar un sistema model-view-controller, pero por miedo a la posible ineficiencia de .NET (luego vi que no), utilicé un "gap buffer" modificado para almacenar las líneas: las líneas van cada una en un string, pero se llega a ellas a través de un array. Y el array tiene la zona "libre" en el centro: a partir de la línea activa hay un "gap" y la última línea es siempre la última entrada del array. Es una porquería porque esto impide manejar más de una vista sobre el mismo código (como en VS, que puedes tener dos paneles abiertos en posiciones distintas del mismo fichero).
Pero en general, creo que se entiende el código. Si quieres, lo empaqueto y te lo mando. El editor acepta un "scanner" enchufable para descomponer en palabras, cadenas y esas cosas.
Ahora lo hubiera hecho diferente, pero es que han pasado dos años desde entonces, y ya tengo un poco más de confianza en .NET. Mi mayor preocupación era el "picadillo" de cadenas que se puede montar y cómo afectaría al garbage collector.
Por cierto, yo estuve viendo Scintilla, y el propio editor de SharpDevelop, pero me dio miedo el modelo de programación. En SharpDevelop dibujan cada carácter por separado (¡!), lo cual, probablemente, provoca que GDI+ cree cadenas innecesarias... aparte de que tienes que entrar y salir del controlador un millón de veces (¿conoces el viejo truco de agrupar el dibujo de líneas con PolyPolyLine?). Este editor, por el contrario, trocea sólo lo inevitable (por cambios en color). Lo que sí ocurre es que te obliga a usar tipos de letras monoespacio, pero no creo que sea grave (tengo por ahí también una DLLImport para averiguar eso desde .NET).
las líneas van cada una en un string, pero se llega a ellas a través de un array. Y el array tiene la zona "libre" en el centro: a partir de la línea activa hay un "gap" y la última línea es siempre la última entrada del array. Es una porquería porque esto impide manejar más de una vista sobre el mismo código (como en VS, que puedes tener dos paneles abiertos en posiciones distintas del mismo fichero).
Yo empecé a hacer un editor, pero por falta de tiempo lo tengo aparcado. El mío si es MCV inspirado en el de SharpDevelop.
Yo en vez de un array uso una lista que funciona como un B-Tree que había hecho para mi base de datos y va de coña.
Para la línea activa uso dos List char>. En uno está el trozo de la línea hasta el cursor y en el otro el resto al revés, lo típico.
Pero en general, creo que se entiende el código. Si quieres, lo empaqueto y te lo mando. El editor acepta un "scanner" enchufable para descomponer en palabras, cadenas y esas cosas.
Te estaría muy agradecido. Si consigo mejorarlo te paso los cambios, o mejor lo metemos en Codeplex o un sitios de esos.
Mi mayor preocupación era el "picadillo" de cadenas que se puede montar y cómo afectaría al garbage collector.
No creo que sea un problema.
En SharpDevelop dibujan cada carácter por separado (¡!), lo cual, probablemente, provoca que GDI+ cree cadenas innecesarias...
Si, el editor de SharpDevelop es muy lento. Si lo usas con un ordenador antiguo se nota bastante.
(¿conoces el viejo truco de agrupar el dibujo de líneas con PolyPolyLine?).
No, le echaré un vistazo.
Yo a lo más a lo que he llegado es a usar BitBlit para el scroll.
Lo que sí ocurre es que te obliga a usar tipos de letras monoespacio, pero no creo que sea grave (tengo por ahí también una DLLImport para averiguar eso desde .NET).
Yo empecé a hacerlo solo para monoespacio aunque lo dejé preparado para que en un futuro pudiese funcionar con cualquier fuente. Con monoespacio iría bastante más rápido.
Para averiguar si la fuente es monoespacio uso un procedimiento bastante artesanal: mido el ancho en pixels de la cadena "W" y lo comparo con el ancho de la cadena "i". Si es igual es que es monoespacio O:-)
las líneas van cada una en un string,
Acabo de echarle un vistazo a mi editor abandonado y ya ni me acordaba de como iba. Las líneas van en un objeto Line que es un array de objetos Segment. Cada segmento es un trozo de línea con el mismo color y tipo de letra. Además el segmento almacena el ancho en pixels para que el repintado sea más rápido.
Tengo una clase para partir las lineas en segmentos según los parámetros típicos (keywords, comentarios y todo eso) y se puede heredar de ella para hacer lo que te de la gana con el formato.
A ver si consigo hacer un Frankenstein entre mi editor a medio hacer y el tuyo :-)
Fe de erratas:
curdo ADO.NET, Manual de ejercicios serie C, pagina 27, linea 4, donde dice ColumnID debe decir CustomerID.
Fe de erratas:
¡Recibido! Muchas gracias.
curdo ADO.NET
Hummm, ya se vende hasta en el Kurdistán :)
Querido Ian, soy el posteador de las erratas, y acabo de descubrir que las tienes hasta en el blog:
Hilo 'espasa afilada', post numero 9, primera linea: donde dice 'curdo ADO.NET' debe decir 'curso ADO.NET'
Todos somos humanos y tenemos los dedos lo suficientemente gordos para pulsar dos tecla a la vez.
Perdona, no te enfades. Era una broma "en familia". Si hubiese sido de otro tipo, no te lo habría dicho (¡pero no pasaría nada, todos metemos la gamba!), pero en este caso, además, era evidente que la D y la S están juntas en el teclado (y la B y la V, lo cuál es más puñetero). Mira cómo se te volvió a deslizar el dedo al escribir "espasa afilada" (no puede ser el diccionario enciclopédico tras afinar el filo: esas suelen ser armas contundentes, no cortantes).
Por favor, no lo tomes a mal. Un simple vistazo a mis "posts" revela muchos más errores de ese tipo... y de otros menos justificables. Y no creo que sea problema de "dedos gordos": es el mal diseño de los teclados de portátil y el problema histórico del puñetero diseño QWERTY (¿sabías que el teclado QWERTY se diseñó para disminuir la velocidad de tecleo y evitar los frecuentes atascos de tipos de las primeras mecanógrafas?).
No esperaba esta respuesta en absoluto, no me molestaste nada, al contrario, mi mensaje era una broma sobre la broma, 'sarcasmo' creo que se llama, suelo hacerlo y la gente que me conoce lo encuentra bastante gracioso, aunque es cierto que al releerlo ahora suena un poco 'resabiado' o molesto, no fue esa nunca mi intencion.
Aunque tal vez tu mensaje sea tambien una broma de la broma sobre la broma y he sido yo el que ha picado ahora.
Publicar un comentario
<< Home