Proyectos (era Re: Problemas con GTK)

[Alvaro Herrera]

Horst von Brand escribió:
> Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:

> > Siempre he considerado esa posicion bastante absurda.  Un debugger puede
> > ayudar a entender _donde_ esta el problema, y con esa informacion
> > corregir el problema de fondo.  Por supuesto, si un idiota cualquiera
> > toma la informacion del debugger y corrige el sintoma en lugar del
> > problema, es un idiota como los que se encuentran en cualquier parte; no
> > es culpa del debugger.
> 
> En mi personal experiencia, las situaciones donde un debugger realmente ha
> sido de ayuda han sido pocas (me ayudo bastante cuando aprendia Perl y no
> sabia que estaba escribiendo, pero fuera de eso...). Y en el caso del
> nucleo creo que tiene toda la razon: Lo que hay que hacer para que tal cosa
> funcione es /mucho/ trabajo, que mete sus tentaculos en las partes mas
> reconditas del sistema, y simplemente no lo vale.

Sorry, es que hay dos temas: uno es que en el codigo de Postgres no hay
suficientes "clausulas de contrato" para mi gusto; el debugger ayuda a
ver en que parte se empieza a violar esta clausula faltante.  Una vez
agregada, ya el debugger no es necesario.

El otro es que en situaciones donde el usuario reporta un bug, a menudo
no hay mas informacion que "se cae el servidor".  En ese caso se le dice
"por favor abre gdb y muestra el stack trace del archivo core", o algo
similar.  Con eso se puede buscar el bug en el codigo.

Con respecto al costo de implementarlo, en el caso de Postgres ya esta
hecho (GDB), y en el caso del Kernel ciertamente hay mucha gente
interesada en tenerlo, asi que no veo en que sentido es un problema.  Si
Linus no quiere gastarse en analizar que el codigo del debugger es
correcto, es otro tema.

> >                                 Esta aproximacion me ha permitido
> > resolver problemas grandes, y usar depuradores para ver errores en mis
> > soluciones.  El paradigma "programacion por contrato" ayuda mucho en
> > este aspecto, y el depurador es una buena herramienta para buscar nuevas
> > clausulas para los contratos, y ver donde estan fallando.
> 
> Podrias detallar? No veo como un debugger ayude alli

Con respecto a esto: el tema era precisamente que el debugger sirve para
ver donde poner nuevos Assert().  Una vez que el assert() mata al
programa, el debugger puede ayudar a ver de donde vino el parametro
incorrecto.

En verdad, para mi GDB ha sido una herramienta extraordinariamente util,
pero creo que la mayor razon es la idiosincracia de C del manejo de
memoria.  En otros lenguajes no he tenido tanta necesidad de el (aunque
por otro lado no me he metido en programas tan complejos, con otros
lenguajes, como con C).  Aunque en PHP, cuando me ha tocado examinar
codigo de otras personas, si lo he echado de menos, no como debugger
propiamente tal, sino como una herramienta para ir viendo paso a paso
que diablos esta sucediendo con el programa.  (El que PHP tenga esas
facilidades absurdas para esconder los errores, no ayuda en nada.)


Hoy ando con mala capacidad de concentracion, asi que mis disculpas si
lo de arriba es algo incoherente :-P

-- 
Alvaro Herrera                         Architect, http://www.EnterpriseDB.com
"El conflicto es el camino real hacia la unión"