Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-09 Por tema Patricio Morales 
El día 2/12/07, Mauro A. Morales M. <[EMAIL PROTECTED]> escribió:
>
> > > Hace un par de meses vi un manual medio ochentero de Turbo Prolog que
> > > claramente estaba pensado para desarrollar aplicaciones de negocios.



Sistema experto ? Base de conocimiento ?
>
> > > No recuerdo haber visto nada relacionado con bases de datos, pero sí
> > > explicaban cómo crear interfaces gráficas con ventanitas y todo.  No
> > > se veía tan marciano como uno podría pensar; después de todo, las
> > > reglas de inferencia de Prolog no son tan diferentes de las funciones
> > > de otros lenguajes.
>
> Quizas para los inputs ?.
>
> > >
> > > A mi me tocó ver una versión de Prolog para MacOs,junto con el famoso
> > programa ELIZA
> > hecho con PROLOG el cual simulaba el dialogo con un psiquiatra.Vi el
> código
> > fuente de este programa
> > y la sintaxís y forma de programación ,realmente me sonaban a
> > mandarín:totalmente distinto a lo que
> > había visto en los lenguajes de  programación estructurada.
>
> Estas meando fuera del tiesto. El proposito de PROLOG no es un sistema
> de informacion tradicional.


Lee bien :jamas dije que PROLOG fuera un lenguaje diseñado para sistema de
Información
Tradicional.

Saludos.

Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Sun Dec  9 21:28:29 2007
From: [EMAIL PROTECTED] (Alvaro Herrera)
Date: Sun Dec  9 21:31:39 2007
Subject: Ocultar Passwords a produccion.
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Horst H. von Brand escribió:
> Asdtaker <[EMAIL PROTECTED]> wrote:
> > On Dec 5, 2007 2:10 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:

> > > Las passwords necesariamente deben estar en un archivo en alguna parte.
> 
> > Ok, I agree.
> 
> Nope. Revisa p.ej. como funciona /etc/passwd + /etc/shadow, y porque usan
> un hash criptografico.

Humm, pero el tema es donde almacenar las passwords _en el cliente_.
Dado que las necesita en un formato que sea util para darselas al
mecanismo de autentificacion, deben estar en claro, no cifradas.
/etc/{shadow,passwd} son del sistema de almacenamiento de passwords en
el _servidor_.

-- 
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"El sabio habla porque tiene algo que decir;
el tonto, porque tiene que decir algo" (Platon).
From [EMAIL PROTECTED]  Sun Dec  9 23:37:46 2007
From: [EMAIL PROTECTED] (Collao Castro)
Date: Mon Dec 10 00:39:28 2007
Subject: emular Sun Solaris en Ubuntu
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

La experiencia mia es con vmware usando centos y emulando un solaris 8 y 9.
No tuve problemas con nada. Lo he usado hasta en producción para parchar o
salir del paso y funciona muy bién.

Ahora, otra cosa es correr una máquina Sparc con Solaris, pero entiendo tu
situación.

Saludos.

Atte.

Juan Collao Salas
Ingeniero Ejecución Informático.

-Mensaje original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] nombre de Carlos Molina
Enviado el: viernes, 07 de diciembre de 2007 17:44
Para: linux@listas.inf.utfsm.cl
Asunto: emular Sun Solaris en Ubuntu


hace poco instale ubuntu en un pc con la intensiòn de recuperar
algunas aplicaciones que poseia en un viejo SUN.
alguno de los honorables, conoce algun emulador para esta plataforma
que corra en ubuntu?
segun san google QEMU, es una alternativa, pero me gustarìa saber de
experiencias al respecto.

desde ya, gracias.

--
Carlos Molina
Ingeniero en Informática.

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-06 Por tema Rodrigo Fuentealba 
El 5/12/07, Horst H. von Brand <[EMAIL PROTECTED]> escribió:
> rodrigo ahumada <[EMAIL PROTECTED]> wrote:
> > Rodrigo Fuentealba <[EMAIL PROTECTED]> dijo:
> > >> >rodrigo ahumada escribió:
>
> [...]
>
> > >No. Todo son funciones; las funciones pueden devolver un tipo de dato
> > >cualquiera, aunque éste sea "void" (nada).
> > >Te recomendaría algo denso relacionado con C, pero por esta clase de
> > >errores, ve al "Aprenda C como si estuviera en Primero".
>
> > ¿cuáles errores? ¿el no comulgar con el dogma C?
>

El opinar sobre un lenguaje del cual pones en evidencia que
desconoces. No digo que yo sea el gran experto. Quizás si lo
estudiaste alguna vez, deberías reclamar para que te devuelvan la
plata.

> Si no sabes C, no tienes derecho a opinar.
>
> [...]
>
> > >De hecho, lo que generalmente en orientación a objetos en PHP 5 se le
> > >llama "métodos" también se declara como "function"; es la forma del
> > >lenguaje de denominarla, nada más que eso.
>
> > eso muestra que el primer lenguaje que aprendieron los creadores de PHP
> > probablemente fue C.

No. De hecho, PHP nunca estuvo pensado para ser un lenguaje como lo es
ahora. Inicialmente PHP significaba "Personal Home Page" y era un
template manager escrito en Perl, algo más completo que lo que hace
ahora Smarty.

> En C no hay "metodos". Tampoco en C++. Es terminologia propia de Smalltalk
> (donde significa algo /bien/ diferente).
>
> >   Eso se llama Impronta, y explica harto este tipo de
> > discusiones de que cual lenguaje es mas santo

Depende de tus parámetros de "santidad".

PHP es un engendro difícil porque es más fácil de que mil monos
codificando durante mil años hagan algo que funcione en PHP; pero yo
lo uso mucho porque es un lenguaje que sirve para mi pega. Y con esto,
por mucho que me acomode, no puedo decir que es santo.
.
> Bueno, si es por eso el "lenguaje mas santo" para mi debiera ser FORTRAN 66
> (o algo anterior)... no es tan simple.

( OT: por aquí dijeron que el lenguaje más santo era el en SAN
Blador... creo que es hora de quitarles las bebidas alcohólicas a los
muchachos :/ ).

-- 
Rodrigo Fuentealba Cartes

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-05 Por tema Horst H. von Brand 
rodrigo ahumada <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> dijo:
> >rodrigo ahumada escribió:

> >> > Ni tanto mas feo que la version C.
> >> 
> >> Ambos leguajes pecan al final. Por que @#%^&[EMAIL PROTECTED] llaman 
> >> "void" a un
> >> procedimiento?
> 
> > Hmm, los procedimientos no existen, solo existen las funciones que no
> > retornan ningun valor ;-)

> ¿que no era al revés? 

> las funciones no existen, todos son procedimientos, solo que algunos
> dejan valores en registros del CPU, o en la RAM, o en ambos...  por algo
> en algunos ensambladores existe la palabra PROC y no FUNC...

Eso es un detalle de la arquitectura en la que tradicionalmente implementan
C, no una caracteristica propia de C.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
From [EMAIL PROTECTED]  Wed Dec  5 17:51:12 2007
From: [EMAIL PROTECTED] (Enrique Herrera Noya)
Date: Wed Dec  5 18:15:43 2007
Subject: : Ocultar Passwords a produccion.
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>


Estimados, mi ultima consulta aqui fue respecto de un cliente para jabber (y
ya vieron lo que ocurrio (y esta ocurriendo)). Finalmente, se opto por
openfire y spark como cliente, lejos las discusiones respecto a la
performance del modelo, ya esta implementado y camina /de pelos/. Gracias a
todos lo que dieron sus opiniones.

Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios
con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como
escondo las password (y usuarios) de las db a los programas y usuarios?. Es
decir, pe. al configurar el acceso a mysql para un servicio web (LAMP),

definiendo funcion conectar 
y eso que utilice quien programe (suponiendo php)
y lo dejas en un directorio paralelo al del sitio y accediendo al php via  alias

algo asi:

/wuebs/coneccion/conecta.php
/wuebs/sitio/config.php

en config.php tienes 
require (dominio/conecto/conecta.php)

y en apache tienes
Alias /conecto/ /wuebs/coneccion



necesariamente debo configurar en un file la passwordm user y database que
utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones
cliente-servidor, con archivos de configuracion en cada cliente, o bien (en
el caso sql server) odbc, en ese caso no existe manera de encriptar las
password, y al menos debe conocerla el desarrollador/analista de la
aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un
archivo de configuracion. Mi problema es que necesito que estas password no
sean conocidas por nadie, ni siquiera el admin del sistema (password
bipartida) y el dia de mañana poder cambiarlas de manera transparente para
los usuarios.

He hecho monos, tirado lineas y buscado en san google, pero ando medio
perdido. Espero me puedan orientar.

Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la
autenticacion, es decir:

SERVER(user, pass)<:>**ALGO**<:>CLIENTE(user, _clave_)

donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario
de dominio, etc.

De antemano, muchisimas gracias.

-- 
Saludos, LSM.
Existen 10 tipos de personas:
los que entienden binarios y los que no

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-05 Por tema rodrigo ahumada 


- Mensaje original 
De: Rodrigo Fuentealba <[EMAIL PROTECTED]>
>> Para: Discusion de Linux en Castellano 
>> Enviado: martes 4 de diciembre de 2007, 18:47:27
>> Asunto: Re: Benchmarking en distintos lenguajes [ Era algo así como
 cliente en  jabber... ]
