Urge un depurador


([N1] aztecmexico) #1

Pues eso, me uuuuuuuurge un debugger en V7.

Todo el tiempo que gano desarrollando lo pierdo depurando, así de sencillo.

Vuelve la araña después de algunos años perdida, el caso es que tengo un desarrollo que para efectos de pruebas y optimización he montado en mi cloud de Velneo, el mismo tira de algunas dlls.

Al ejecutarlo desde Windows 8 funciona perfecto.

Al ejecutarlo desde Windows 7 el vClient rompe.

El equipo con windows 8 es nuevo, o sea, se le instalaron las librerías correspondientes que requiere el desarrollo, paquetes redistribuibles, las dlls en los directorios de 32 y 64 bits, en el cacherun del vclient, etc. y repito, ahí funciona de maravilla.

En el equipo con windows 7, mi principal equipo para el desarrollo truena como ejote.

He revisado las librerias, los paquetes, etc. todo bien.

Obviamente no es un problema del desarrollo en V7, de lo contrario imagino que tambien tronaría en W8, pero después de haber revisado TODO con checklist en ambos equipos la verdad ya me enfadé de no tener NADA que me ayude a ver por donde van los tiros.

El vAdmin pues en estos casos solo está de adorno, no cacha nada de nada, amén de que cuando cacha algo solo un grupo muy selecto lo puede descifrar.

Si tuvieramos un depurador que nos indicara por donde va la falla esto sería de mucho agradecer toda vez que evitariamos los costes inherentes a la pérdida de tiempo jugando al gato y al ratón, desinstalando, reiniciando, instalando, reiniciando paquetes, librerías, componentes y lo peor de todo, VOLVIENDO A TOCAR EL CÓDIGO QUE YA FUNCIONA pensando que la falla está ahí cuando no lo está.

De pura chiripa -casualidad- mi colega ejecutó el programa en su equipo con W8 y ahí fue que funcionó perfecto, de lo contrario su servidor hubiera comenzado por joder el código, los procesos, las funciones, sus definiciones de dll, los tipos de retornos de las funciones de dll, los objetos de los formularios, los menús, etc, etc, etc, etc.

Resumiendo, si, tengo un problema que en estricto y purista sentido no es de V7 sino de algún componente externo que utilizo, pero, demonios, o como diría Robin, ¡Chanclas diabólicas Batman! esto es obra del Acertijo.

Ya de menos implementar algo como el cachar, o atrapar las excepciones que usan en otras plataformas, para aislar el problema e irnos directamente sobre él, y no andar perdiendo valioso y costoso tiempo jugando a ciegas haber donde esta el problema.

Y ya no le sigo que ya es tarde, estoy cansado, enfadado y muy, muy, pero muy frustrado por no encontrar la falla, pero más por no tener ABSOLUTAMENTE nada que me ayude a ver la luz.

Saludos y excelente fín de semana a toda la comunidad, que sigue siendo una de las mejores, si no es que la mejor de todas las plataformas por las que he transitado.

Martin Ibarra.


([N3] pacosatu) #2

Hola Martín.

Comprendo tu cabreo y no quiero desilusionarte más, pero pinta muy negro el panorama.

  • En LifeIsSoft_2014 se confirmó que el proyecto del depurador se ha abandonado porque lo que se había hecho no sirve con QT 5.2.
  • La depuración en lenguajes de Script externos como Javascript nunca se va a dar porque Velneo no da soporte al código hecho con estos lenguajes, solo da soporte a problemas con el API.
  • La depuración en HTML lo mismo
  • La depuración en librerías externas (tipo DLL’s, …) por razones obvias es imposible y solo podrás depurar en la llamada y en la respuesta.

Ya me imagino que habrás exprimido todo lo posible vLogger para intentar poner un cepo en el lugar adecuado y atrapar el ratón travieso.

En cualquier caso un +1 para el depurador y además otro +1 para:

  • Una verdadera ayuda contextual en vDevelop, con Intellisense, tanto en código Velneo como en JavaScript. No os podéis ni imaginar la satisfacción que es pulsar sobre un comando en el código y que aparezcan inmediatamente toneladas de información en pantalla, en lugar de tener que hacer una penosa búsqueda por la Web.
  • Que se vaya planteando la Idea de hacer una ventana de comandos en la que podamos ejecutar desde vDevelop los objetos de Velneo (formularios, procesos, funciones, …) para probar que funcionan correctamente.
    Algo parecido a lo que hace vDataClient.

Saludos
Paco Satué


([N4] arturomiranda) #3

+1,000


([N4] Ramon Denuc) #4

Paco aquí tienes otro +1


([N1] aztecmexico) #5

Buen día a todos,

La Araña ha triunfado, bueno, a medias, pero ha solucionado el problema de momento cuando menos.

Por si les sirve de algo les comento la secuencia de hechos y acciones llevadas a cabo hasta -a ciegas casi, y prueba y error- solucionar el problema.

