Re: WINE: Run-time error 7 - Out of memory
El Thu, 15 Jul 2010 16:20:38 -0400 Miguel Oyarzo O. ad...@aim.cl escribió: El 15-07-2010 11:09, AngelD escribió: Al lanzar ipview pro (aplicacion para camaras IP) mediante wine obtengo Run-time error 7 - Out of memory Existe memoria suficiente. Creo que este no es el problema Alguien conoce este error? Algun paquete de librerías runtime que se deba instalar para aplicaciones bajo windows? Dicen que si las aplicaciones dan muchos [1]mensajes de error OLE, se puede instalar con [2]winetricks las DCOM98. En mis pruebas (wine-1.1.42 desde 0) he logrado muchos mensajes menos de error, algún mensaje de reinicio tras el instalador y errores diferentes al especificado, por lo que parece es el camino correcto. Si, instale winetricks, pero tiene mas de 80 librerias runtime .. ni loco probaré una por una.. además, no el mensaje de runtime podría estar equivocado y quizas es una dll la que no puede registrar su clase. quien sabe. Se me han repetido mensajes no deseados, pero si miras los que valen, verás que la conclusión apunta a la versión del Wine. Cambia la versión de Wine y ¡FUNCIONA!. Por lo menos, a mi me funciona, y sin winetricks Mejor instale una maquina virtual y corrí la aplicación deseada, para tener conectividad solo puse la interfaz en modo bridge y ahora tengo el servidor de Camaras IPVIEW corriendo desde una ventana windows, dentro de linux, trabaja estupendo. Sigo diciendo, antes de matar moscas a cañonazos, INSTALA ZONEMINDER, que tiene un soporte casi completo para las cámaras que comentas (creo, porque has hablado de software, no de cámaras). Claro que puedes instalar una máquina virtual, para una mierda de programa para gestionar una cámara. ¡OPTIMIZACIÓN¡ se llama. Me gustaría resolver el problema con wine si... me pongo nervioso teniendo esa MV alli ;-) Siento repetirme, pero entre los mensajes enviados erroneamente, ¡ESTÁ LA SOLUCIÓN!. Claro que para eso hay que leer todos para descartar los que se me han ido (malditas colas, maldita conexión, maldito cliente de correo que repite el envío de mensajes que no deseo, maldito dedo que dispara sobre lo que no deseo, ...). Saludos --- Angel P.D. Como todo el trabajo (y las soluciones) que he realizado se quede en una máquina virtual, dejo de escribir en este tipo de foros de por vida.
Re: Capas de abstracción (fue Re: Postgresql que se muere)
On Jul 15, 2010, at 4:59 PM, Franco Catrin L. wrote: El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió: Las capas de abstracción no son para protegernos de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien. En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca justo la mala suerte). La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el mundo real (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de ordenar una lista de manera rápida, entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). El ejemplo va por otro lado. Como programadores asumimos que la memoria es lineal y cada celda tiene el mismo costo de acceso. Esa es la abstracción. La realidad es que la memoria puede estar fragmentada y además tienes sistemas de caché intermedios, por lo que no existe un costo de acceso igual para todos los casos. Sigo insistiendo que te estás enfocando en protegernos del mundo real... ¡las capas son para dar soluciones, no problemas! Cómo una biblioteca te puede proteger de eso si como programador necesitas por ejemplo un array bidimensional que vas a procesar por filas y por columnas indistintamente? Olvídate de los peros, que son excusas y para eso estamos nosotros. Si en cambio nos enfocamos en algún objetivo como: proveer el procesamiento mas rápido de un arreglo ahí los peros que me das desaparecen (indistintivamente del modo de acceso, eso es un problema particular de una implementación). Te olvidas del acceso de memoria, te olvidas incluso que hay CPU pues tenemos a alguien que hace muy bien este tipo de pegas que es la GPU. Es decir, una posible respuesta sería utilizar la GPU la cual tiene buses mucho mas anchos, tienen hasta cientos de Cores que pueden procesar en paralelo, etc. De hecho, hay bibliotecas que hacen este tipo de soluciones hoy en día: el tarro donde escribo lo hace vía OpenCL y gracias a LLVM puede enviar trabajos tanto a la GPU como a la CPU. http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/14 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/15 Si el objetivo es otro (proveer procesamiento de un arreglo, pero en tiempo real que no sobrepase X tiempo), las soluciones son otras... y así. Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el herramienta adecuada, ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con leaky abstractions o lo complicado que es la vida. En ese caso, si le pagas al mecánico por resolver un problema puntual, lo puede hacer perfectamente, otra cosa muy distinta es querer que te deje el auto andando. Bueno, yo le pago al mecánico para que me deje andando el auto... Es la clásica confusión entre el que define los requerimientos y el que los tiene que satisfacer. ¡Epa! Una luz de encuentro. La pregunta era entonces: ¿debiera postgresql dar mas información en el error de memoria? Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software. Qué me dices del ejemplo en donde los sistemas de seguridad de un auto no ocultan la diferencia entre manejar con o sin lluvia? La capa no es para proteger (ni ocultar) los problemas del mundo real... si algo no está diseñado para manejar con lluvia (o su rendimiento degrada) no lo es y punto (y yo no salgo en moto cuando llueve). A esto me refiero con usar la herramienta adecuada. La capa de software o los servicios siempre tienen un límite en donde no pueden resolver los problemas por si mismos. Es ahí donde salta la excepción. Que estén o no declarados esos límites es otro problema muy distinto, y al final la elegancia con que se resuelven algunos casos puede ser inútil en la práctica, aumentando el costo para el 99%
Re: Postgresql que se muere
El Wed, 14 Jul 2010 17:08:24 -0400 Alvaro Herrera alvhe...@alvh.no-ip.org escribió: (¿Cuántos de aquí usan memoria ECC en sus servidores de datos?) En mi caso NO es asumible no tener ECC en casi ningún servidor productivo, por estúpido y sencillo que sea este. Usar servidores de datos sin ECC es de una cortedad de miras increíble (nunca se me ha dado el caso), y económicamente insignificante. Resumiendo, NUNCA he tenido servidores de datos sin ECC, y espero no tenerlos nunca. Saludos --- Angel
Re: OT: oracle client
El Wed, 14 Jul 2010 14:01:02 -0400 Juan C. Olivares juan...@juancri.com escribió: Podrías probar de todas maneras. Yo he usado el cliente 10g con bases 9.2... ¿seguro que no funciona con 8.x? Según [1]esto hay que tener instalado el grupo de parches 8.1.7.3 para que funcione [1]http://stackoverflow.com/questions/153151/connect-to-an-oracle-8i-database-using-a-10g-client Saludos --- Angel
Re: Postgresql que se muere
Excerpts from AngelD's message of vie jul 16 05:37:27 -0400 2010: El Wed, 14 Jul 2010 17:08:24 -0400 Alvaro Herrera alvhe...@alvh.no-ip.org escribió: (¿Cuántos de aquí usan memoria ECC en sus servidores de datos?) En mi caso NO es asumible no tener ECC en casi ningún servidor productivo, por estúpido y sencillo que sea este. Usar servidores de datos sin ECC es de una cortedad de miras increíble (nunca se me ha dado el caso), y económicamente insignificante. En el tercer mundo los presupuestos son diferentes.
Re: Ayuda con Control Remoto USB HID y/o adaptador infrarojo.
El Thu, 15 Jul 2010 17:09:01 -0400 Franco Catrin L. fcat...@tuxpan.com escribió: [.] Ya encontré la causa del problema, les cuento por si alguien se topa con algo parecido: Los eventos se propagan así: dispositivo - usbhid - input layer El problema es que por algún motivo, usbhid está descartando algunos eventos que provienen del control y no los propaga a input layer. Una de las causas probables es que el descriptor USB HID del dispositivo esté malo. En ese caso, no será mejor corregir en la base el descriptor? En BIOS no se usa ese descriptor y probablemente Windows tampoco lo usa, por lo que el dispositivo está OK para sus fabricantes. usbhid prevee esos casos y tiene mecanismos para ignorar estos defectos, pero no he logrado hacer que ignore lo que está malo en este control. usbhid también prevee ese caso, y envía los eventos HID por /dev/hidraw*. Desde ese device si puedo leer los eventos y veo todas las teclas. Para no meter mano en el kernel, voy a hacer una solución ad-hoc en userspace: hidraw - aplicacion - /dev/lircd De esta forma puedo mapear todas las teclas del control a lo que yo quiera, y para las aplicaciones compatibles con lircd quedará oculta esta complejidad (alguien dijo abstracción?). Afortunadamente inputlirc es un buen punto de partida para implementar esta solución. Si bien esto puede funcionar, pero estas corrigiendo el problema por una puerta trasera y no desde el fuente, en tu lugar trataría de corregir el problema en el fondo, ya sea reportando el problema o comunicándome con el o los desarrolladores para que se corrija, así se gana en la comunidad. En el otro caso sólo sales del problema, haciéndolo funcionar pero el problema para el resto sigue vigente. Saludos Saludos RAB