>>
>> >rodrigo ahumada escribió:
>>
> >> > Ni tanto mas feo que la version C.
> >>
> >> Ambos leguajes pecan al final. Por que @#%^&[EMAIL PROTECTED] llaman 
> >> "void" a
 un
> >> procedimiento?

>¿Porque no quieren devolver nada?

pero es un procedimiento, ni si quiera se debe pensar en "devolver"...

>> > Hmm, los procedimientos no existen, solo existen las funciones que
 no
>> > retornan ningun valor ;-)
>>
>> ¿que no era al revés?
>>
>> las funciones no existen, todos son procedimientos, solo que algunos
 dejan valores en registros del CPU, o en la RAM, o en >ambos...

>No. Todo son funciones; las funciones pueden devolver un tipo de dato
>cualquiera, aunque éste sea "void" (nada).
>Te recomendaría algo denso relacionado con C, pero por esta clase de
>errores, ve al "Aprenda C como si estuviera en Primero".

¿cuáles errores? ¿el no comulgar con el dogma C? 

>> por algo en algunos ensambladores existe la palabra PROC y no FUNC...

>Porque no estamos hablando de ensambladores, sino del lenguaje C, me
>imagino que entiendes la diferencia, ¿verdad?

en realidad no se está hablando de eso, se está hablando de cuál los dos 
lenguajes (C o java) presenta menos cosas incomprensbles a un novato, supongo 
que leíste los correos anteriores...

>De hecho, lo que generalmente en orientación a objetos en PHP 5 se le
>llama "métodos" también se declara como "function"; es la forma del
>lenguaje de denominarla, nada más que eso.

eso muestra que el primer lenguaje que aprendieron los creadores de PHP 
probablemente fue C.
Eso se llama Impronta, y explica harto este tipo de discusiones de que cual 
lenguaje es mas santo.







  Tarjeta de crédito Yahoo! de Banco Supervielle.
Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. 
www.tuprimeratarjeta.com.ar

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-04 Por tema rodrigo ahumada 


- Mensaje original 
De: Alvaro Herrera <[EMAIL PROTECTED]>
Para: Discusion de Linux en Castellano 
Enviado: martes 4 de diciembre de 2007, 18:47:27
Asunto: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en  
jabber... ]

>rodrigo ahumada escribió:

>> > Ni tanto mas feo que la version C.
>> 
>> Ambos leguajes pecan al final. Por que @#%^&[EMAIL PROTECTED] llaman "void" 
>> a un
>> procedimiento?

> Hmm, los procedimientos no existen, solo existen las funciones que no
> retornan ningun valor ;-)

¿que no era al revés? 

las funciones no existen, todos son procedimientos, solo que algunos dejan 
valores en registros del CPU, o en la RAM, o en ambos...
por algo en algunos ensambladores existe la palabra PROC y no FUNC...


 




  Tarjeta de crédito Yahoo! de Banco Supervielle.
Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. 
www.tuprimeratarjeta.com.ar

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-04 Por tema rodrigo ahumada 


- Mensaje original 
De: Horst H. von Brand <[EMAIL PROTECTED]>
Para: Discusion de Linux en Castellano ; Franco 
Catrin L. <[EMAIL PROTECTED]>
Enviado: martes 4 de diciembre de 2007, 13:24:12
Asunto: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en  
jabber... ]

[...]

> Que es esa basura de "public class"? Porque el archivo se tiene que
 llamar
> asi? Que es "public static void"? Porque "System.out"? Y la larga lista
 de
> etc que aparecen en cuanto quieres leer algo, o definir tus propios
 datos.

> Elegante. Clasico. ;-)

> Ni tanto mas feo que la version C.


Ambos leguajes pecan al final. Por que @#%^&[EMAIL PROTECTED] llaman "void" a 
un procedimiento?
 






  Tarjeta de crédito Yahoo! de Banco Supervielle.
Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. 
www.tuprimeratarjeta.com.ar

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-04 Por tema Pedro GM 
Horst H. von Brand escribió:
> 
>>>  OOP es para problemas
>>> /muy/ grandes, en otras cosas es un perfecto desperdicio. Y como el mechon
>>> promedio escribe programas de una a dos docenas de lineas, no uno o dos
>>> centenares de miles de lineas, ...
> 
>> El problema posterior es exorcisarlo para que pueda aplicar OOP y sea
>> capaz de abordar aplicaciones reales.
> 
> Y? Acaso con hacerlo escribir una funcion en una clase que lee 3 numeros y
> escribe la suma sabe OOP?
> 

Lo que muchos se la creen...

>> Tengo una opinion muy humilde
>> y personal y es que la cantidad de desastres que se ven en OOP son porque
>> a la hora de tener que usarlo, el personaje en cuestion tiene poca
>> experiencia en OOP
> 
> "No tiene la menor idea de que se trata" suele ser mas cercano a la
> verdad...
> 
>>debido a su "deformacion profesional" y no es capaz de
>> reconocer cuando esta cayendo en cosas como over-design/engineering.
> 
> En eso cae todo mal profesional. Y, lamentablemente, la inmensa mayoria de
> los "programadores" debieran dedicarse a plantar papas, asi resultarian mas
> productivos para la sociedad.
> 

Triste pero cierto...

>>  Si
>> los niños aprendieran desde mechones que la mejor solución no es
>> necesariamente la que se le ocurrió, y que existen patrones de diseño
>> requetecontraprobados las cosas serían muy distintas.
> 
> Metele en la cabezota a un mechon (o no tanto...) que lo que intenta hacer
> esta requete-recontra-hecho... metele en la cabeza al profe correspondiente
> que la gente no /escribe/ programas, /modifica/ programas, o debe trabajar
> /en el estilo/ o /con lo que trae/ el ambiente en que trabaja...
> 

Ese es una de las discusiones que siempre encuentro 

En realidad la enseñanza de la programacion deberia aplicarse en ese 
sentido, uno en realidad haciendo un software a medida se toma mucho 
tiempo en I+D y la reusabilidad tiende a cero. ademas de las enormes 
pifias que puede contener ese codigo...

IMHO creo que el enfoque deberia ir por motivar a los alumnos a 
integrarse a un proyecto y ahi "IN SITU" aprender como es una buena 
programacion, y como es mas beneficioso tanto en conocimiento, seguridad 
y productividad el utilizar lo que otros (muchos muchos) han probado y 
archiprobado que es efectivo y eficiente y de ahi recien empezar los 
efuerzos para Ampliar o Reutilizar parte del codigo conocido para algun 
fin especifico.




 El Kernighan y Ritchie "The C Programming Language" es un
> clasico, con merecida razon. Libros como el "Software Tools" de Kerighan y
> Plaugher (no la version en Pascal!) son escenciales para aprender a
> programar bien. Y en  hay harto sobre la
> cultura C.

Muy interesante referencia, gracias.

-- 
.:: Pedro:G:M ::.
Linux User #397462
From [EMAIL PROTECTED]  Tue Dec  4 15:35:20 2007
From: [EMAIL PROTECTED] (Leonardo Soto M.)
Date: Tue Dec  4 15:38:17 2007
Subject: Benchmarking en distintos lenguajes
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Dec 4, 2007 2:30 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:

[...]

> He visto aplicaciones grandes escritas en C (en empresas), y el
> problema con dejar eso en manos de la voluntad del programador es que
> se pueden perder horas o dias porque algun pastel olvido poner un "*".
>
> En el caso de C# y Java no puedes mezclar tipos con y sin referencia,
> por lo tanto no existe tal mezcolanza.

Pero tuvieron la mala idea de permitir referencias nulas por todos
lados, por lo que en la práctica igual se da una mezcolanza de
referencias buenas y referencias nulas. Y se pierden horas por que
algún pastel devolvió un null donde no debía...

> O es o no es, y el programador
> tiene que ser muy explicito cuando quiera que eso que es, deje de
> serlo.  (boxing/unboxing).

Los amigos de Sun no encontraron tan cool esta parte, y ahora (Java
1.5+) el boxing/unboxing lo hace el compilador de forma implícita, por
lo que todas estas cosas son válidas

 int i = new Integer(8);
 Integer i = 8;
 map.put("foo", 8);
 int j = map.get("foo");

--
Leo Soto M.
http://blog.leosoto.com

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-04 Por tema Roberto Bonvallet 
El 30/11/07, Patricio Morales <[EMAIL PROTECTED]> escribió:
> Con lo que discrepo que exista mayor cantidad
> de código para FORTRAN que para Pascal.

Los científicos y matemáticos ocupan harto código en Fortran.  Supongo
que gran parte es código implementado cuando Fortran era el único
lenguaje disponible, y que nadie se dio la lata de reimplementar
porque el rendimiento era excelente.  Ver
http://en.wikipedia.org/wiki/Fortran#The_legacy_of_FORTRAN

Un amigo físico me pidió que lo ayudara a instalar unas extensiones
para Mathematica.  Justo cuando le estaba comentando que me parecía
bien que por fin los científicos estaban usando lenguajes de alto
nivel, el instalador me reclamó que no estaba instalado el compilador
de Fortran :)  La biblioteca estaba implementada en Fortran y se podía
enlazar desde Mathematica o C++.  Y me imagino que hay muchas más
aplicaciones cuyas funciones críticas están implementadas en Fortran,
aunque eso sea invisible para uno.

Saludos,
-- 
Roberto Bonvallet

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-02 Por tema Roberto Bonvallet 
El 2/12/07, Patricio Morales <[EMAIL PROTECTED]> escribió:
> (Dudo que alguien use PROLOG
> para crear  un SIA y conectarse a un motor de datos ).