No era el código
No eran los objetos de V7
No eran las librerías
No eran los formularios, eventos, conexiones de eventos, etc.
No eran los paquetes redistribuibles de Visual C++XXXXXXXXX
No era ningún software de terceros instalado en mi máquina y que haya estado interfiriendo
No era YO

Era la caché de V7 para la máquina en cloud a la cual me conectaba.

Borré la cache en mi equipo de mi servidor de cloud de Velneo y al generarse de nueva cuenta al ejecutar la app ya funcionó perfectamente.

Nos dimos cuenta de eso porque instalamos la misma app en el cloud de otro colega, me conecté a dicho vServer para ejecutar la app y ahí si funcionó, deduciendo un poco caí en cuenta que el problema estaba en la propia cache de mi servidor cloud que se generaba en mi equipo.

Para evitar seguir perdiendo el tiempo la borré completa, nada me costaba únicamente borrar las dlls que cargo como adjuntos en mi aplicación, para que las volviera a grabar, en fín, ya todo funciona bien, el único costo pues 24 horas perdidas, muchas tazas de café, cigarros, una buena desvelada, y también mucho aprendizaje.

Paco, muchas gracias por tus comentarios y apoyo, los tomo en cuenta para futuras incidencias y desde aquí te comento que siempre leo con detenimiento tus reflexiones y aportaciones, toda vez que considero eres un excelente miembro y participante de este gran foro.

Un abrazo.

Martin Ibarra.


([N3] pacosatu) #6

Hola Martin.

Me alegro que se haya solucionado, pero con las prisas y los nervios te has olvidado de depurar la resolución del problema. Tendrías que haber hecho una copia de la carpeta de la caché e ir borrando uno a uno los ficheros de dicha carpeta. Con cada borrado ejecutarías la aplicación hasta que ésta funcionase correctamente y así averigüar el fichero culpable del fallo.

Sería interesante saber cómo Velneo decide que un fichero debe actualizarse en la caché del cliente. Imagina que una DLL se copia de forma incorrecta en la caché y Velneo no la actualiza. Este es el tipo de error que vDevelop no es capaz de detectar, pero con un comando TRY CATCH y la EXCEPCIÓN correspondiente, lo que tú has tardado 1 día en solucionar, se hubiera arreglado inmediatamente con un simple mensaje en la Excepción: “Ha ocurrido un error en la DLL …”.

Bueno, lo importante es que no era un problema del código de Velneo.

Saludos
Paco Satué


([N4] velavisual) #7

Hola,

Sin ánimo de generar conflicto alguno y tras la decisión de Martín de borrar la caché, he encontrado en vBugman una posible incidencia (que no es tal sino el comportamiento real en este caso) la número 001719 que habla de lo que se comenta en este post. Adjunto imagen de la misma y espero que al menos sepamos todos que debemos de borrar la caché por completo en caso de que sea necesario.



([N1] aztecmexico) #8

Hola Antonio,

Para nada generas conflicto, al contrario muy bueno tu punto y la revisión que hiciste del vBugman.

Al principio pensé en hacer lo que comenta Paco, pero por la prisa pues sin haber leido la indicencia del vBugman, borré la caché completa.

Ahora queda claro que de nada sirve perder el tiempo intentando aislar el elemento que ocasiona la falla si el vServer no lo va a enviar de nueva cuenta y nos vamos a quedar en las mismas.

Un saludo.

Martin Ibarra.


([N1] VictorMC) #9

Saludos Martín, Arturo, Paco, Antonio y miembros de esta comunidad.

Que bien que se haya solucionado tu caso, mi estimado Martín.

Solo comentar que en base al tema de adjuntos, el servidor si reenvía los adjuntos si la aplicación ha sido modificada. Yo lo he sufrido el mismo caso y así lo soluciono, de cualquier manera se puede forzar la actualización de adjuntos según esta información:

En el caso de que que queramos actualizar el fichero adjunto al proyecto el procedimiento será borrar el objeto fichero adjunto del mapa y crearlo nuevamente…

Un abrazo a tod@s.


([N3] pacosatu) #10

Hola a todos.

Magnífico apunte Antonio. Magnífico apunte Víctor.

