Re: [Python-es] Compilar python a javascript
Hola a todos me he decidido a utilizar multiprocessing para tratar de ejecutar varios procesos al mismo tiempo pero sucede que al ejecutarse la linea p.start() no hace nada solo se detiene y se reinicia la aplicación,ya revisé bien los parámetros que se le pasan al Proces y no hay error además no me lanza ningun error solo se detiene en esa linea si me pueden ayudar se los voy a agradecer saludos - Mensaje original - De: Hernan M Foffani hfoff...@gmail.com Para: La lista de python en castellano python-es@python.org Enviados: Jueves, 27 de Mayo 2010 6:34:55 GMT -04:00 Georgetown Asunto: Re: [Python-es] Compilar python a javascript ¿Alguien tiene experiencia con proyectos como los descritos en http://developers.slashdot.org/firehose.pl?op=viewtype=storysid=09/09/19/1345236?. Lo que me interesa es poder programar 100% python y que esos programas funcionen en un navegador, incluyendo el acceso al DOM y demás filigranas habituales en Javascript. No quiero aprender (más) javascript si puedo evitarlo. Pues sí. Con Pyjamas es posible. Hace tiempo que no haga nada con él así que no se en qué estado de madurez está hoy. Pero ten en cuenta que si bien te evitas programar en JS tendrás que lidiar con una API gráfica nueva. Lo mejor es que lo evalúes tu mismo. Me olvidaba de algo importante: Las bibliotecas de Pyjamas son independientes del navegador. ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] Compilar python a javascript
Ivette, ¿qué tiene que ver lo que hablas con el javascript? En/na Ivette Maria Suarez Muñoz ha escrit: Hola a todos me he decidido a utilizar multiprocessing para tratar de ejecutar varios procesos al mismo tiempo pero sucede que al ejecutarse la linea p.start() no hace nada solo se detiene y se reinicia la aplicación,ya revisé bien los parámetros que se le pasan al Proces y no hay error además no me lanza ningun error solo se detiene en esa linea si me pueden ayudar se los voy a agradecer saludos - Mensaje original - De: Hernan M Foffani hfoff...@gmail.com Para: La lista de python en castellano python-es@python.org Enviados: Jueves, 27 de Mayo 2010 6:34:55 GMT -04:00 Georgetown Asunto: Re: [Python-es] Compilar python a javascript ¿Alguien tiene experiencia con proyectos como los descritos en http://developers.slashdot.org/firehose.pl?op=viewtype=storysid=09/09/19/1345236?. Lo que me interesa es poder programar 100% python y que esos programas funcionen en un navegador, incluyendo el acceso al DOM y demás filigranas habituales en Javascript. No quiero aprender (más) javascript si puedo evitarlo. Pues sí. Con Pyjamas es posible. Hace tiempo que no haga nada con él así que no se en qué estado de madurez está hoy. Pero ten en cuenta que si bien te evitas programar en JS tendrás que lidiar con una API gráfica nueva. Lo mejor es que lo evalúes tu mismo. Me olvidaba de algo importante: Las bibliotecas de Pyjamas son independientes del navegador. ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] .NET Remoting en Python
2010/5/27 Hernan M Foffani hfoff...@gmail.com: Q: - Alguien conoce una librería que permita serializar objetos y mensajes para obtener el formto binario del protocolo .NET Remoting ? Gracias por adelantado ! Con IronPython tienes acceso a todas las librerías de .NET y mono no? [...] Pero bueno, preferiría una librería que sea FOSS, hecha completamente en Python. Por eso pregunté ... [...] Las alternativas que tienes son: IronPython, Python.NET (está discontinuado) o una pasarela o proxy personalizado (que sólo abarque la api de tu servicio) de Remoting a lo-que-sea (JSON, etc.) Nota: IronPython es Python y es FOSS. [Desde ya aviso que paso de flamewars sobre este tema. Si no contesto es que estoy en desacuerdo :-P] Antes que todo aclaro que hablo del .NET Remoting binario que tiene una implementación o binding en WCF (AFAIK Framework 3.5) Pero a ver, ¿Es .NET Remoting o WCF? Son cosas distintas. No, para nada. WCF es una API para RPC, multi-protocolo, que tiene un binding para MS-NRBF sobre TCP y HTTP , otro para SOAP con diferentes transportes, otro para los WS-* , ... , más los que se le puedan ocurrir a alguien que haga sus propios bindings o los que resulten de ensamblar binding elements existentes o nuevos. Mientras que .NET Remoting Binary format (código del estándar MS-NRBF ;o) es un protocolo binario para serializar mensajes RPC . Para que quede más claro : NRBF es un protocolo (o tecnología de serialización) para RPC, mientras que WCF es una API . Como me diría alguien alguna vez «oranges and apples, Olemis» ;o) El Remoting viene desde la versión .NET 1.0. Ya en la 2.0 se recomendaba no usarlo y lo nuevo se hacía vía WebServices. El NRBF es más o menos lo mismo pero binario y «más eficiente» (de hecho el MS-NRTP a.k.a. .NET Remoting Core Protocol Specification tiene un binding para SOAP y otro binario ;o) Y ahora lo guay es WCF. ¿Por qué lo dice MS? ;o) Bien, poniendo a funcionar mis neuronas creo que logro darme cuenta de que me venden esencialmente lo mismo con una nueva envoltura (envoltura que resulta ser lo que es más guay ;o). Lo que sí es nuevo es los bindings ws* . Q: - ¿Porqué está pasado de moda? Ni idea. Pregúntale a Microsoft. Bueno MS no fue quién lo dijo en mensajes anteriores ;o) . ¿Al menos recuerda Ud donde es que MS lo dijo? La verdad es que tenía severas limitaciones. Bueno, comparado con otras cosas, puede ser . Pero e.g. para publicar servicios en una intranet y aprovechar el ancho de banda (desperdiciado miserablemente por super-SOAP) ... DISCLAIMER: No es que me guste mucho la idea de usar .NET Remoting, pero parece que a otros sí ... ;o) La alternativa de la pasarela no me sirve porque lo que pretendo es añadir soporte para .NET Remoting (HTTP binding) en una app web hecha en Python . La alternativa de IronPython + Python.NET no me sirve porque requeriría instalar Mono Co. en GNU/Linux y hacer una buena cantidad de cambios en el Apache para hacer que todo eso corra . En definitiva , descartada (a no ser que no quede otra alternativa ...). IronPython y Python.NET no pueden ir *sumados*. Disculpa si no me expresé bien, pero son alternativas excluyentes. El que se expresó mal fue yo . Donde dije *digo* (i.e. IronPython + Python.NET) digo *Diego* (i.e. IronPython | Python.NET) :-S Dado que tienes el Apache de por medio, piensa de nuevo en la pasarela, por ejemplo, a JSON. Tu aplicación solo expone JSON, y *por fuera* (separada del Apache), implementas una pasarela JSON-WCF escrita en IronPython o en C#. La aplicación web de la que hablo ya tiene soporte para (XML|JSON)RPC , pero se desea añadirle soporte para MS-NRTP + MS-NRBF . Faltó una alternativa «Do It Yourself» ;o) , pero si me pudiera evitar un poco de trabajo ... No, no me he olvidado. Estaba implícita cuando te dije que el protocolo de comunicación no es el problema mayor. Insisto, la dificultad está en la serialización y deserialización de objetos .NET a Python y vuelta. El tiempo que necesitarías para implementarlo es enorme... Además, ¿Cómo vas a probar que tu interfaz funciona sin programar en IronPython, C# o VisualBasic.NET? De la misma forma que se puede utilizar HessianPy , PyAMF et al (i.e. todos protocolos para RPC diseñados para lenguajes que no tienen nada que ver con Py ;o) sin necesitar Java, ni ActionScript, ni ... ;o) El papel de C# et al en este caso solo lo veo relacionado con algún tipo de suite de pruebas + CI para verificar interoperabilidad con esas plataformas . -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Control de usuarios personalizado con Apache y mod_authnz_external - http://feedproxy.google.com/~r/simelo-es/~3/cBNqfg_xMaw/control-de-usuarios-personalizado-con.html ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ:
Re: [Python-es] Compilar python a javascript
tambien existe una forma de programar en python y obtener css http://sandbox.pocoo.org/clevercss/ 2010/5/27 Narcis Garcia - GiLUG informat...@actiu.net Ivette, ¿qué tiene que ver lo que hablas con el javascript? En/na Ivette Maria Suarez Muñoz ha escrit: Hola a todos me he decidido a utilizar multiprocessing para tratar de ejecutar varios procesos al mismo tiempo pero sucede que al ejecutarse la linea p.start() no hace nada solo se detiene y se reinicia la aplicación,ya revisé bien los parámetros que se le pasan al Proces y no hay error además no me lanza ningun error solo se detiene en esa linea si me pueden ayudar se los voy a agradecer saludos - Mensaje original - De: Hernan M Foffani hfoff...@gmail.com Para: La lista de python en castellano python-es@python.org Enviados: Jueves, 27 de Mayo 2010 6:34:55 GMT -04:00 Georgetown Asunto: Re: [Python-es] Compilar python a javascript ¿Alguien tiene experiencia con proyectos como los descritos en http://developers.slashdot.org/firehose.pl?op=viewtype=storysid=09/09/19/1345236 ?. Lo que me interesa es poder programar 100% python y que esos programas funcionen en un navegador, incluyendo el acceso al DOM y demás filigranas habituales en Javascript. No quiero aprender (más) javascript si puedo evitarlo. Pues sí. Con Pyjamas es posible. Hace tiempo que no haga nada con él así que no se en qué estado de madurez está hoy. Pero ten en cuenta que si bien te evitas programar en JS tendrás que lidiar con una API gráfica nueva. Lo mejor es que lo evalúes tu mismo. Me olvidaba de algo importante: Las bibliotecas de Pyjamas son independientes del navegador. ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/ ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] .NET Remoting en Python
Pero a ver, ¿Es .NET Remoting o WCF? Son cosas distintas. No, para nada. WCF es una API para RPC, multi-protocolo, que tiene un binding para MS-NRBF sobre TCP y HTTP , otro para SOAP con diferentes transportes, otro para los WS-* , ... , más los que se le puedan ocurrir a alguien que haga sus propios bindings o los que resulten de ensamblar binding elements existentes o nuevos. Mientras que .NET Remoting Binary format (código del estándar MS-NRBF ;o) es un protocolo binario para serializar mensajes RPC . Para que quede más claro : NRBF es un protocolo (o tecnología de serialización) para RPC, mientras que WCF es una API . Como me diría alguien alguna vez «oranges and apples, Olemis» ;o) .NET Remoting también es una API, fue introducida en 2002. WCF es la nueva y la que ha dejado obsoleta a la anterior. El protocolo a que te refieres es de hace menos de tres años. Que Microsoft reutilice nombres para cosas distintas no es una novedad. Mi sugerencia es que si hablas de protocolo usa las siglas, porque .NET Remoting es como se conoce la API original. Q: - ¿Porqué está pasado de moda? Ni idea. Pregúntale a Microsoft. Bueno MS no fue quién lo dijo en mensajes anteriores ;o) . ¿Al menos recuerda Ud donde es que MS lo dijo? Lo que he aprendido con los años es que cuando MS (bueno, no es solo Microsoft, eso vale para todos) introduce un nuevo conjunto de APIs para hacer lo mismo (dicho en términos generales) que hacían las anteriores en vez de corregirlas o extenderlas, lo que están diciendo es que mas pronto que tarde las dejarán morir. Read my lips. ... No, no me he olvidado. Estaba implícita cuando te dije que el protocolo de comunicación no es el problema mayor. Insisto, la dificultad está en la serialización y deserialización de objetos .NET a Python y vuelta. El tiempo que necesitarías para implementarlo es enorme... Además, ¿Cómo vas a probar que tu interfaz funciona sin programar en IronPython, C# o VisualBasic.NET? De la misma forma que se puede utilizar HessianPy , PyAMF et al (i.e. todos protocolos para RPC diseñados para lenguajes que no tienen nada que ver con Py ;o) sin necesitar Java, ni ActionScript, ni ... ;o) El papel de C# et al en este caso solo lo veo relacionado con algún tipo de suite de pruebas + CI para verificar interoperabilidad con esas plataformas . Claro, a eso me refiero. Si ya tienes implementado JSON-RPC, hacer un gateway a WCF en cualquier lenguaje .NET nativo no tiene dificultades. Pero si te apetece implementar tu el protocolo ¡Adelante! De paso, mientras depuras tu interfaz mediante ingeniería reversa y tcp-sniffing, le informas a MS de los errores en la documentación del NRBF. ;-) ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
Re: [Python-es] .NET Remoting en Python
2010/5/27 Hernan M Foffani hfoff...@gmail.com: [...] Q: - ¿Porqué está pasado de moda? Ni idea. Pregúntale a Microsoft. Bueno MS no fue quién lo dijo en mensajes anteriores ;o) . ¿Al menos recuerda Ud donde es que MS lo dijo? Lo que he aprendido con los años es que cuando MS (bueno, no es solo Microsoft, eso vale para todos) introduce un nuevo conjunto de APIs para hacer lo mismo (dicho en términos generales) que hacían las anteriores en vez de corregirlas o extenderlas, lo que están diciendo es que mas pronto que tarde las dejarán morir. Read my lips. Volvemos al mismo punto : no hablo de la API , sino del protocolo ... No, no me he olvidado. Estaba implícita cuando te dije que el protocolo de comunicación no es el problema mayor. Insisto, la dificultad está en la serialización y deserialización de objetos .NET a Python y vuelta. El tiempo que necesitarías para implementarlo es enorme... Además, ¿Cómo vas a probar que tu interfaz funciona sin programar en IronPython, C# o VisualBasic.NET? De la misma forma que se puede utilizar HessianPy , PyAMF et al (i.e. todos protocolos para RPC diseñados para lenguajes que no tienen nada que ver con Py ;o) sin necesitar Java, ni ActionScript, ni ... ;o) El papel de C# et al en este caso solo lo veo relacionado con algún tipo de suite de pruebas + CI para verificar interoperabilidad con esas plataformas . Claro, a eso me refiero. Si ya tienes implementado JSON-RPC, hacer un gateway a WCF en cualquier lenguaje .NET nativo no tiene dificultades. Pero si te apetece implementar tu el protocolo ¡Adelante! De paso, mientras depuras tu interfaz mediante ingeniería reversa y tcp-sniffing, le informas a MS de los errores en la documentación del NRBF. ;-) Ingeniería inversa ??? Bueno , no entiendo porque debería hacerlo , especialmente después que tan gentilmente desde Microsoft han publicado (todas ?) las especificaciones de sus protocolos (unos 200-300 MB [1]_ ), ratificando así su compromiso con el FOSS ;o) PS: OT: ¿Será que como ahora Apple es quién subió al trono [2]_ se invirtieron los papeles? :P .. [1] Windows Communication Protocols (MCPP) (http://msdn.microsoft.com/en-us/library/cc216513(v=PROT.10).aspx) .. [2] Google Finance - GOOG AAPL MSFT (http://www.google.com/finance?q=GOOG+AAPL+MSFT) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Control de usuarios personalizado con Apache y mod_authnz_external - http://feedproxy.google.com/~r/simelo-es/~3/cBNqfg_xMaw/control-de-usuarios-personalizado-con.html ___ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