Hace un par de meses vi un manual medio ochentero de Turbo Prolog que
claramente estaba pensado para desarrollar aplicaciones de negocios.
No recuerdo haber visto nada relacionado con bases de datos, pero sí
explicaban cómo crear interfaces gráficas con ventanitas y todo.  No
se veía tan marciano como uno podría pensar; después de todo, las
reglas de inferencia de Prolog no son tan diferentes de las funciones
de otros lenguajes.

Saludos,
-- 
Roberto Bonvallet

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-02 Por tema Patricio Morales 
El día 2/12/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:

Creo que deberías ver la afirmación que motivó mi comentario sobre el uso o
no de determinados lenguajes.  Afirmación que tu mismo hiciste
contradiciendo lo que dices ahora.   No quiero darle muchas vueltas al
asunto, estoy totalmente de acuerdo con lo que escribiste ahora

.Saludos

-Franco

No ,no se a que te refieres ,y yo también quiero dar por cerrado este
tema.Solo afirmar que  hay  lenguajes en  los cuales es mas factible
trabajar con bases de datos que otros,y bueno que hay lenguajes que fueron
creados con propósitos especiales como PROLOG (Dudo que alguien use PROLOG
para crear  un SIA y conectarse a un motor de datos ).

Saludos


Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Sun Dec  2 22:39:43 2007
From: [EMAIL PROTECTED] (Patricio Morales)
Date: Sun Dec  2 22:42:35 2007
Subject: LINUX VS WINDOWS, la hora de la verdad se acerca
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El día 2/12/07, Hugo Figueroa R. <[EMAIL PROTECTED]> escribió:QUE SON
TONTOS GRAVES ALGUNOS ACA

Bueno y ¿Quien Ganó el partido ?,¿los de Microsoft o los de Linux?,¿o fué
empate?

Saludos.



-- 
Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Sun Dec  2 21:41:22 2007
From: [EMAIL PROTECTED] (Matias Valdenegro T.)
Date: Sun Dec  2 22:46:32 2007
Subject: Desarrollo para PIC's Microchip en linux
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El Domingo 02 Diciembre 2007, Alejandro Weinstein escribió:
> On Dec 2, 2007 1:48 PM, Aldrin Gonzalo Martoq Ahumada
>
> <[EMAIL PROTECTED]> wrote:
> > Estimados, estoy en un miniproyecto personal que consiste en un pedal
> > midi programable. Para ello, compre un microprocesador PIC18F4550 de
> > Microchip (alrededor de $8.000-9.000 y un PIC16F876A de respaldo)
>
> Estas amarrado a los PIC por alguna razon? (aparte de que ya compraste
> los PIC y el programador :( ).
>
> Si puedes te recomiendo que utilizes microcontroladores AVR
> (fabricados por Atmel). Estan en el mismo nicho que los PIC, pero
> tienen, IMO, varias ventajas. Una de ellas es que existe un port de
> gcc para los AVR (avr-gcc), que funciona de pelos. En Chile puedes
> comprarlos en www.olimex.cl .

Bastante interesante, existe software para grabarlos desde Linux tambien?

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-12-02 Por tema Patricio Morales 
>
> No, yo me refiero a aplicaciones, ya que herramientas de desarrollo
> siempre van a haber, por ultimo un compilador/interprete a secas.
>
> Por ejemplo si voy a una empresa de servicios, voy a encontrar
> aplicaciones en Pascal corriendo allá?? o en la banca, retail, etc.


Por supuesto que no,ya que Pascal a secas es un lenguaje destinado a la
enseñanza de la Programación.Pero si hay empresas pequeñas que tienen sus
sistemas desarrollados en Delphi
que es el sucesor de Pascal para Windows.Por ejemplo acá en la novena
región,Espex Ingeniería
tiene su sistema comercial desarrollado en Delphi con Interbase como Base de
Datos.

Saludos.



-- 
Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Sun Dec  2 15:06:05 2007
From: [EMAIL PROTECTED] (Patricio Morales)
Date: Sun Dec  2 15:08:57 2007
Subject: =?iso-8859-1?q?Re=3A_Re=3A_Benchmarking_en_distintos_lenguajes_?=
=?iso-8859-1?q?=5B_Era_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_?=
=?iso-8859-1?q?=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El día 2/12/07, Patricio Morales <[EMAIL PROTECTED]> escribió:
>
>
>
> > No, yo me refiero a aplicaciones, ya que herramientas de desarrollo
> > siempre van a haber, por ultimo un compilador/interprete a secas.
> >
> > Por ejemplo si voy a una empresa de servicios, voy a encontrar
> > aplicaciones en Pascal corriendo allá?? o en la banca, retail, etc.
>
>

Solo como un agregado: Puedes escoger la herramienta que mejor estimes
conveniente
y esta puede ser cualquiera que te dé la posibilidad de conexión a un motor
de Datos
(Oracle,Sybase,Interbase,Db2,Postgresql,etc).Pero donde radica toda la
potencia para que tu Sistema
realice procesos complejos y de gran demanda es en este último Item donde
puedes manejar procedimientos almacenados,triggers dede el motor de Datos y
donde el software sólo se encarga de hacer las llamadas correspondientes a
estos procedimientos,y donde Oracle lleva
las de ganar  .Eso si ,se deben obviamente considerar las posibilidades
económicas de la Empresa
donde se desarrollará el Sistema ,ya que no cualquier Empresa se puede dar
el lujo de gastar
US$3 en una licencia de Oracle.
En resumen ,el Software es una cáscara,donde esta la potencia es en el Motor
de Base de Datos.

Saludos.

-- 
Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Sun Dec  2 15:27:00 2007
From: [EMAIL PROTECTED] (Patricio Morales)
Date: Sun Dec  2 15:29:52 2007
Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era?=
=?iso-8859-1?q?_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

2007/11/29, Rodrigo Fuentealba <[EMAIL PROTECTED]>:
>
> 2007/11/29, Franco Catrin L. <[EMAIL PROTECTED]>:
>
> Medio difícil de hacer los clásicos listados impresos en 80 líneas
> como en COBOL no más, pero se ve entrete <-!
> Yo no soy tan viejito, lo más oldie que programé fue Cobol...
>

Programar en COBOL  es un cacho(aún hay programadores en Cobol,y uno de
ellos es
un compañero de carrera,que trabaja para una empresa de Distribución
Electrica).Me acuerdo
que cuando estudié Técnico en Programación,hacer un Simple Menú en RM
COBOL85 para DOS
me demoraba casi dos horas,en comparación con los 15 o 20 minutos que me
demoraba
en hacerlo en Pascal.Y todo el tiempo que me demoraba,era gastado en:digitar
los enormes listados de los programas, corregir los errores que arrojaba el
interprete,y en adivinar porqué arrojaba error de compilación.Eso si deben
ser muy contados los programadores en Cobol,y relativamente muy bien
cotizados
por las Empresas que requieren de sus servicios.

Saludos.




-- 
Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Sun Dec  2 17:07:03 2007
From: [EMAIL PROTECTED] (Aldrin Gonzalo Martoq Ahumada)
Date: Sun Dec  2 17:16:21 2007
Subject: =?iso-8859-1?q?Re=3A_Re=3A_Benchmarking_en_distintos_lenguajes_?=
=?iso-8859-1?q?=5B_Era_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_?=
=?iso-8859-1?q?=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-30 Por tema Patricio Morales 
Pero esas son cosas que estan muertas.  Que pasa con aplicacionesexistentes?

Franco,actualmente existen implementaciones de Pascal para Linux:Proyecto
FreePascal
y el Proyecto Lazarus:Este último posee un Ide para desarrollar programas
"visuales" en
Linux.
Y por último existe Kilyx:(implementación del lenguaje Delphi ) para Linux

Eso si te refieres a herramientas de programación

Saludos


-- 
Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Fri Nov 30 19:23:16 2007
From: [EMAIL PROTECTED] (Jorge Palma)
Date: Fri Nov 30 19:26:05 2007
Subject: Alternativa xvidcap
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Nov 30, 2007 4:02 PM,  <[EMAIL PROTECTED]> wrote:
> Saludos a todos hay una buena alternativa para xvidcap, gracias
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>

recordmydesktop

Salu2


-- 
Jorge Palma Escobar
Ingeniero de Sistemas
Red Hat Linux Certified Engineer
Certificate Nº 804005089418233

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-30 Por tema Horst H. von Brand 
Ricardo Mun~oz A. <[EMAIL PROTECTED]> wrote:
> Horst H. von Brand wrote:
> > [Corregidas algunas atribuciones (> > ... >) que claramente estaban mal...]
> > Patricio Morales <[EMAIL PROTECTED]> wrote:
> >> El día 28/11/07, Horst H. von Brand <[EMAIL PROTECTED]> escribió:
> >>> Leonardo Soto M. <[EMAIL PROTECTED]> wrote:
>  On Nov 27, 2007 5:12 PM, Horst H. von Brand <[EMAIL PROTECTED]>
>  wrote:
> > Rodrigo Fuentealba <[EMAIL PROTECTED]> wrote:

[...]

> > Huh... hay una _larga_ lista de lenguajes que ni aparecen en "listas de
> > lenguajes". Una de las razones de Ada es que DoD usaba (para aplicaciones
> > tiempo real, mas que nada) algo de 800 (!) lenguajes diferentes.