Si me permitís, me parece interesante hacer un resumen para que quede constancia en el foro. He hecho pruebas con un documento adjunto a un proyecto vca de tipo PDF y estas son mis conclusiones que complementan a la documentación de Velneo:

  • La caché se crea por usuario y máquina (\velneo\cacherun<dominio/ip_vServer>
  • Los ficheros adjuntos del proyecto se copian a la caché desde la carpeta de la Solución en vServer
  • Un fichero adjunto se copiará o actualizará a la caché en los siguientes casos:
    Cuando el proyecto al que pertenece cambia
    Cuando se borra manualmente el proyecto en la caché
  • Borrar manualmente un fichero adjunto de la caché no desencadena su actualización, aunque es suficiente con borrar el proyecto al que pertenece.

Así que las conclusiones son que:

  • Para actualizar varios ficheros adjuntos vale con copiar la nueva versión a la carpeta del vServer y forzar un guardado del proyecto. Con esto el fichero vca o vcd se copiará de nuevo a la caché junto con todos los adjuntos. Así, no es necesario borrar el objeto Adjunto y crearlo nuevamente y nos ahorramos un trabajo tedioso en el caso de que sean muchos adjuntos.
    Observad que esta actualización se hará para todos los Usuarios y máquinas.

  • Para el caso de Martín, en el que queremos borrar manualmente un fichero sospechoso de la caché, no es necesario borrar toda la caché, simplemente borramos el proyecto al que pertenece el adjunto y se actualizarán todos los adjuntos (por esta razón es necesario guardar una copia de la caché original que causa problemas, para reponer los ficheros de nuevo a la caché).
    Observad que esta actualización solo se hará para el usuario/máquina conectado.

A veces no será posible borrar toda la caché porque habrá ficheros de personalización, de logs, etc… pertenecientes al usuario.

Saludos
Paco Satué


([N1] Spicer) #11

Estimados,

Concuerdo plenamente que un depurador es, a estas alturas, un componente básico de cualquier plataforma de desarrollo, y sobre todo de una como V7, que ha tenido tanta evolución en los últimos años.

Me ha pasado muchas veces que al encontrar un error, resulta imposible saber por qué ocurre, con lo cual hay que empezar a mirar los valores de las variables con paneles adicionales, mensajes, etcétera. Eso es una enorme desventaja, por decirlo suavemente y sin querer ser destructivo con la enorme labor que realizan los integrantes de Velneo. La plataforma es extraordinaria, pero tiene cosas que resultan enervantes. La falta de un depurador es una de ellas.

En mi caso, he aprendido a ‘oler’ los errores, por lo cual el 95% del tiempo cuando hay un error, ya sé por qué ocurre.

Finalmente, aprovecho de agradecer a los Masters Paco Satué y Martín Ibarra, que siempre son un excelente aporte a este Distinuguido foro (Nótese que Distinguido va con Mayúscula)

Saludos,


([N4] Infortic) #12

Llevo 2 horas poniendo mensajes y alerts y todavía no he encontrado un error que estoy convencido que tendría arreglado en 1 minuto si tuviera depurador.

Estoy HARTO.

En mi caso no pierdo el tiempo que gano, pierdo muchísimo más del que gano.

Y no pinta que lo vayamos a tener nunca la verdad.


([N1] Emanuel) #13

Si el depurador es algo que se pidió siempre. Una vez creo que le pregunté a Cobos y me dijo que era complicado de realizar pero que estaba pendiente, si mal no recuerdo.

Saludos.


([N4] ns) #14

+1


([N4] nDesarrollo) #15

+1



([N2] japps) #16

+1 al depurador:

Yo estoy recién llegado y la verdad me ha sorprendido mucho la falta debug y mas viniendo de VB que puedes programar mientras haces debug. Por el momento el tiempo perdido buscando errores ha sido increíblemente mayor que el empleado en programar.

+1 a la ayuda contextual en vDevelop

Es lento ir a consultar un documento un documento PDF de 1090 páginas


([N1] carlaarana) #17

Hola chicos velneadores!!!

Respecto a este asunto, debo contar las siguientes experiencias:

  1. left(#CAMPOTEXTO,3=“121”).
    Lo escribir y me “distraje”, y asi lo pasè y el proceso donde estaba escrito no resultaba como lo que queria. En esta expresion el “Inspector de errores” no muestra error. Despues de muchas horas me di cuenta que correcto para mi es:
    left(#CAMPOTEXTO,3)=“121”

  2. segunda experiencia:
    Despues de la ejecucion exitosa de un proceso a una tabla, me dedique a aumentar las tablas de acumulados utilizando los campos de “indirecto real” en varios de de tablas acumuladas y en la penultima olvido colocar los campos de “resolucion”. Asi lo deje de un viernes a lunes. Luego optimizando y ejecutando el proceso mencionado el vclient rompia y hacia “parar” el verver (ojo ESTA ROMPE Y PARA el vserver). Yo pensando que habia pecado en la optimizacion de este ultimo proceso. Asi pasaban los dias y pasaban los dias y seguian pasando, no encontraba donde estaba el error aun usando el “inspector de errores”. Hasta que reviso los campos de “resolucion” hasta esa penultima tabla de acumulados, complemento esos “campos de resulucion” y “problema solucionado”

A falta de campos de “resolucion” ROMPE vclient y PARA el vserver.

A los chicos del equipo de desarrollo de velneo ruego tomar nota de esta mi experiencia.

Es la historia de una experiencia.

Gracias a todos.