Si, estoy de acuerdo en que crear la interacción con el resto del mundo es bastante laboriosa, y utilizar algún tipo de leverage, ya sea con la libc, o usando otra vm (como hizo Angel), puede ser util.
2011/4/7 Andres Valloud <[email protected]>: > Para ser un poco mas bruto... tenemos suficiente masa cerebral para ir > y reimplementar algo como GCC y glibc en N plataformas? Es un laburo > *denso*... e igual no te salvas de leer la documentacion de turno! > > 2011/4/7 Andres Valloud <[email protected]>: >> Y... como poder seguro que se puede... o sea, podes implementar un >> compilador de C y generarte tus propios exes para todas las >> plataformas etc (asumiendo que queres usar un sistema operativo que >> escribio otro). Ahora, vale la pena todo ese trabajo cuando, con >> considerablemente menos esfuerzo y mantenimiento, podes usar lo que >> hicieron los demas? >> >> 2011/4/7 Javier Burroni <[email protected]>: >>> Hola, >>> no se si un smalltalk se puede escribir en smalltalk; pero un Mark & >>> compact, y un GC generacional, me consta que sí :) >>> (perdón, pero justo coincidió el thread con otra cosa del universo) >>> >>> 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 >>> >>> >>> >>> -- >>> " To be is to do " ( Socrates ) >>> " To be or not to be " ( Shakespeare ) >>> " To do is to be " ( Sartre ) >>> " Do be do be do " ( Sinatra ) >>> >>> -- >>> 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 be is to do " ( Socrates ) " To be or not to be " ( Shakespeare ) " To do is to be " ( Sartre ) " Do be do be do " ( Sinatra ) -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