> aca hay un listado de lenguajes usados en proyectos open source:
> 
> http://www.ohloh.net/languages?sort=projects&commit=Sort

Faltan ObjectiveC, FORTRAN al menos (si, hay codigo substancial escrito en
eso; probablemente bastante mas FORTRAN que Pascal). Ni que decir de
lenguajes menores (OCaml, Haskell, FORTH, ...)
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
From [EMAIL PROTECTED]  Fri Nov 30 15:38:02 2007
From: [EMAIL PROTECTED] (Patricio Morales)
Date: Fri Nov 30 15:40:55 2007
Subject: =?iso-8859-1?q?Re=3A_Re=3A_Benchmarking_en_distintos_lenguajes_?=
=?iso-8859-1?q?=5B_Era_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_?=
=?iso-8859-1?q?=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

>
> Faltan ObjectiveC, FORTRAN al menos (si, hay codigo substancial escrito en
> eso; probablemente bastante mas FORTRAN que Pascal). Ni que decir de
> lenguajes menores (OCaml, Haskell, FORTH, ...)


Pascal (específicamente Turbo Pascal )fue el primer lenguaje con el que
aprendí a programar (Anteriormente en muchas Instituciones de Educación
Superior tanto en Chile como en el Mundo ,era el lenguaje por excelencia que
se usaba para la enseñanza de la programación) despues aprendí a programar
en Turbo C,C,C++,Clipper,etc.Con lo que discrepo que exista mayor cantidad
de código para FORTRAN que para Pascal.

Me acuerdo que uno de los sitios que me gustaba visitar (y que aun visito)
es el servidor
garbo de la Universidad de Vaasa en Finlandia.En este servidor en la parte
de programación uno se podía descargar una buena cantidad de códigos fuente
de Pascal (archivos .pas)lecciones de Pascal,además de un montón de
Utilerías para Unix/Linux
MS-DOS y Windows.





-- 
Patricio Morales Fariña
Técnico en Computación
Alumno Ing. Informática (Técnicos Vespertino)
Universidad de los Lagos
045-219291- Temuco Chile
cel 78732062-
From [EMAIL PROTECTED]  Fri Nov 30 16:02:55 2007
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Date: Fri Nov 30 16:05:42 2007
Subject: Alternativa xvidcap
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Saludos a todos hay una buena alternativa para xvidcap, gracias



This message was sent using IMP, the Internet Messaging Program.

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-29 Por tema Rodrigo Fuentealba 
2007/11/29, Franco Catrin L. <[EMAIL PROTECTED]>:
>
> Y no olvidemos Whitespace : http://compsoc.dur.ac.uk/whitespace/
> Me hubiera servido esos dias en que no pude usar lentes de contacto ;)

Medio difícil de hacer los clásicos listados impresos en 80 líneas
como en COBOL no más, pero se ve entrete <-!

Yo no soy tan viejito, lo más oldie que programé fue Cobol... (Ah,
don't forget the good old Atari BASIC)...

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-29 Por tema Franco Catrin L. 
Horst H. von Brand escribió:
> Huh... hay una _larga_ lista de lenguajes que ni aparecen en "listas de
> lenguajes". Una de las razones de Ada es que DoD usaba (para aplicaciones
> tiempo real, mas que nada) algo de 800 (!) lenguajes diferentes.
>
> Alguien sabe que era UPL? O se tropezo con FORTH? APL era una delicia... si
> tenias el teclado marciano del caso (y /chancha/ maquina). Oberon? Bliss
> (lindo lenguaje, ese...)? PL/1 (Urgh)? PL/360? No se si TECO califica como
> "lenguaje", pero debiera... Ni que hablar de curiosidades arqueologicas
> como BCPL y B, que a los C-istas les deben sonar para algo (demas que
> hugueteando hallan compiladores para eso hoy). Hasta D hay...
>   
Y no olvidemos Whitespace : http://compsoc.dur.ac.uk/whitespace/
Me hubiera servido esos dias en que no pude usar lentes de contacto ;)
--
Franco

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-27 Por tema Horst H. von Brand 
Rodrigo Fuentealba <[EMAIL PROTECTED]> wrote:

[...]

> jajajajajaja yeah. Creo que los programadores Java se engrupen mucho
> con lo difíciles que pueden llegar a ser sus aplicaciones;

Un mal programador escribira basura sea cual sea el lenguaje que use para
ello.

>alguien me
> comentó que, de hecho, el inventor de la programación orientada a
> objetos se hizo netamente con el objetivo de ganar más plata nada más.

Falso. OOP es la mejor manera conocida de organizar la solucion eficiente
de problemas grandes y complejos (como un nucleo de un sistema operativo,
un ambiente grafico, o un paquete de oficina completo; digamos unas
poquitos a muchos millones de lineas de codigo). Claro que (igual que
siempre) la parte mas dura es la de "disen~ar", y como (casi) nadie se da
el trabajo de siquiera pensar la organizacion antes de programar (y, a
decir verdad, como es imposible saber cual debera ser la organizacion antes
de intentar tres formas y desechar cinco mas), los resultados estan a la
vista...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
From [EMAIL PROTECTED]  Tue Nov 27 17:31:45 2007
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Tue Nov 27 17:34:35 2007
Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_?=
=?iso-8859-1?q?Era_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Alejandro Weinstein <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007 10:23 AM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
> > Segun entiendo esos no son compilados reales, runcobol es un interprete,
> > no una maquina virtual.

> Cual es la diferencia entre un interprete y una maquina virtual? En
> google no pude encontrar una respuesta clara. Encontre por ejemplo:

Ninguna.

Un procesador no es mas que un interprete del lenguaje de maquina del caso,
implementado en silicio, una maquina virtual es el mismo interprete pero
implementado en C (o el lenguaje du jour). Y al otro extremo, nosotros
programamos contra la "maquina virtual C", que se implementa (normalmente,
incidentalmente) via gcc y otras tonteras mas. Nada impide que tal cosa (o
incluso lenguajes mucho mas complejos) se interpretara directamente

Generalmente se hace la distincion que maquina virtual interpreta un
lenguaje de "bajo nivel" == "nivel de maquina", mientras un interprete
maneja un lenguaje de "alto nivel" == "lenguaje de a deveras". Pero es una
distincion de grado, no cualitativa. He visto llamar interpretes a
implementaciones de lenguajes de relativamente bajo nivel, como el lenguaje
interno de Perl o la maquina virtual comunmente usada para explicar Prolog,
e incluso algo tan elemental como el "threaded code" popular en FORT
(basicamente, una lista de direcciones de subrutinas a llamar y pocazo
mas), y a cosas como bash e incluso un interprete de C (!). En rigor, Perl,
Ruby, Python se compilan a una representacion interna que luego se
interpreta, no son interpretes directos; los shell por otro lado (y los
BASIC de antan~o) toman el codigo fuente, lo analizan y ejecutan linea a
linea.

Por otro lado, hay implementaciones en silicio de JVM, y del interprete
interno de FORT; y por el otro lado cosas como Bochs, la divertida CPU que
desarrollaba Transmeta, y supongo recordaran las epocas en que aun no
habian AMD64 para la venta pero ya Red Hat ofrecia su distribucion para esa
maquina (desarrollada en muy buena parte sobre emuladores). Y, last but not
least, esta la mitologica MMIX, para la cual incluso hay un gcc
perfectamente funcional (parte de la distribucion oficial en fuente,
incluso). Solo que nadie se ha puesto con las lucas para realizar esa linda
arquitectura...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
From [EMAIL PROTECTED]  Tue Nov 27 16:40:09 2007
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Tue Nov 27 17:43:28 2007
Subject: disclamers en correos
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Victor Hugo dos Santos <[EMAIL PROTECTED]> wrote:
> estoy buscando en los históricos de la lista, un hilo que comentaba
> sobre los "disclamers" que vienen en algunos correos 

> estoy buscando, para ver se encuentro algún comentario sobre el
> valido/invalido/estúpido/ingenioso que puede ser esto para un empresa.

Mira p.ej. en

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-19 Por tema Roberto Bonvallet 
El día 17/11/07, Rodrigo Fuentealba <[EMAIL PROTECTED]> escribió:
> Por lo visto, el personaje de psyco quiere trabajar más en PyPy que en
> Psyco "itself".
>
> ¿Lo has probado?

No lo he probado, pero en comp.lang.python ocasionalmente hay tipos
que reportan mejoras de rendimiento bastante importantes (léase un
orden de magnitud) sólo por usar psyco en sus programas sin modificar.
 Claro que esto sólo sirve para código intensivo en cómputo.
Seguramente una aplicación web o una de escritorio no gozarían de
mejora alguna.

> ¿Cómo podríamos hacer benchmarking? (¿El clásico "time && programa.sh
> && time, como las guaguas, o alguien tiene una mejor idea?)

En Python se acostumbra a usar el módulo timeit para medir y comparar
tiempos de ejecución.

