No es lo mismo escribir assembler a mano porque el compilador no hace
lo que vos queres, que escribir C para que tu programa cumple las
reglas que hay que cumplir. No te queda otra. No se puede llamar a
funciones arbitrarias desde un FFI (por ejemplo, GetLastError()).
Tampoco se puede obtener el valor de entes arbitrarios desde un FFI
(por ejemplo, errno). Es decir, como poder se puede, pero
teoricamente tambien podes hacer algo como Metaclass become: String
new. Que algo no este prohibido no implica que este bien.
Por un lado, lidiar con C a traves de Smalltalk parece lograr reducir
la complejidad de C a dos metodos en un FFI, y eso se ve como una
validacion de que Smalltalk es bueno. Por otro lado, esa reduccion de
complejidad es una ilusion, y en realidad el codigo C implicito suele
estar mal. Mientras la cosa funcione mas o menos de casualidad,
entonces Smalltalk es cool y como esa hipotesis en general se da como
axioma entonces termina siendo una excusa que cubre el moco implicito.
En pocas palabras, "Smalltalk es cool" no justifica "cuando programo
cosas de C no leo la documentacion, y cuando escribo cosas en un FFI
es lo mismo que usar un compilador C de verdad".
Y el problema no es solo del FFI. El tema del codigo traducido es que
si ***parece*** que funciona, como ***sabes*** que funciona si nunca
miraste el codigo C? Por ejemplo, no poder subir el nivel de
optimizacion es un sintoma serio que conozco de primera mano. Si tu
programa no anda con mucha optimizacion, porque tiene que andar con
poca o sin optimizacion? Como sabes que la conducta tiene que ser la
misma? De haber lidiado con esto personalmente, el 99% de las veces
la causa es una violacion de algun standard por parte del que escribio
el codigo C.
Tambien es cierto que encontramos un bug en el compilador de HPUX
porque, en ciertos casos,
if (...) {
blah;
} else {
blah;
}
no es lo mismo que
(...) ? blah; : blah;
La documentacion de turno dice que la segunda notacion *deber ser*
equivalente a la primera notacion. Sin embargo, este es *UN* caso de
*N*, y viene con la *demostracion* de que hay un bug en el compilador
en vez simplemente decir *debe haber* algun bug en el compilador. Por
eso, la gente de HPUX abrio un ticket para arreglar su compilador. No
es lo mismo.
Y no es que a mi me guste laburar de abogado de la especificacion,
ojo. La mayoria de las veces es muy denso. Pero es clarisimo: si no
lees el manual, tu programa *no anda*. Y si la maquina virtual no
anda, o si por ejemplo alguien del mundo de C (digamos que es mucha
mas gente que nosotros) empieza a ver todos estos problemas, entonces
porque van a querer usar nuestro lenguaje de programacion si desde su
punto de vista no podemos mostrar un minimo de disciplina? La
impresion que damos a veces es bastante ridicula: escribimos un FFI
con un costo enorme, que al final no sirve (es decir: no *puede*
servir) en el caso general, y la mayoria de las veces es para evitar
escribir como mucho O(100) lineas de C.
Leer manuales de C es denso, pero a mi me parece que es mas importante
que la maquina virtual funcione.
2011/4/5 Hernan Wilkinson <[email protected]>:
> Andres,
> tu razonamiento es muy similar al que tenía la gente en el 50 (sin
> ofender eh!) cuando prefería escribir código assembler en vez de
> utilizar lenguajes de "alto nivel" porque el "compilador no era tan
> bueno como las personas" para escribir código performeante, etc. O
> sea, yo entiendo lo que decis y en ciertos puntos concuerdo que hay
> que escribir código C, pero seguramente en la mayorías de los casos el
> C generado automáticamente puede ser lo suficientemente bueno o aún
> mejor de lo que podría escribir una persona... por supuesto que no es
> lo mismo traducir leng. alto nivel a assembler que smalltalk a C (está
> la diferencia de abstracción que cada uno maneja), pero me suena a un
> problema similar.
>
> Un abrazo
> Hernan.
>
> 2011/4/4 Andres Valloud <[email protected]>:
>> No estoy muy convencido de que cualquier cosa en C se pueda escribir
>> en Smalltalk que eventualmente se traduce a C. De hecho, me parece
>> tanto quilombo hacer eso que prefiero escribir las O(100) lineas de C
>> que hagan falta, cumplir con la especificacion de turno, y listo. Ojo
>> que cuando digo esto estoy pensando en cosas que tienen que ver con la
>> plataforma, no necesariamente un JIT.
>>
>> 2011/4/4 Guillermo Schwarz <[email protected]>:
>>> 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
>>
>> --
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>>
>> http://www.clubSmalltalk.org
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: [email protected]
> site: http://www.10Pines.com
>
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
