A eso justamente iba. Si debe estar en c es porque desde smalltalk no puedo hacer referencia a una posición en memoria, que es justamente como se manejan los signals.
En squeak hay una manera de traducir smalltalk a c. Cada mutex de smalltalk debiera ser traducible a un mutex de c. Saludos, Guillermo Schwarz. El 03-04-2011, a las 4:17, Andres Valloud <[email protected]> escribió: > Me refiero a los mutexes que tienen que estar escritos en C, por > ejemplo los de los signal handlers o los de los foreign callbacks. > > 2011/4/2 Guillermo Schwarz <[email protected]>: >> Estoy 100% de acuerdo en lo que dices, excepto en eso de que "si los mutexes >> están escritos en c, le dan poca bola, si están escritos en smalltalk no les >> van a dar nada", ya que mientras mas alto es el nivel del lenguaje mas >> evidente se hacen todas esas cosas y es mas fácil arreglarlas. >> >> Saludos, >> Guillermo Schwarz. >> >> El 02-04-2011, a las 17:33, Andres Valloud <[email protected]> >> escribió: >> >>>> En resumen, coincido con vos. Tal vez mi post no fue tan claro como yo >>>> quise. Mi punto de vista era que el hecho de que esté escrita en SLANG está >>>> buenísimo para que cualquier boludo >>> >>> No no no :)... >>> >>>> cómo yo, la pueda >>>> navegar/refactorizar/simular usando las herramientas mismas de Smalltalk. >>> >>> Eso esta bueno. A mi por ejemplo me gustaria tener senders / >>> implementors en vez de usar grep. Aunque grep tambien tiene lo suyo. >>> >>>> Ponele si yo miro el interp.c (el archivo resultado de la transformación >>>> de >>>> SLANG a C), y pienso que tengo que entender/modificar eso, me pego un tiro. >>>> Claro, es autogenerado, así que supongo que si está hecho todo manual es >>>> otra cosa, pero igual... >>> >>> Y si... eso no es facil. A mi lo que me da un poco de impresion es >>> que si esta autogenerado entonces no se le pasa tanta bolilla desde el >>> punto de vista de C por la razon que decis... es un quilombo. Hace >>> varios años cuando estaba en Exobox (que te pario ya soy un fosil!!!) >>> me acuerdo que despues de la primera conversion venia otra que hacia >>> inline de todo 9 veces seguidas, socorro... lo que me da un poco de >>> cosa es el tema de los tipos, los bitfields con GCC, las cosas que no >>> estan especificadas como hacer bitshift a la izquierda de un entero >>> negativo mas veces que la cantidad de bits en el entero... >>> >>> ... o sea, en C el resultado de esta operacion depende del compilador: >>> >>> int k = -1; >>> return k << 40; >>> >>> Ojo, para valores positivos la especificacion dice exactamente que >>> tiene que pasar, pero para valores negativos, no. En algunos casos vi >>> cero, y en otros vi como el shift se hacia rotativo y los bits que se >>> caian de un lado aparecian en el otro. Estaba tentado de pensar que >>> el compilador era una basura, pero me fije en la especificacion de C >>> (se llama C99), y... y dice claramente que el resultado en ese caso no >>> esta especificado. Esta clase de cosas son jodidas, y encima hay un >>> monton. >>> >>> Que se yo, tambien hay una region gris donde se asume que la >>> implementacion va a ser razonable. Uno se la pasa asumiendo que los >>> punteros se pueden comparar independientemente de la direccion a la >>> que apuntan. Sin embargo, la comparacion de punteros tampoco esta >>> especificada si los punteros en cuestion no apuntan a datos del mismo >>> array (o, como mucho, &(a[x]) si el array tiene tamaño x). En algun >>> lado dice que todos los programas en C tiene *un* stack --- asi que >>> por ejemplo tener stacks "nativos" en un JIT es una violacion de la >>> especificacion correspondiente. Y sin embargo, la cosa anda porque >>> las implementaciones en C son lo suficientemente flexibles (o, dicho >>> de otro modo, no son tan estrictas) como para que cosas interesantes >>> funcionen igual. >>> >>> Por eso hay que tener mucho cuidado, despues uno le termina tirando la >>> culpa de que el programa no anda a algun misterioso "bug del >>> compilador" demasiado facil... >>> >>>> No cabe duda de que hay muchísimas partes que se tienen que hacer directo >>>> en >>>> C: cuestiones de performance, cuando depende de la plataforma, etc etc etc. >>> >>> O lo que rompe mucho la paciencia hacer en el JIT, como por ejemplo la >>> primitiva del become: en particular cuando tenes un modelo de memoria >>> complejo. En VisualWorks hay 15 casos, y encima hay que pensar mucho >>> que pasa cuando el IGC esta funcionando y haces cosas como >>> >>> strongObject become: weakObject >>> >>> o >>> >>> weakObject become: anEphemeron >>> >>> Ya en C eso es un ***bardo***. Escrito en un JIT... ay que dolor. >>> >>>> Más allá de eso, la simulación para muchos es terriblmente inpagable. >>>> Ponele, si le preguntás a Eliot (por lo que me comentó en la Smalltalk o en >>>> la Deep Smalltalk, no me acuerdo), está CHOCHO con poder simular la VM. De >>>> hecho, puso bocha de esfuerzo en el simulador (incluso para la JIT). >>> >>> El tema de simular los metodos nativos y todo eso debe ser mucho mas >>> agradable que gdb (o, mucho peor, WinDBG). Pero tambien hay que tener >>> en cuenta que seguramente en esa simulacion el tema de signals e >>> interrupciones no es una simulacion fiel de lo que pasa en realidad. >>> >>> Por ejemplo, que pasa cuando hay que boletear el stackLimit de un >>> stack desde un signal handler? Y que pasa si la interrupcion cae >>> mientras la maquina virtual (en C) esta cambiando los stack pages? >>> Entonces se te cae un pedido de interrupcion al piso y la maquina >>> virtual lo ignora. Arreglar esa clase de bugs es muy dificil porque >>> la mayoria del tiempo parece que las cosas funcionan. Esto pasa en >>> VisualWorks... lo tengo un poco arreglado, pero hay otro bug >>> relacionado que aun no encontre (basicamente, podes hacer que un >>> proceso de prioridad menor le haga siempre un preempt a varios >>> procesos de prioridad superior, lo que esta claramente muy mal), y >>> entonces no se si el tema del stackLimit esta arreglado del todo o no. >>> Mientras tanto, hace mas de una decada que ***parece*** que funciona. >>> >>> Y sin embargo que no existan esos problemas, que no haya problemas con >>> secciones criticas sin proteccion de mutex, que no haya violaciones >>> groseras de la especificacion relevante... todas esas cosas que en C >>> las tenes a flor de piel son hiper importantes para que despues uno >>> pueda decir que la maquina virtual anda. Me preocupa que si ya hoy >>> mucha bolilla no se le pasa a esos temas de C, entonces mañana si esta >>> escrito en Smalltalk entonces menos bolilla se le va a pasar. >>> Arreglar los parches que se acumulan con los años para hacer que las >>> cosas ***parezcan*** funcionar es un requilombo... si con un cambio >>> haces que el bug que te pasaba una vez cada 5 minutos ahora pase cada >>> 6 meses, mejor no cambies nada hasta no encontrar el bug. >>> >>> Andres. >>> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