-- 
Roberto Bonvallet

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-17 Por tema Franco Catrin L. 
Rodrigo Fuentealba escribió:
> El 16/11/07, Alejandro Weinstein <[EMAIL PROTECTED]> escribió:
>   
>> On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>> 
>>> El segundo link casi me deja ciego ;)
>>>   
>> Perdon. Me olvide de advertir que habia que ponerse lentes oscuros.
>>
>> [sobre la diferencia entre maquina virtual e interprete]
>>
>> Aun no me queda del todo clara la diferencia. Por ejemplo, hay alguna
>> diferencia de fondo entre un interprete Python ejecutando un archivo
>> .pyc o .pyo (no un .py) y una maquina virtual java ejecutando
>> bytecodes?
>> 
>
> Diferencia de fondo no hay mucha. Según [1], inclusive hay similitudes
> con Java y .NET:
>
> 1.- Se compila a bytecode que es compatible entre arquitecturas (yo
> tomo un .pyc en Windows y lo paso a Linux y funciona).
>
> 2.- Se hacen algunas optimizaciones pequeñas al código Python.
>
> 3.- De 1.- se puede inferir que no es necesario que Python como
> intérprete deba destripar cadenas y revisar sintaxis, lo cual también
> es una optimización a la hora de interpretar y cargar el archivo.
>   

Eso se hace solo una vez y se genera el .pyc.  Despues de eso actua el 
interpete del .pyc que "ejecuta" el codigo generado [1], pero no hay 
JIT, entonces se lee un bytecode y se ejecuta una funcion del interperte 
de python, luego se lee el siguiente bytecode y se ejecuta otra fucnion 
del interprete de python, y asi sucesivamente.  Eso es lo que se supone 
hace Python/eval.c [3]

Es no implica que el lenguaje sea necesariamente lento, solo dificulta 
las optimizaciones que se puedan realizar en tiempo de ejecucion.

> Ahora, una diferencia sustancial debe ser la manera en que Java y
> Python reservan la cantidad de memoria necesaria para su ejecución,
> pero eso ya es hilar demasiado fino y... es viernes.
>   

Lo de la memoria reservada se puede cambiar en java mediante el 
parametro -Xmx, pero hay que considerar como afecta eso a la eficiencia 
del garbage collector y la fragmentacion de la memoria que pide al 
sistema operativo.  Revisar tambien otro link que di sobre GC's

La diferencia sustancial esta en la generacion de codigo nativo a partir 
del .pyc, eso es algo que python no hace, y probablemente por la 
naturaleza del lenguaje tampoco conviene hacer [4]

[1] http://alumni.media.mit.edu/~tpminka/patterns/python/
[2] http://alumni.media.mit.edu/~tpminka/patterns/python/bytecode.txt
[3] http://svn.pythonmac.org/python24/python24-fat/Python/ceval.c
[4] http://en.wikipedia.org/wiki/Dynamic_language

Saludos
--
Franco
From [EMAIL PROTECTED]  Sat Nov 17 13:53:50 2007
From: [EMAIL PROTECTED] (Roberto Bonvallet)
Date: Sat Nov 17 14:25:51 2007
Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era?=
=?iso-8859-1?q?_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El día 17/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
>
> La diferencia sustancial esta en la generacion de codigo nativo a partir
> del .pyc, eso es algo que python no hace, y probablemente por la
> naturaleza del lenguaje tampoco conviene hacer [4]
>

Hay un compilador JIT para Python que, si bien no hace exactamente lo mismo
que el de Java, también trabaja optimizando en tiempo de ejecución.

http://psyco.sourceforge.net/introduction.html

PyPy, la implementación de Python en Python, también viene con un compilador
JIT:

http://codespeak.net/pypy/dist/pypy/doc/jit.html

-- 
Roberto Bonvallet
From [EMAIL PROTECTED]  Sat Nov 17 14:41:47 2007
From: [EMAIL PROTECTED] (Rodrigo Fuentealba)
Date: Sat Nov 17 14:44:34 2007
Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era?=
=?iso-8859-1?q?_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El 17/11/07, Roberto Bonvallet <[EMAIL PROTECTED]> escribió:
> El día 17/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> >
> Hay un compilador JIT para Python que, si bien no hace exactamente lo mismo
> que el de Java, también trabaja optimizando en tiempo de ejecución.
>
> http://psyco.sourceforge.net/introduction.html

Por lo visto, el personaje de psyco quiere trabajar más en PyPy que en
Psyco "itself".

¿Lo has probado?
¿Cómo podríamos hacer benchmarking? (¿El clásico "time && programa.sh
&& time, como las guaguas, o alguien tiene una mejor idea?)

> PyPy, la implementación de Pytho

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 17/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> Alejandro Weinstein escribió:
> > On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
> >
> >> El segundo link casi me deja ciego ;)
> >>
> > [sobre la diferencia entre maquina virtual e interprete]

.java -> compilador -> bytecode -> JIT -> binario x86

> Luego tu procesador ejecuta el binario x86 generado como si hubiera sido
> hecho en C/ASM

.py -> compilador -> tokens -> interprete de tokens -> funciones del intérprete

> No hay generacion de codigo nativo, sino que el inteprete en base a los
> tokens comienza a ejecutar distintas secciones de si mismo.  Imaginate
> un gigante "if" o un gigante "switch/case" que va consumiendo tokens.

Excelente respuesta! Me quedó mucho más claro.

Yo pensaba que el bytecode de Java (CAFEBABE) se interpretaba igual
que el de Python.

Los conceptos de Java que tengo son lo que aprendí en el instituto,
que no fue mucho... de hecho tuve la mala suerte de que el profe se
iba a ir a fin de semestre así que tenía cero ganas de enseñarnos a
trabajar con Swing/AWT y con Java Server Pages :(

> Para el caso de python puedes mirar en Python/eval.c
> http://svn.pythonmac.org/python24/python24-fat/Python/ceval.c
>
> Para el caso de JIT hay una charla de Miguel de Icaza con ejemplos y
> todo, incluso generando bytecode a partir de Python, una de las gracias
> de Mono y .NET

¿La que dio en la UOC? Buenísima.

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Alejandro Weinstein <[EMAIL PROTECTED]> escribió:
> On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
> >
> > El segundo link casi me deja ciego ;)
>
> Perdon. Me olvide de advertir que habia que ponerse lentes oscuros.
>
> [sobre la diferencia entre maquina virtual e interprete]
>
> Aun no me queda del todo clara la diferencia. Por ejemplo, hay alguna
> diferencia de fondo entre un interprete Python ejecutando un archivo
> .pyc o .pyo (no un .py) y una maquina virtual java ejecutando
> bytecodes?

Diferencia de fondo no hay mucha. Según [1], inclusive hay similitudes
con Java y .NET:

1.- Se compila a bytecode que es compatible entre arquitecturas (yo
tomo un .pyc en Windows y lo paso a Linux y funciona).

2.- Se hacen algunas optimizaciones pequeñas al código Python.

3.- De 1.- se puede inferir que no es necesario que Python como
intérprete deba destripar cadenas y revisar sintaxis, lo cual también
es una optimización a la hora de interpretar y cargar el archivo.

Ahora, una diferencia sustancial debe ser la manera en que Java y
Python reservan la cantidad de memoria necesaria para su ejecución,
pero eso ya es hilar demasiado fino y... es viernes.

[1] http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Alejandro Weinstein 
On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>
> El segundo link casi me deja ciego ;)

Perdon. Me olvide de advertir que habia que ponerse lentes oscuros.

[sobre la diferencia entre maquina virtual e interprete]

Aun no me queda del todo clara la diferencia. Por ejemplo, hay alguna
diferencia de fondo entre un interprete Python ejecutando un archivo
.pyc o .pyo (no un .py) y una maquina virtual java ejecutando
bytecodes?

Alejandro.
From [EMAIL PROTECTED]  Fri Nov 16 18:21:14 2007
From: [EMAIL PROTECTED] (Xavier Andrade)
Date: Fri Nov 16 19:04:23 2007
Subject: =?utf-8?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era_a?=
 =?utf-8?q?lgo_as=C3=AD_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>
> Supongo que es porque rompen el principio de localidad [1].
>

Principalmente es el costo asociado a llamar una funcion, el paso de
argumentos, guardar registros, etc.

>
> Yo me refería a otros casos pero igual es interesante:
> La máquina virtual de Java puede aplicar inline en algunos métodos siempre 
> y cuando estos métodos no sean sobreescritos, por ejemplo todos aquellos que 
> sean static o final... pero... además en tiempo de ejecución puede deducir 
> que un método puede ser "inlined" de forma segura, porque ya sabe que no 
> esta sobreescrito. De esta forma el programador no necesita cambiar su 
> código y es la máquina virtual quien se hace la astuta, lo malo es que hay 
> programadores que declaran todo como public. [2]
>
> Si no me equivoco los compiladores de C tambien son capaces de reconocer 
> código que conviene dejar como inline.

El problema es que en C, a diferencia de Java, la mayoria de las veces no se
tiene el codigo que se podria hacer inline. A veces no se sabra que funcion
es hasta el momento de la ejecucion (punteros a funciones o funciones
virtuales en C++)

De hecho, algunos compiladores de C/C++ o Fortran en los niveles de
optimizacion mas agresivos (normalmente con el flag -ipa), no compilan el
codigo al generar los .o, sino que al momento de enlazar juntan todas la
fuentes haciendo un analisis completo de la ejecucion para ver que se puede
hacer inline (entre otras optimizaciones), por supuesto esto toma mucho
tiempo y consume cantidades obscenas memoria.

