loro-dev Mailing List for Loro - Un Sistema de Programación (Page 2)
Status: Beta
Brought to you by:
carueda
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(9) |
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(6) |
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(3) |
Oct
(4) |
Nov
(3) |
Dec
|
2003 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Carlos R. <ca...@cs...> - 2002-06-04 18:02:12
|
Una de las principales razones es canalizar la dependencia sobre JavaCC a traves de interfaces/clases propias para posibilitar tambien la utilizacion de otras herramientas sintacticas (antlr, sablecc, etc.) sin que se afecte el resto del sistema Loro. Notaras por ejemplo que todas las clases en el paquete loro.parsers.javacc NO aparecen en ninguna otra parte del sistema SALVO loro.parsers.javacc.DerivadorJavaCC que es la unica clase referenciada en loro.derivacion.ManejadorDerivacion, ya que este manejador es quien decide CUAL derivador particular utilizar y lo pone a disposicion a traves de la interface IDerivador. En un futuro podrian aparecer otros derivadores, digamos los paquetes: loro.parsers.sablecc.*; loro.parsers.antlr.*; aunque esto no esta entre las prioridades. Salvo por una leve dependencia en la implementacion de Rango.obtPos() (que se corregira en una proxima version) el esquema descrito arriba esta logrado completamente y se constituye uno de las principales caracteristicas de modularidad de Loro. Pero esta clase tiene justificacion por si misma: representa el segmento (rango) de codigo fuente asociado a cada nodo del arbol sintactico. No solo sirve para ubicar un error de compilacion o ejecucion, sino que tambien permitira resaltar el codigo correspondiente en un modo de ejecucion paso-a-paso para fines de depuracion y ayudar a establecer "break points". En todo caso tu observacion nos recuerda que aun hay mucho por actualizar en la documentacion del codigo. Gracias! On Mon, 3 Jun 2002, Marcos Diaz Molk wrote: > Buenas, me gustaria entender un poco para que sirve la clase > Rango. Si se utilizaa para control de errores, no seria mejor > utilizar las propias clases que te da JavaCC |
From: Carlos R. <ca...@cs...> - 2002-06-04 17:58:50
|
---------- Forwarded message ---------- Date: Mon, 3 Jun 2002 22:34:57 +0200 From: mo...@ms... Buenas, me gustaria entender un poco para que sirve la clase Rango. Si se utiliza para control de errores, no seria mejor utilizar las propias clases que te da JavaCC |
From: Carlos R. <ca...@cs...> - 2002-04-09 05:42:45
|
No es un bug propiamente: lo que se quiere es mostrar la pila de ejecucion vigente cuando se hace el llamado a terminarEjecucion(cod), lo cual se toma como una *terminacion INTERNA* (no *externa* como se muestra en el reporte --creo que hubo un error de transcripcion o era un error de una version anterior). Recuerdese que nuestro contexto es el de aprendizaje de la programacion, y toda esta informacion puede ser valiosa para el estudiante para saber lo que esta sucediendo. En todo caso, quiza convenga que terminarEjecucion(cod) termine "silenciosamente": al fin y al cabo es una terminacion *voluntaria* (o sea, programada explicitamente --por eso el nombre "interna"); y mas bien agregar un nuevo proceso concretamente para fines de depuracion que muestre la pila de ejecucion (como el abort() de C). Mas comentarios seran bienvenidos ;^) On Mon, 8 Apr 2002, Marlon J. Manrique wrote: > /* > Al realizar el llamado al algoritmo terminarEjecucion se > produce un error de ejecucion */ >=20 > especificacion terminar() > descripcion "Al momento de invocar el algoritmo terminarEjecucion del > paquete loroI::sistema > se produce un error de ejecucion" > fin especificacion >=20 > algoritmo para terminar() > estrategia "Invocar el algoritmo terminarEjecucion del paquete > loroI::sistema > con el codigo de terminacion 0" > inicio > terminarEjecucion(0); > fin algoritmo >=20 > /* Error reportado : >=20 > Hubo error en ejecuci=F3n >=20 > Terminacion externa >=20 > en algoritmo loroI::sistema::terminarEjecucion(cod:entero) (:90) > en algoritmo terminar() (terminar.loro:109) > */ >=20 >=20 >=20 > _______________________________________________ > Loro-dev mailing list > Lor...@li... > https://lists.sourceforge.net/lists/listinfo/loro-dev >=20 > Sponsored by http://www.ThinkGeek.com/ >=20 >=20 Carlos Rueda Postgraduate Researcher Center for Spatial Technologies and Remote Sensing, CSTARS Department of Land, Air, and Water Resources, LAWR University of California Davis, CA 95616 =20 (530) 752-5092 FAX: (530) 752-5262 http://www.cstars.ucdavis.edu |
From: Marlon J. M. <ma...@si...> - 2002-04-08 23:10:07
|
/* Al realizar el llamado al algoritmo terminarEjecucion se produce un error de ejecucion */ especificacion terminar() descripcion "Al momento de invocar el algoritmo terminarEjecucion del paquete loroI::sistema se produce un error de ejecucion" fin especificacion algoritmo para terminar() estrategia "Invocar el algoritmo terminarEjecucion del paquete loroI::sistema con el codigo de terminacion 0" inicio terminarEjecucion(0); fin algoritmo /* Error reportado : Hubo error en ejecuci=F3n Terminacion externa en algoritmo loroI::sistema::terminarEjecucion(cod:entero) (:90) en algoritmo terminar() (terminar.loro:109) */ |
From: <ca...@uc...> - 2002-04-04 23:22:19
|
Debido a un cambio interno (proveniente del pasado "refactoring"), se registra ahora la posicion absoluta (contando caracteres) en que ocurre el error, y no el numero de linea. Esto esta bien para control interno, pero desde luego hay que volver a mostrar la linea (y la columna) para facilitar la inspeccion por parte del usuario cuando no esta utilizando el EDI. (La mayoria de los editores tienen la opcion de "ir a una linea" y no la de "ir a un caracter" ;^). Gracias por el aviso; se dara alta prioridad a este ajuste. ----------------------------------------------------------------------- especificacion bug_linea() descripcion "Si ocurre un error en ejecucion la linea suministrada como causa de error dista de ser esa" fin especificacion algoritmo para bug_linea() estrategia "Provocar cualquier error, en este caso un indice de arreglo fuera de rango" inicio i : entero := 0; a : []entero := crear [0]entero; a[i]; fin algoritmo /** En este caso el error se produce al tratar de acceder al arreglo en la linea 11 pero el interprete muestra el siguiente mensaje de error : Hubo error en ejecución Indice en arreglo fuera de rango: 0 Este es un arreglo vacio. en algoritmo bug_linea() (bug2.loro:329) */ |
From: Marlon J. M. <ma...@si...> - 2002-04-04 22:57:43
|
especificacion bug_linea() descripcion "Si ocurre un error en ejecucion la linea suministrada como causa de error dista de ser esa" fin especificacion algoritmo para bug_linea() estrategia "Provocar cualquier error, en este caso un indice de arreglo fuera de rango" inicio i : entero :=3D 0; a : []entero :=3D crear [0]entero; a[i]; fin algoritmo /** En este caso el error se produce al tratar de acceder al arreglo en la linea 11 pero el interprete muestra el siguiente mensaje de error : Hubo error en ejecuci=F3n Indice en arreglo fuera de rango: 0 Este es un arreglo vacio. en algoritmo bug_linea() (bug2.loro:329) */ |
From: Carlos R. <ca...@cs...> - 2002-04-04 20:19:04
|
Muchas gracias. Ha sido corregido en la version 0.7r9 (por publicarse). On Wed, 3 Apr 2002, Marlon J. Manrique wrote: > /** > El siguiente codigo muestra un bug que permite acceder a un atributo a > traves de el identificador de la clase >=20 > Este codigo compila, pero en el momento de ejecucion muestra un error > en ejecucion : >=20 > Hubo error en ejecuci=F3n (class java.lang.ClassCastException) > loro.arbol.NClase > java.lang.ClassCastException: loro.arbol.NClase > at > loro.ejecucion.LoroEjecutor.visitar(LoroEjecutor.java:1429) > at > loro.ejecucion.EjecutorTerminable.visitar(EjecutorTerminable.java:125) > at loro.arbol.NAsignacion.aceptar(NAsignacion.java:26) > at > loro.ejecucion.LoroEjecutor.visitar(LoroEjecutor.java:1338) > at > loro.ejecucion.EjecutorTerminable.visitar(EjecutorTerminable.java:116) > at loro.arbol.NAlgoritmo.aceptar(NAlgoritmo.java:47) > at > loro.ejecucion.LoroEjecutor.ejecutarAlgoritmo(LoroEjecutor.java:738) > at > loro.ejecucion.LoroEjecutor.ejecutarAlgoritmoArgumentosCadena(LoroEjecuto= r.java:884) >=20 > at > loro.impl.EjecutorImpl.ejecutarAlgoritmoArgumentosCadena(EjecutorImpl.jav= a:69) >=20 > at loroedi.HiloAlgoritmo.run(HiloAlgoritmo.java:63) > */ >=20 > clase MiClase > descripcion "Una clase" > atributo : entero : "Un atributo"; > fin clase >=20 > especificacion bug_clase() > descripcion "Se puede llamar un atributo de una clase como si este fuera > estatico" > fin especificacion >=20 > algoritmo para bug_clase() > estrategia "Crear una clase y acceder al atributo a traves de la > instancia y la clase " > inicio > miClase : MiClase :=3D crear MiClase; > miClase.atributo :=3D 0; > MiClase.atributo :=3D 0; > fin algoritmo >=20 |
From: Marlon J. M. <ma...@si...> - 2002-04-04 02:36:36
|
/** El siguiente codigo muestra un bug que permite acceder a un atributo a traves de el identificador de la clase Este codigo compila, pero en el momento de ejecucion muestra un error en ejecucion : Hubo error en ejecuci=F3n (class java.lang.ClassCastException) loro.arbol.NClase java.lang.ClassCastException: loro.arbol.NClase at loro.ejecucion.LoroEjecutor.visitar(LoroEjecutor.java:1429) at loro.ejecucion.EjecutorTerminable.visitar(EjecutorTerminable.java:125) at loro.arbol.NAsignacion.aceptar(NAsignacion.java:26) at loro.ejecucion.LoroEjecutor.visitar(LoroEjecutor.java:1338) at loro.ejecucion.EjecutorTerminable.visitar(EjecutorTerminable.java:116) at loro.arbol.NAlgoritmo.aceptar(NAlgoritmo.java:47) at loro.ejecucion.LoroEjecutor.ejecutarAlgoritmo(LoroEjecutor.java:738) at loro.ejecucion.LoroEjecutor.ejecutarAlgoritmoArgumentosCadena(LoroEjecuto= r.java:884) at loro.impl.EjecutorImpl.ejecutarAlgoritmoArgumentosCadena(EjecutorImpl.jav= a:69) at loroedi.HiloAlgoritmo.run(HiloAlgoritmo.java:63) */ clase MiClase descripcion "Una clase" atributo : entero : "Un atributo"; fin clase especificacion bug_clase() descripcion "Se puede llamar un atributo de una clase como si este fuera estatico" fin especificacion algoritmo para bug_clase() estrategia "Crear una clase y acceder al atributo a traves de la instancia y la clase " inicio miClase : MiClase :=3D crear MiClase; miClase.atributo :=3D 0; MiClase.atributo :=3D 0; fin algoritmo |
From: Carlos R. <ca...@cs...> - 2002-03-25 22:06:48
|
Bienvenido adrian15! Veamos: > En principio me apunto en esta lista para estar al d=EDa del desarrollo d= e Loro y=20 > enterarme un poco m=E1s de como funciona en general, cual es su estructur= a.=20 >=20 > Adem=E1s me gustar=EDa colaborar como cr=EDtico de la p=E1gina web de Lor= o aportando=20 > ideas (Antes lo hac=EDa directamente a carueda, ahora lo har=E9 en esta l= ista). >=20 > No obstante tengo algunas: > Preguntas referentes al c=F3digo fuente: >=20 > Me he bajado el loro-edi-src-0.7r7-20020321.zip >=20 > y me he fijado en el archivo LoroTokenMarker.java del directorio > \src\loroedi\jedit >=20 > Quisiera hacer una objecci=F3n a como se definen los tokens. Se definen= =20 > directamente por medio de string, y no a trav=E9s de constantes string co= mo me=20 > parece que deber=EDa ser. Adem=E1s esos tokens, (los nombres de los token= s) se=20 > podr=EDan conseguir a trav=E9s de un archivo de texto llamado tokens.txt.= Esto=20 > facilitar=EDa a la larga el poder traducir el loro a otros idiomas: ingl= =E9s,=20 > franc=E9s, etc. De acuerdo totalmente contigo. Pero dejame aclarar: Para el resaltado (coloreamiento) de sintaxis se utiliza codigo del excelente editor jEdit (http://jedit.org). Bueno, en realidad parte de una version anterior de tal sistema que no estaba aun muy madura y por lo tanto sufre de algunos inconvenientes como el que mencionas. Con LoroTokenMarker.java me he limitado a seguir ese esquema pero solo como una solucion transitoria porque, como tu lo dices, es importante que haya flexibilidad para acoplar la herramienta a otros idiomas. Actualmente hay una actualizacion del modulo de sintaxis del jEdit para que esto se defina a traves de archivos XML, pero por falta de tiempo (y por atacar otras prioridades) se ha aplazado este aspecto. > Ahora bien si me voy a: > : [SourceForge] / loro / loro / src / loro / parser / LoroIParser.java=20 >=20 > Veo que usais constantes... as=ED que no s=E9 si lo haceis bien, =BFAcaso= en=20 > LoroTokenMarker al pasar los tokens luego los convierte en constantes? LoroIParser.java es *generado*, no editado a mano. Este archivo (fichero) proviene de LoroIParser.jj que es en donde se especifica la gramatica de Loro para efectos de utilzar la herramienta de generacion de analizadores lexicos y sintacticos JavaCC (http://www.webgain.com/products/java_cc/) > Repito que hago hincapi=E9 en lo de los tokens por lo de la traducci=F3n. de acuerdo; en este caso el asunto se atacaria desde el .jj > > Tengo m=E1s dudas porque no s=E9 si el zip que me he bajado es el bueno..= =2E si=20 > quizas con bajarme el nucleo ya estaba. Pero no el nucleo, a primera vist= a, no=20 > est=E1 incluido en el archivo del edi (que pone sistema completa). LoroEDI incluye el nucleo a nivel de binarios. Para los fuentes hay que bajar lo disponible para el nucleo. (La idea es mantener una cierta separacion logica --claro, hasta donde sea practico.) pero=20 tienes razon, pondre una aclaracion al respecto. > Ya me confirmareis este punto si es verdad o no porque no estoy muy segur= o. >=20 > Le he echado un vistazo al zip del nucleo, y concretamente a: >=20 > \src\loro\parsers\javacc\ > LoroIParser.java > Y veo cosas como: > jj_consume_token(78); > =F3 > jj_la1[7] =3D jj_gen; > A ese metodo le pasan un n=FAmero directamente sin ser una constante... y= no s=E9=20 > si es que est=E1 mal hecho, o es que no s=E9 puede hacer de otra manera. explicado mas arriba. (en general, los arhivos *generados automaticamente* no suelen ser legibles para los humanos). > Nada m=E1s, por el momento, si veis que no tengo ni idea, y pregunto cosa= s muy=20 > simples. Pues s=ED es verdad. Pero poco a poco, si me aclarais las ideas,= quizas=20 > podr=E9 entender el source del loro un poco mejor y encima ayudar un poco= m=E1s. perfecto! y no te preocupes: en informatica las preguntas mas simples no pocas veces resultan ser las mas profundas ;^) Asi que adelante y=20 gracias por tu participacion! >=20 > adrian15. >=20 |
From: <bea...@go...> - 2002-03-25 10:00:46
|
Hola Carueda, y compañia, En principio me apunto en esta lista para estar al día del desarrollo de Loro y enterarme un poco más de como funciona en general, cual es su estructura. Además me gustaría colaborar como crítico de la página web de Loro aportando ideas (Antes lo hacía directamente a carueda, ahora lo haré en esta lista). No obstante tengo algunas: Preguntas referentes al código fuente: Me he bajado el loro-edi-src-0.7r7-20020321.zip y me he fijado en el archivo LoroTokenMarker.java del directorio \src\loroedi\jedit Quisiera hacer una objección a como se definen los tokens. Se definen directamente por medio de string, y no a través de constantes string como me parece que debería ser. Además esos tokens, (los nombres de los tokens) se podrían conseguir a través de un archivo de texto llamado tokens.txt. Esto facilitaría a la larga el poder traducir el loro a otros idiomas: inglés, francés, etc. Ahora bien si me voy a: : [SourceForge] / loro / loro / src / loro / parser / LoroIParser.java Veo que usais constantes... así que no sé si lo haceis bien, ¿Acaso en LoroTokenMarker al pasar los tokens luego los convierte en constantes? Repito que hago hincapié en lo de los tokens por lo de la traducción. Tengo más dudas porque no sé si el zip que me he bajado es el bueno... si quizas con bajarme el nucleo ya estaba. Pero no el nucleo, a primera vista, no está incluido en el archivo del edi (que pone sistema completa). Ya me confirmareis este punto si es verdad o no porque no estoy muy seguro. Le he echado un vistazo al zip del nucleo, y concretamente a: \src\loro\parsers\javacc\ LoroIParser.java Y veo cosas como: jj_consume_token(78); ó jj_la1[7] = jj_gen; A ese metodo le pasan un número directamente sin ser una constante... y no sé si es que está mal hecho, o es que no sé puede hacer de otra manera. Nada más, por el momento, si veis que no tengo ni idea, y pregunto cosas muy simples. Pues sí es verdad. Pero poco a poco, si me aclarais las ideas, quizas podré entender el source del loro un poco mejor y encima ayudar un poco más. adrian15. --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ |
From: Carlos R. <ca...@uc...> - 2002-03-06 02:03:39
|
Por fin le hice una version mas decente a la herramienta con la que estoy haciendo actualmente el instalador para Loro. De pronto puede ser de su interes (quiza no tanto para uso propiamente, pero mas por sus cosas internas -que no son muchas- como classloaders, zip/jar files, properties, tipico build.xml para jakarta ant, etc.). Si hasta le echan una ensayada me cuentan (si es que tienen tiempo). ;^) http://sourceforge.net/project/showfiles.php?group_id=16016 El propio instalador nanoinstaller-0.5.jar es < 40K y trae todos los fuentes. |
From: Carlos R. <ca...@uc...> - 2002-02-22 18:23:02
|
bueno, casi! depende ahora de las pruebas ;-) He hecho varios cambios internos importantes (externamente la interface al usuario es practicamente la misma). El mas importante es la separacion del nucleo del sistema Loro (con todos los servicios basicos de compilacion, ejecucion, documentacion, etc.) de la GUI o entorno de desarrollo integrado para el usuario final, LoroEDI. Loro: Al interior del nucleo ha habido cambios importantes buscando siempre una mejor modularizacion. Por ejemplo, se ha abstraido una interface IDerivador para la construccion del arbol sintactico. La implementacion disponible sigue siendo sobre JavaCC, pero ahora es posible otras implementaciones (ANTLR, SableCC, etc.) sin mayores resonancias en el resto del sistema. Incluye las herramientas de linea de comando (compilador, ejecutor, documentador, etc.) aunque solamente he revisado ultimamente el compilador. Desde luego, este nucleo se puede utilizar de manera independiente. Lo pondre en SF prontamente. LoroEDI: Este viene siendo un cliente del nucleo Loro para ofrecer el entorno grafico de desarrollo. Tambien he hecho una reestructuracion importante aqui aunque de seguro faltan muchas afinaciones. hasta la proxima. |
From: Carlos A R. <ca...@cs...> - 2001-10-15 22:18:11
|
Loro 0.699 - Interprete Interactivo Mejorado http://loro.sf.net/app/ http://loro.sf.net/app/DEVNOTES.txt FAVOR NOTIFICAR OBSERVACIONES. GRACIAS. |
From: Carlos R. <ca...@cs...> - 2001-10-08 02:47:29
|
Loro 0.69 - Ahora con Interprete Interactivo Version inicial (sin sofisticacion visual por ahora) para escribir y ejecutar acciones (instrucciones) en el lenguaje de manera interactiva. Escriba el meta-comando (empieza con punto) .? para conocer otros metacomandos disponibles. http://loro.sourceforge.net/app/ http://loro.sourceforge.net/app/DEVNOTES.txt FAVOR NOTIFICAR OBSERVACIONES. GRACIAS. |
From: Carlos R. <ca...@cs...> - 2001-09-22 00:41:39
|
Como una primera exploracion para el tema de hilos, se ha hecho el algoritmo lorox::hilos::lanzar(alg: algoritmo) que simplemente abre una nueva ventana de ejecucion (similar a la estandar) y alli ejecuta el algoritmo dado (el cual puede ser para cualquier especificacion) retornando inmediatamente a quien lo llama. Esto es solo un ensayo, ya que no incorpora lo que se asocia a manejo de hilos propiamente dicho (este manejo deberia incluir el control de hilos asociados al "mismo" programa Loro, por ejemplo, para saber desde codigo Loro que hilos estan vivos, hacer comunicacion entre hilos, sincronizacion, y todo lo acostumbrado). Si desea probar esta extension, aqui se adjunta lo siguiente: lxhilos.lar - Unidades Loro lxhilos.jar - Clases Java de apoyo prj_lxhilos.tgz - Todo el proyecto Ponga lxhilos.[jl]ar en DIR/lib/ext/ (donde DIR es el directorio en donde esta instalado Loro), y reinicie el EDI. prj_lxhilos.tgz incluye un programa de prueba. Con esto tambien se prueba el mecanismo de extension de Loro que, desde la version 0.68, incluye la generacion automatica de la documentacion. |
From: Carlos R. <ca...@cs...> - 2001-09-22 00:24:21
|
Loro 0.68 -Correccion de anomalias detectadas -Modificacion de gramatica de clases (para mejor documentacion) -Generacion automatica de documentacion para extensiones Mas detalles es: http://loro.sourceforge.net/app/DEVNOTES.txt http://loro.sourceforge.net/app/ Ya que ha habido modificaciones en algunos puntos criticos del compilador, es vital su retroalimentacion: MUCHAS GRACIAS POR SUS OBSERVACIONES. |
From: Carlos R. <ca...@cs...> - 2001-09-18 19:33:33
|
> Hasta el momento se han realizado pruebas satisfactorias del EDI y la > generacion automatica de la documentacion. OK. Creo que con lo que tiene ahora el manejo de la documentacion se puede trabajar por un buen tiempo (salvo por la documentacion para paquetes): hay otros aspectos ahora mas prioritarios ahora. > Se han tenido dos problemas : > > 1. Al tratar de convertir un algoritmo representado por una clase en > java el ejecutor verifica que el algoritmo sea una instancia de > NAlgoritmo; el ejecutor deberia tambien verificar si es una instancia de > LAlgoritmo. Claro! Se acaba de hacer lo siguiente (extraido del fuente): // Aqui viene la consideracion de LAlgoritmo: else if ( val instanceof LAlgoritmo ) { // 2001-09-17 // OJO: La idea seria hacer la misma revision que se // hace con NAlgoritmo: que haya compatibilidad en cuanto // a la especificacion correspondiente. PERO actualmente // LAlgoritmo no incluye esta funcionalidad. // La reestructuracion necesaria en este sentido sigue // pendiente (espero que para un futuro cercano). // Por ahora, simplemente acepte las cosas; // retorne el mismo val: return val; } > > 2. Se compilo un algoritmo que recibe dos cadenas, despues de la > compilacion el EDI no mostraba la posibilidad de ejecutar este > algoritmo. Era BUG: solo se miraba que fuera tipo basico y las cadenas no entran en esta categoria. CORREGIDO y probado. > Tambien se probo el comando loroc.bat el cual funciono perfectamente! Muy bien! > Estas pruebas se realizaron bajo el sistema operativo Windows 98. Muchas gracias por la revision!! |
From: Carlos R. <ca...@cs...> - 2001-09-18 19:27:16
|
oh, si es lor...@li... (lo siento). "Marlon J. Manrique" wrote: > > Carlos Rueda wrote: > > > Lo de multihilos en Loro no se ha contemplado por ahora, bajo el > > supuesto (quizas equivocado) de que es un tema "avanzado" con respecto a > > los > > alcances del nivel I de Loro. Sin embargo, ahora que lo mencionas, creo > > que podria abrirse una discusion al respecto (pero mejor a traves de > > mailto:lor...@li..., que es la lista de definicion del > > lenguaje, ya que este tema involucraria la adicion de los elementos > > sintacticos de soporte correspondientes. Dependiendo de la ideas que > > maduremos en aquella lista, podriamos plantear una "implementacion de > > referencia" cuyos detalles, de nuevo, seguiriamos discutiendo en esta > > lista de desarrollo. > > Ok, enviare el asunto a la lista lor...@li... ya que > aparentemente no existe la lista lor...@li... > > _______________________________________________ > Loro-dev mailing list > Lor...@li... > https://lists.sourceforge.net/lists/listinfo/loro-dev |
From: Marlon J. M. <ma...@ex...> - 2001-09-18 18:26:18
|
Hasta el momento se han realizado pruebas satisfactorias del EDI y la generacion automatica de la documentacion. Se han tenido dos problemas : 1. Al tratar de convertir un algoritmo representado por una clase en java el ejecutor verifica que el algoritmo sea una instancia de NAlgoritmo; el ejecutor deberia tambien verificar si es una instancia de LAlgoritmo. 2. Se compilo un algoritmo que recibe dos cadenas, despues de la compilacion el EDI no mostraba la posibilidad de ejecutar este algoritmo. Tambien se probo el comando loroc.bat el cual funciono perfectamente! Estas pruebas se realizaron bajo el sistema operativo Windows 98. |
From: Marlon J. M. <ma...@ex...> - 2001-09-18 18:08:49
|
Carlos Rueda wrote: > Lo de multihilos en Loro no se ha contemplado por ahora, bajo el > supuesto (quizas equivocado) de que es un tema "avanzado" con respecto a > los > alcances del nivel I de Loro. Sin embargo, ahora que lo mencionas, creo > que podria abrirse una discusion al respecto (pero mejor a traves de > mailto:lor...@li..., que es la lista de definicion del > lenguaje, ya que este tema involucraria la adicion de los elementos > sintacticos de soporte correspondientes. Dependiendo de la ideas que > maduremos en aquella lista, podriamos plantear una "implementacion de > referencia" cuyos detalles, de nuevo, seguiriamos discutiendo en esta > lista de desarrollo. Ok, enviare el asunto a la lista lor...@li... ya que aparentemente no existe la lista lor...@li... |
From: Carlos R. <ca...@cs...> - 2001-09-18 17:10:22
|
"Marlon J. Manrique" wrote: >=20 > La necesidad de permitir a una aplicacion Loro el manejar multitarea es > inminente. >=20 > Esta el nucleo de Loro preparado para esto o se necesita un redise=F1o > para agregar esta carateristica? > Que mecanismo se podrian utilizar para permitir a aplicativos escritos > en Loro ser multitarea? Lo de multihilos en Loro no se ha contemplado por ahora, bajo el supuesto (quizas equivocado) de que es un tema "avanzado" con respecto a los alcances del nivel I de Loro. Sin embargo, ahora que lo mencionas, creo=20 que podria abrirse una discusion al respecto (pero mejor a traves de mailto:lor...@li..., que es la lista de definicion del=20 lenguaje, ya que este tema involucraria la adicion de los elementos sintacticos de soporte correspondientes. Dependiendo de la ideas que maduremos en aquella lista, podriamos plantear una "implementacion de=20 referencia" cuyos detalles, de nuevo, seguiriamos discutiendo en esta lista de desarrollo. |
From: Marlon J. M. <ma...@si...> - 2001-09-18 01:57:32
|
La necesidad de permitir a una aplicacion Loro el manejar multitarea es inminente. Esta el nucleo de Loro preparado para esto o se necesita un redise=F1o para agregar esta carateristica? Que mecanismo se podrian utilizar para permitir a aplicativos escritos en Loro ser multitarea? |
From: Carlos R. <ca...@cs...> - 2001-09-15 01:42:52
|
Loro 0.67 - http://loro.sourceforge.net/app/DEVNOTES.txt http://loro.sourceforge.net/app/ URGE REVISION. MUCHAS GRACIAS. |
From: Carlos R. <ca...@cs...> - 2001-08-30 23:30:27
|
Early Access: Loro 0.65 - loroc Ant Task, loro sources compilation, minor fixes http://loro.sourceforge.net/app/ Notas de los cambios en: http://loro.sourceforge.net/app/DEVNOTES.txt ESPERANDO OBSERVACIONES. GRACIAS. |
From: Carlos R. <ca...@cs...> - 2001-08-27 16:30:01
|
oops! gracias. Corregido. "Marlon J. Manrique" wrote: > > En la pagina http://loro.sourceforge.net/app/ en los enlaces para > obtener la vesion 0.63 > al solicitar : > > instalar-loroI-063.jar > instalar-loroI-063.jar.zip > > No se encuentran los archivos > > _______________________________________________ > Loro-dev mailing list > Lor...@li... > http://lists.sourceforge.net/lists/listinfo/loro-dev |