> Y finalmente.. los problemas de rendimiento en aplicaciones de las que me 
> toca ver a mi casi siempre son debido a latencias por I/O :(
>

Bueno, si. Lo que yo menciono se da mas en codigo numerico orientado al
objeto donde la optimizacion a nivel de ejecucion en el procesador cuenta.

Saludos,

Xavier
From [EMAIL PROTECTED]  Fri Nov 16 19:10:10 2007
From: [EMAIL PROTECTED] (Alvaro Herrera)
Date: Fri Nov 16 19:12:58 2007
Subject: Benchmarking =?iso-8859-1?q?en_distintos_lenguajes_?=
=?iso-8859-1?q?=5B_Era_algo_as=ED?= como cliente en jabber... ]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Rodrigo Fuentealba escribió:
> El 16/11/07, Xavier Andrade <[EMAIL PROTECTED]> escribió:
> >
> > Claro, pero eso no es programacion orientada al objeto ni ninguna tecnica de
> > programacion sofisticada. El punto es que con POO puedes llegar a tener 
> > casos
> > equivalentes a ese.
> 
> Un método en OOP es una mera función,

Solo si tu jerarquia de clases es de un solo nivel, que no es lo que se
"estila".  Un sistema un poquito mas complejo requiere que en tiempo de
ejecucion se haga una busqueda del metodo invocado en una tabla de
metodos, y si no aparece entonces tienes que ir a la clase padre a ver
si esta implementado ahi, y asi hasta llegar al tope de la jerarquia de
clases.

-- 
Alvaro Herrera  http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)
From [EMAIL PROTECTED]  Sat Nov 17 00:13:37 2007
From: [EMAIL PROTECTED] (Franco Catrin L.)
Date: Fri Nov 16 21:16:21 2007
Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era?=
 =?iso-8859-1?q?_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Alejandro Weinstein escribió:
> On Nov 16, 2007 1:16 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>   
>> El segundo link casi me deja ciego ;)
>> 
>
> Perdon. Me ol

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> pero... además en tiempo de
> ejecución puede deducir que un método puede ser "inlined" de forma
> segura, porque ya sabe que no esta sobreescrito. De esta forma el
> programador no necesita cambiar su código y es la máquina virtual quien
> se hace la astuta, lo malo es que hay programadores que declaran todo
> como public. [2]

Con relación a la memez de algunos digitadores Java, ¿Alguien puede
ofrecer algún link sobre programación eficiente en Java? Me saldría
fácil buscar en Google, pero más que nada quiero que me recomienden
lecturas (es más como "¿tienen por ahí un buen libro para leer el
sábado cuando esté aburrido?" que "no quiero buscar en Google, denme
info", no sé si me entienden):

Yo por lo pronto encontré algunas cosas que para mí como noob en java,
aporta detalles interesantes (a lo mejor los que llevan más de 4 horas
programando en este lenguaje son cosas básicas):

- http://www.cybergrain.com/tech/writing/efficient-java.html
- http://www.java-tips.org/blog/java-se/programming-in-an-efficient-way.html

> Si no me equivoco los compiladores de C tambien son capaces de reconocer
> código que conviene dejar como inline.

http://www.gnu.org/software/gcc/gcc-4.3/changes.html

GCC tiene un early inliner.

> Y finalmente.. los problemas de rendimiento en aplicaciones de las que
> me toca ver a mi casi siempre son debido a latencias por I/O :(

Eso también es cierto.

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> Rodrigo Fuentealba escribió:
> > la máquina no tiene para
> > qué esforzarse en destripar cadenas de caracteres, en saber si
> > funciona o no, simplemente pone un puntero al principio del archivo y
> > va leyendo y cargando las bibliotecas que requiere, enlazando en
> > tiempo de ejecución y hasta el final, y recogiendo basurita.
> >
>
> Te faltó la parte en que se convierte el código de la máquina virtual a
> código de maquina "nativo" y es ahi en donde está la diferencia entre un
> interprete clasico y un interprete/compilador de bytecode de una maquina
> virtual.

Eso... intentar estar pendiente a la cantidad de desastres que hay
aquí en la oficina es una lata, no se puede pensar en nada bien.

> > A ver si con eso me explico mejor con a qué me refería con el ejemplo
> > de RUNCOBOL de hace unos e-mails atrás.
> >
> RUNCOBOL me suena a un interprete clasico no mas.  (sin JIT)

Lo que interpreta no es el código que escribe el usuario, sino el
código intermedio que se genera con RMCOBOL. Es claro que no tiene JIT
ni capacidad de decisión; está pensado así para ser todo lo rápido
posible en máquinas antiguas, no para técnicas avanzadas de
programación orientada a objetos.

-- 
Rodrigo Fuentealba Cartes

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Franco Catrin L. 
Rodrigo Fuentealba escribió:
> la máquina no tiene para
> qué esforzarse en destripar cadenas de caracteres, en saber si
> funciona o no, simplemente pone un puntero al principio del archivo y
> va leyendo y cargando las bibliotecas que requiere, enlazando en
> tiempo de ejecución y hasta el final, y recogiendo basurita.
>   

Te faltó la parte en que se convierte el código de la máquina virtual a 
código de maquina "nativo" y es ahi en donde está la diferencia entre un 
interprete clasico y un interprete/compilador de bytecode de una maquina 
virtual.

> A ver si con eso me explico mejor con a qué me refería con el ejemplo
> de RUNCOBOL de hace unos e-mails atrás.
>   
RUNCOBOL me suena a un interprete clasico no mas.  (sin JIT)

--
Franco
From [EMAIL PROTECTED]  Fri Nov 16 17:28:58 2007
From: [EMAIL PROTECTED] (Xavier Andrade)
Date: Fri Nov 16 18:12:07 2007
Subject: =?iso-8859-1?q?Re=3A_Re=3A_Benchmarking_en_distintos_lenguaje?=
 =?iso-8859-1?q?s_=5B_Era_algo_as=ED_como_cliente_en_jabber=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>


On Fri, 16 Nov 2007, Rodrigo Fuentealba wrote:
>
> Depende.
>
> Si en C haces algo así:
>
> #include 
> #define SUM(A,B)A + B
>

Claro, pero eso no es programacion orientada al objeto ni ninguna tecnica de
programacion sofisticada. El punto es que con POO puedes llegar a tener casos
equivalentes a ese.

Saludos,

Xavier
From [EMAIL PROTECTED]  Fri Nov 16 17:21:09 2007
From: [EMAIL PROTECTED] (Marcos Ramirez)
Date: Fri Nov 16 18:14:41 2007
Subject: Benchmarking en distintos lenguajes [ Era algo
=?iso-8859-1?q?as=ED?= como cliente en jabber... ]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Fri, 2007-11-16 at 17:19 -0300, Franco Catrin L. wrote:
> Rodrigo Fuentealba escribió:

> > A ver si con eso me explico mejor con a qué me refería con el ejemplo
> > de RUNCOBOL de hace unos e-mails atrás.
> >   
> RUNCOBOL me suena a un interprete clasico no mas.  (sin JIT)

Menos que eso incluso. Cobol es un lenguaje pseudocompilado y se
requiere dos pasos: rmcobol que hace el analisus sintactico/semantico y
genera el codigo objeto (.cob) que usara el run-time. RUNCOBOL solo
ejecuta este codigo objeto y no tiene capacidad de analisis mayores. 

Comparado con un lenguaje interpretado actual cobol usa archivos
intermedios (.cob) para lo que perl/php/otro hacen en memoria.

Saludos
-- 
Marcos Ramirez <[EMAIL PROTECTED]>

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Franco Catrin L. 
Alejandro Weinstein escribió:
> On Nov 16, 2007 10:23 AM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>   
>> Segun entiendo esos no son compilados reales, runcobol es un interprete,
>> no una maquina virtual.
>> 
>
> Cual es la diferencia entre un interprete y una maquina virtual? En
> google no pude encontrar una respuesta clara. Encontre por ejemplo:
>
> "The Java virtual machine is another term for the Java interpreter" en
> http://safari.oreilly.com/1565924185/ch01-18331
>
> "Cuando Java es compilado y pasado a código de bytes, un interprete
> llamado maquina virtual" en
> http://arechiga.50megs.com/tpoo2/javah1.html
>   

El segundo link casi me deja ciego ;)

Aqui hay una buena definicion:

Interpreter (computing)
http://en.wikipedia.org/wiki/Interpreter_(computing)

Voy a traducir un trozo referente a Java y .NET:

JIT se refiere a la técnica donde el bytecode se compila a codigo de 
maquina nativo en tiempo de ejecución, obteniendo la alta velocidad de 
ejecución del codigo nativo con el costo de incrementar el tiempo de 
partida cuando se compila el bytecode.  Ha ganado atencion en los 
últimos años, y queda aun más difusa la distinción entre interpretes, 
interpretes de byte code y compiladores. JIT esta disponible para las 
plataformas .NET y Java.  La técnica de usar JIT tiene un par de décadas 
de antiguedad, apareciendo en lenguajes como Smalltalk en los 80.


Java bytecode: Understanding bytecode makes you a better programmer
http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/


Y para ver en mas detalle:

A first look at the bytecodes of the Java virtual machine
http://www.javaworld.com/javaworld/jw-09-1996/jw-09-bytecodes.html

Java Bytecode Assembler Examples
http://www.cs.rpi.edu/~moorthy/Courses/compiler99/Assembler/examples.html

--
Franco

Re: Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Xavier Andrade <[EMAIL PROTECTED]> escribió:
>
> Bueno, por ejemplo si se llama repetidamente a rutinas chicas que hacen
> poco, el rendimiento se reduce en al menos un orden de magnitud en
> comparacion al mismo codigo "inlined".
>
> Es decir:
>
> for(i=0; i
> es muchisimo mas rapido que
>
> for(i=0; i
#define SUM(A,B)A + B

int main(void)
{
int x = 5, y = 10, z;

z = SUM(x,y);
printf("%i\n", z);
return 0;
}

El preprocesador de C reemplaza la operatoria en tiempo de
compilación, y permite hacer cosas como esa sin pérdida de ciclos en
tiempo de ejecución.

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Franco Catrin L. 
Xavier Andrade escribió:
> On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>>
>> El problema esta cuando el nivel de abstracci?n te oculta lo que esta 
>> sucediendo por debajo, y se hacen cosas dem?s en forma involuntaria. 
>> Recuerdo que Federico Mena comentaba que muchos problemas de 
>> performance se habian resuelto simplemente aplicando strace para ver 
>> qu? estaba sucediendo por debajo y ahi encontraron que en 
>> aplicaciones como OpenOffice (y tambien en GNOME) se abrian y 
>> procesaban archivos inmutables una y otra vez, en vez de una sola vez 
>> al principio. Es facil tener ese problema, cuando las aplicaciones 
>> crecen y tienes una gran base de c?digo te comienzas (al fin) a 
>> enfocar mas en el qu? y no en el c?mo, pero si te descuidas comienzas 
>> a mal usar lo que ya tienes.
>>
>
> Bueno, por ejemplo si se llama repetidamente a rutinas chicas que hacen
> poco, el rendimiento se reduce en al menos un orden de magnitud en
> comparacion al mismo codigo "inlined".
>
> Es decir:
>
> for(i=0; i
> es muchisimo mas rapido que
>
> for(i=0; i
> con double sum(double a, double b){ return a + b;}. Y al final muchos
> codigos OO terminan haciendo cosas por el estilo (probablemente no 
> para este
> ejemplo, claro).
Supongo que es porque rompen el principio de localidad [1].

Yo me refería a otros casos pero igual es interesante:
La máquina virtual de Java puede aplicar inline en algunos métodos 
siempre y cuando estos métodos no sean sobreescritos, por ejemplo todos 
aquellos que sean static o final... pero... además en tiempo de 
ejecución puede deducir que un método puede ser "inlined" de forma 
segura, porque ya sabe que no esta sobreescrito. De esta forma el 
programador no necesita cambiar su código y es la máquina virtual quien 
se hace la astuta, lo malo es que hay programadores que declaran todo 
como public. [2]

Si no me equivoco los compiladores de C tambien son capaces de reconocer 
código que conviene dejar como inline.
Y finalmente.. los problemas de rendimiento en aplicaciones de las que 
me toca ver a mi casi siempre son debido a latencias por I/O :(

[1] http://en.wikipedia.org/wiki/Locality_of_reference
[2] http://java.sun.com/products/hotspot/docs/general/hs2.html

--
Franco

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Xavier Andrade 
On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>
> El problema esta cuando el nivel de abstracción te oculta lo que esta 
> sucediendo por debajo, y se hacen cosas demás en forma involuntaria. 
> Recuerdo que Federico Mena comentaba que muchos problemas de performance se 
> habian resuelto simplemente aplicando strace para ver qué estaba sucediendo 
> por debajo y ahi encontraron que en aplicaciones como OpenOffice (y tambien 
> en GNOME) se abrian y procesaban archivos inmutables una y otra vez, en vez 
> de una sola vez al principio.  Es facil tener ese problema, cuando las 
> aplicaciones crecen y tienes una gran base de código te comienzas (al fin) a 
> enfocar mas en el qué y no en el cómo, pero si te descuidas comienzas a mal 
> usar lo que ya tienes.
>

Bueno, por ejemplo si se llama repetidamente a rutinas chicas que hacen
poco, el rendimiento se reduce en al menos un orden de magnitud en
comparacion al mismo codigo "inlined".

Es decir:

for(i=0; i
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Leonardo Soto M. escribió:
> On Nov 16, 2007 2:23 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>   
>> Rodrigo Fuentealba escribió:
>> 
 Hay algunas cosas que funcionan más rápido en Java pero no por un tema
 de compiladores, sino que por otros aspectos como por ejemplo el
 mecanismo de Garbage Collection que funciona de forma asincrona (pero no
 en paralelo).

 
>>> Estuve viendo eso relacionado con Microsoft.NET; jamás se me ocurrió
>>> aplicar eso a Java. Bueeena!
>>>
>>>   
>> Sumale eso a que cuando hay suficiente RAM puede funcionar muy bien.
>> 
>
> Un caso práctico donde la recolección de basura podría ser mejor que
> malloc()/free() es Firefox. Análisis recientes están demostrando que
> la manía de Firefox por consumir RAM está más relacionada con
> fragmentación de memoria que "memory leaks" [1]. Y ahí un recolector
> de basura puede ayudar, compactando la memoria de vez en cuando.
>   
Definitivamente ayudaría. Es curioso que esto recien se venga a detectar 
(10 de nov)
Recuerdo haber visto otro análisis en donde se mostraba que las imágenes 
se mantenían en memoria aunque no fueran visibles. Existen técnicas 
conocidas para resolver eso, como las referencias debiles pero creo que 
lo patearon para firefox 3.

Saludos
--
Franco

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Alejandro Weinstein <[EMAIL PROTECTED]> escribió:
> On Nov 16, 2007 10:23 AM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
> > Segun entiendo esos no son compilados reales, runcobol es un interprete,
> > no una maquina virtual.
>
> Cual es la diferencia entre un interprete y una maquina virtual? En
> google no pude encontrar una respuesta clara. Encontre por ejemplo:

En general son casi lo mismo. Las diferencias son poquísimas en cuanto
a funcionamiento.

Un intérprete es capaz de entender un código como "Hola Mundo" (por
ejemplo, en PHP), a través de parsear el archivo, quitarle los
espacios necesarios en la memoria, analizar sintácticamente y luego
recién hacer un puntero a la función que ejecuta.

 se ejecuta así, tal como está, sin
necesidad de precompilar.

En el caso de la máquina virtual, funciona como una maquinita de
stack. Primero hay un compilador que convierte el código de:

public class holamundo
{
public static void main(String[ ] args)
{
System.out.println("Hola Mundo");
}
}

a algo que nosotros como buenos seres cuya estructura molecular está
basada en carbono no entendemos, pero en que la máquina no tiene para
qué esforzarse en destripar cadenas de caracteres, en saber si
funciona o no, simplemente pone un puntero al principio del archivo y
va leyendo y cargando las bibliotecas que requiere, enlazando en
tiempo de ejecución y hasta el final, y recogiendo basurita.

A ver si con eso me explico mejor con a qué me refería con el ejemplo
de RUNCOBOL de hace unos e-mails atrás.

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Alejandro Weinstein 
On Nov 16, 2007 10:23 AM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
> Segun entiendo esos no son compilados reales, runcobol es un interprete,
> no una maquina virtual.

Cual es la diferencia entre un interprete y una maquina virtual? En
google no pude encontrar una respuesta clara. Encontre por ejemplo:

"The Java virtual machine is another term for the Java interpreter" en
http://safari.oreilly.com/1565924185/ch01-18331

"Cuando Java es compilado y pasado a código de bytes, un interprete
llamado maquina virtual" en
http://arechiga.50megs.com/tpoo2/javah1.html

Alejandro.

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Ricardo Mun~oz A. 
Rodrigo Fuentealba wrote:
> El 15/11/07, Asdtaker <[EMAIL PROTECTED]> escribió:
>   

[...]

>> (Por cierto, estoy comenzando
>> con Cake.ya antes habia probado rails, e imaginaras que estoy
>> viviendo un deja vu)
>> 
>
> ¿Por qué? Cake dista un poquito de Rails... Aléjate de él (a menos que
> ya lo hayan migrado a PHP 5 y que aproveche las ventajas que tiene...
>   

Asdtaker,
si te interesa Cake puedes encontrar mas informacion y ayuda en:

http://groups.google.com/group/CakePHP-es

-- 
Ricardo Mun~oz A.
Usuario Linux #182825 (counter.li.org)
From [EMAIL PROTECTED]  Fri Nov 16 15:15:04 2007
From: [EMAIL PROTECTED] (Leonardo Soto M.)
Date: Fri Nov 16 15:24:34 2007
Subject: =?utf-8?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era_algo?=
=?utf-8?b?IGFzw60gY29tbyBjbGllbnRlIGVuIGphYmJlci4uLiBd?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Nov 16, 2007 2:23 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
> Rodrigo Fuentealba escribió:
> >> Hay algunas cosas que funcionan más rápido en Java pero no por un tema
> >> de compiladores, sino que por otros aspectos como por ejemplo el
> >> mecanismo de Garbage Collection que funciona de forma asincrona (pero no
> >> en paralelo).
> >>
> >
> > Estuve viendo eso relacionado con Microsoft.NET; jamás se me ocurrió
> > aplicar eso a Java. Bueeena!
> >
>
> Sumale eso a que cuando hay suficiente RAM puede funcionar muy bien.

Un caso práctico donde la recolección de basura podría ser mejor que
malloc()/free() es Firefox. Análisis recientes están demostrando que
la manía de Firefox por consumir RAM está más relacionada con
fragmentación de memoria que "memory leaks" [1]. Y ahí un recolector
de basura puede ayudar, compactando la memoria de vez en cuando.


> > jajajajajaja yeah. Creo que los programadores Java se engrupen mucho
> > con lo difíciles que pueden llegar a ser sus aplicaciones; alguien me
> > comentó que, de hecho, el inventor de la programación orientada a
> > objetos se hizo netamente con el objetivo de ganar más plata nada más.

Para nada. De hecho, el inventor del término "orientación a objetos"
ha dicho varias veces que lo que tenía en mente en su momento no se
parece mucho a lo que hacen la mayoría de los sistemas de orientación
a objetos hoy por hoy [2].


[1] http://www.pavlov.net/blog/archives/2007/11/memory_fragment.html
[2] http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht26Ht/doc_kay_oop_en
--
Leo Soto M.
http://blog.leosoto.com

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> Rodrigo Fuentealba escribió:
> >> La máquina virtual de Java igual te va a compilar el código a código de
> >> máquina y eso es lo que va a ejecutar, se demorará la primera vez pero
> >> en los casos en donde importa el rendimiento (loops) sólo se hace al
> >> principio.  El byte-code no es código interpretado, es código de máquina
> >> para una máquina virtual (oh!).
> >
> > O sea... es algo así como los compilados de cobol que después tenías
> > que ejecutarlos con runcobol...
> >
> Segun entiendo esos no son compilados reales, runcobol es un interprete,
> no una maquina virtual.

Si a runcobol le pasas un listado de un programa COBOL no va a
funcionar. Tienes que "precompilar" tu archivo .cbl para generar algo
en .cob que runcobol sí entendiera, que no necesariamente es bytecode;
ahora no te podría asegurar qué tenía ese archivo .cob.

Eso obviamente estaba pensado para acelerar la ejecución de varios
listados de programas (COBOL corre en máquinas antiquísimas, y en él
se hacen programas que requieren de harta velocidad para funcionar) y
no para hacer que un mismo código sea compatible con varias versiones
de COBOL. No es lo mismo en cuanto a cómo funciona.

> > jajajajajaja yeah. Creo que los programadores Java se engrupen mucho
> > con lo difíciles que pueden llegar a ser sus aplicaciones; alguien me
> > comentó que, de hecho, el inventor de la programación orientada a
> > objetos se hizo netamente con el objetivo de ganar más plata nada más.
>
> Yo creo que eso es una leyenda urbana como una entrevista que vi por ahi
> al creador de C++ (AFAIR).
> La programación orientada a objetos es de gran ayuda, incluso el kernel
> de Linux es orientado a objetos!

Yep. Gran parte del buen código que he visto lo es pero en sus inicios
la orientación a objetos era considerada elitista y consume hartos
recursos.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas - Consultor UNIX - Database Administrator

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Franco Catrin L. 
Rodrigo Fuentealba escribió:
>> La máquina virtual de Java igual te va a compilar el código a código de
>> máquina y eso es lo que va a ejecutar, se demorará la primera vez pero
>> en los casos en donde importa el rendimiento (loops) sólo se hace al
>> principio.  El byte-code no es código interpretado, es código de máquina
>> para una máquina virtual (oh!).
>> 
>
> O sea... es algo así como los compilados de cobol que después tenías
> que ejecutarlos con runcobol...
>   
Segun entiendo esos no son compilados reales, runcobol es un interprete, 
no una maquina virtual.
Tanto Java como .NET utilizan codigo de maquina independiente de la 
máquina, pero es código de máquina al fin (stack, registros, etc).  Es 
por eso que no es dificil aplicar JIT o incluso compilacion previa (GCJ 
en Java o -aot en Mono).

>> Hay algunas cosas que funcionan más rápido en Java pero no por un tema
>> de compiladores, sino que por otros aspectos como por ejemplo el
>> mecanismo de Garbage Collection que funciona de forma asincrona (pero no
>> en paralelo).
>> 
>
> Estuve viendo eso relacionado con Microsoft.NET; jamás se me ocurrió
> aplicar eso a Java. Bueeena!
>   

Sumale eso a que cuando hay suficiente RAM puede funcionar muy bien.  
Piensa en un simple "add" de un puntero al pedir memoria.  Un par de 
lecturas interesantes:

http://www.ibm.com/developerworks/java/library/j-jtp11253/
http://www.ibm.com/developerworks/java/library/j-jtp09275.html

>> El tema de por qué las aplicaciones en Java funcionan lento tiene varias
>> causas, desde complejidad en exeso en el diseño de aplicaciones hasta el
>> uso y abuso de conceptos avanzados de  Estupidez Artificial y Lógica
>> Confusa ;)
>> 
>
> jajajajajaja yeah. Creo que los programadores Java se engrupen mucho
> con lo difíciles que pueden llegar a ser sus aplicaciones; alguien me
> comentó que, de hecho, el inventor de la programación orientada a
> objetos se hizo netamente con el objetivo de ganar más plata nada más.

Yo creo que eso es una leyenda urbana como una entrevista que vi por ahi 
al creador de C++ (AFAIR).
La programación orientada a objetos es de gran ayuda, incluso el kernel 
de Linux es orientado a objetos!

El problema esta cuando el nivel de abstracción te oculta lo que esta 
sucediendo por debajo, y se hacen cosas demás en forma involuntaria.  
Recuerdo que Federico Mena comentaba que muchos problemas de performance 
se habian resuelto simplemente aplicando strace para ver qué estaba 
sucediendo por debajo y ahi encontraron que en aplicaciones como 
OpenOffice (y tambien en GNOME) se abrian y procesaban archivos 
inmutables una y otra vez, en vez de una sola vez al principio.  Es 
facil tener ese problema, cuando las aplicaciones crecen y tienes una 
gran base de código te comienzas (al fin) a enfocar mas en el qué y no 
en el cómo, pero si te descuidas comienzas a mal usar lo que ya tienes.

Tambien hay casos en que la gente no sabe ni le interesa lo que sucede 
por debajo y hacen grandes desastres de aplicaciones, al final le echan 
la culpa a la complejidad del problema, al lenguaje o a la máquina, pero 
objetivamente los problemas que solucionan la mayoria de las 
aplicaciones no son complejos.


--
Franco
From [EMAIL PROTECTED]  Fri Nov 16 14:32:16 2007
From: [EMAIL PROTECTED] (Rodrigo Fuentealba)
Date: Fri Nov 16 14:35:00 2007
Subject: Carga de aplicaciones (Era Re: Jabber server & client.)
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El 16/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> Rodrigo Fuentealba escribió:
> > El 16/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> Hablando estrictamente en terminos de carga de aplicaciones, para que se
> pueda cargar una aplicación de escritorio se tiene que cargar gran parte
> del sistema operativo.  Cuanto demora el sistema en bootear ah?   1
> segundo? 2 segundos?

Ojalá.

> Creo que dijimos lo mismo pero con otras palabras.

Con otras palabras dijimos lo mismo, creo.

> > Yep; hay que considerar que son aplicaciones complejas y que hacen uso
> > extensivo de gráficas; en el caso de OpenOffice, carga todo el motor
> > de diccionarios y una gran faramalla de cosas.
>
> Parafernalia que no es inncesaria desde el punto de vista de lo que uno
> espera de la aplicación

Volvemos a las aplicaciones con código spaghetti que construyen mucho
en Java: a veces ponen parafernalia que sí es innecesaria; las más de
las veces... y es ahí donde la mala fama pesa.

Q.- How to write a bloated application?
A.- Program it on Java.

> "Si, mi mamá tambien pero si somos hermanosss!!!" ;)

Chócale!

-- 
Rodrigo Fuentealba

Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

2007-11-16 Por tema Rodrigo Fuentealba 
El 16/11/07, Franco Catrin L. <[EMAIL PROTECTED]> escribió:
> Rodrigo Fuentealba escribió:
> > Tampoco lo tiene mucho Java v/s C ya que C se
> > compila directamente a código de máquina, mientras que Java requiere
> > que tengas el JRE (Java Runtime Environment).
>
> Si y no.

> La máquina virtual de Java igual te va a compilar el código a código de
> máquina y eso es lo que va a ejecutar, se demorará la primera vez pero
> en los casos en donde importa el rendimiento (loops) sólo se hace al
> principio.  El byte-code no es código interpretado, es código de máquina
> para una máquina virtual (oh!).

O sea... es algo así como los compilados de cobol que después tenías
que ejecutarlos con runcobol...

> También puedes compilar Java a código de máquina directamente con GCJ,
> pero eso requiere que también tengas compiladas otras cosas que hasta
> hace poco estaban restringidas por Sun.  No sé cual es el escenario actual.

No es 100% portable.

> Hay algunas cosas que funcionan más rápido en Java pero no por un tema
> de compiladores, sino que por otros aspectos como por ejemplo el
> mecanismo de Garbage Collection que funciona de forma asincrona (pero no
> en paralelo).

Estuve viendo eso relacionado con Microsoft.NET; jamás se me ocurrió
aplicar eso a Java. Bueeena!

> El tema de por qué las aplicaciones en Java funcionan lento tiene varias
> causas, desde complejidad en exeso en el diseño de aplicaciones hasta el
> uso y abuso de conceptos avanzados de  Estupidez Artificial y Lógica
> Confusa ;)

jajajajajaja yeah. Creo que los programadores Java se engrupen mucho
con lo difíciles que pueden llegar a ser sus aplicaciones; alguien me
comentó que, de hecho, el inventor de la programación orientada a
objetos se hizo netamente con el objetivo de ganar más plata nada más.

-- 
Rodrigo Fuentealba