Mensajes

Whoops, recién veo el hilo, a ver ...

Primera excepción en 0x0116dd07 en Fisica 1.1.exe: 0xC0000005: Infracción de acceso al leer la ubicación 0x00000000.

Lo que está en Rojo es básicamente un segmentation fault, segfault, como gustes llamarlo ... significa que tu programa trata de acceder a memoria que no tiene permisos de leer.
Lo que está en Azul te dice donde quiso leer ... 0x00000000 es básicamente 0 en hexadecimal, y 0 es lo mismo que NULL.

¿Hay un puntero sin inicializar por ahí?
Compilá el proyecto en modo debug y ponele un breakpoint antes de la primer llamada en esa función, aunque el drama está en GScene; sea por que GScene es nullptr o por que algún puntero que  fetchResults() usa vale eso.

Saludos.

P.S → Tendría que compilar Ogre y NxOgre (asumiendo que esté para linux, creo que si) para depurar eso ... y es algo que me consumiría bastante tiempito aparte de no enseñarte nada; tratá de ir resolviéndolo por tu cuenta y te echamos una mano desde acá.

estoi investigando sobre procesos en linux, quisiera saber si alguno lo sabe ya. como hace linux para planificar por ejemplo un proceso que tiene 3 hilos. no se si es el foro que va del tema pero es sobre programar en c me imagino.

Si tenés que trabajar con hilos, tenés el estándar POSIX para hilos, pthread (la lista de funciones acá)
Aunque ojo, también tenés librerías que funcionan en linux, windows y demás y que apuntan a simplificar el uso de hilos; aunque claro, por lo bajo usan pthread.

hasta donde yo se para planificar procesos lo hace el kernel de linux pero los hilos estuve viendo que lo debe hacer el programador manualmente o usar una biblioteca.

El kernel "planifica" (este es un término técnico, attenti ... tiene que ver con el subsistema de scheduling o planificación; cosa sobre la que deberías leer un poco para entender las diferencias de performance entre una cosa y otra) tanto hilos como procesos.
La diferencia radica en cómo los planifica; y esto depende del algoritmo que use (por que hay un *montón* de algoritmos de scheduling incluso para un mismo kernel), pero del vamos podemos decir que el context switch entre  hilos es más rápido.

eso significa que el kernel no es el que planifica los hilos de unproceso sino es como que el kernel ve al proceso como un hilo solo. si alguno sabe como se hace el planificamiento o planificacion de hilos en linux me gustaria saberlo,desde ya gracias

Así es, un proceso arranca siempre con un hilo "main"; después quien programa puede crear más según vea necesario.
Las diferencias entre programar hilos o procesos van mucho más allá que el planificador, hay múltiples diferencias prácticas (por ejemplo, en programación multiproceso no compartís espacio de memorias, por o que tenés que usar mecanismos de IPC para pasar datos de un proceso a otro ... comparado con los hilos que sí comparten espacio de memoria por pertenecer al mismo proceso)

También tenés que pensar un poco más en la integridad de datos cuando entrás al mundo del paralelismo/concurrencia.

Acá hay una intro a los hilos en linux → http://www.thegeekstuff.com/2012/03/linux-threads-intro/

Saludos.

P.S → Igual mucho no entendí la duda ... si pateaba para programación concurrente, paralela, una vista general de ambas, nosé.

XXX

Chanfles, mandé solicitud y nada de nada :c

http://lists.freebsd.org/pipermail/freebsd-current/2004-January/018245.html

Sucede ... lo importante es que sea argumentando y citando fuentes (y sino, pedirlas según sea necesario, por que a veces poner fuentes a todo toma tiempo), todo medio digital tiene flame wars por que siempre hay posturas muy diferentes que entran en contacto y friccionan.
Lo interesante es ver qué tipos de flamewars tiene el medio y cómo se mueven lxs actorxs dentro de ella ... eso dice mucho del medio también

Ah, y una flame es una flame ... hay que ser un pelotudo para tomárselo de manera personal, sinceramente
creo que cuando contratás un ISP tendrían que darte un "instrucciones para usar la internet" que incluya esto.

Saludos.

Yo te diría que lo re-pienses a lo que querés hacer ... si fueses 100% consciente de las posibilidades de "reparación" que perdés si sacás el prompt del bootloader, no lo harías.
Bajale el tiempo de espera para el autoboot si pensás que te roba velocidad, pero mi sincera opinión es que no lo vale.

Saludos.

Resumiendo, de quien sea la culpa no me interesa,  almenos en las distros deberian de dejar estas cosas por defecto, de lo contrario estaria dificil que se habran mercado en las laptops como las nuestras. Porque no todos tenemos tiempo para andar indagando que hacer y como hacerlo, pero si soy honesto, tener la laptop caliente solo por esto me parece una estupides.

Reclamale a nVIDIA ... el licenciamiento actual de los drivers privativos impiden que se incluyan en una distribución (es ilegal)
En Phoronix hace poco hubo una flame war al respecto, mucho troll ... pero bastante educativa, charla el tema de Optimus justamente (tu caso) y sobre su implementación en linux con los drivers privativos

http://phoronix.com/forums/showthread.php?74516-Bickering-Continues-About-NVIDIA-Using-DMA-BUF

Saludos.

Esa es una de las razones por las que Ubuntu falla mas que una escopeta de feria. En un intento de 'crear' algo estable y con un mínimo de control, que pudiese ser usado para otra cosa que no fuese un escritorio chupiguay crearon la LTS, que es 'un Debian Stable' basado en los repositorios de testing (lol?).

Creo que no entendiste el argumento, por que seguís viendo al sistema como un "todo" y pareciese que no distinguís importancia de los diversos componentes para con la estabilidad final del sistema y qué posibilidad tuvieron de QA antes de la versión final de upstream.
Debian ni siquiera hace esas discriminaciones, Ubuntu menos ....

(hay otras 2 ramas en las que no lo están)

No, Testing y Unstable siguen con la 8, la actual es la 9 y se está llegando la 10.
Ah, y en Debian stable tenés la rama 7 ... si tenés corrupción gráfica o problemas de estabilidad por tener un stack gráfico más obsoleto, a llorarle a magoya.

¿Se entiende a qué me refiero? saque sus propias conclusiones.

de Stable te diria: ¿Por qué me iba a interesar actualizar X? Tengo una versión que me funciona.

Ajám el concepto de "funciona" depende de los bugs que entorpezcan la funcionalidad que el usuario necesite.
Que te funcione no significa que me funcione, y que funcione para con el estado actual de la aplicación ..  Y te puedo asegurar que he visto cosas que NO FUNCIONAN en Stable.

Ejecutá un juego 3D como el HoN en el stack gráfico de mesa stable y mirá como segfaultea todo el entorno gráfico (X y todo lo que dependa de eso), ejecutalo acá en Gentoo y vas a ver como corre perfecto.

Es totalmente relativo este argumento.

¿Por qué tengo que actualizar a otra que le da soporte a XXXXXXXXXX e incorpora XXXXX cosas que tal vez no necesite,

Es una cuestión de motivaciones ... si "funciona" la persona no cambia el sistema.
A mi Debian jamás me "funciona" y traté con mucho amor y le dí oportunidades por las propagandas que le hacen mis amistades Debianitas.

No hay chance.

n vez de simplemente quedarme con la que tengo y recibir solo actualizaciones de seguridad o actualizaciones que resuelvan los problemas que tiene esta versión?

Relee el argumento, esa versión X puede tener el mismo problema que una versión Y ... pero por cambios arquitecturales X no puede recibir un costoso backport del fix de Y por que tendría que recibir modificaciones sustanciales que podrían introducir bugs.

Ah, por cierto, los bugs también se introducen con fixs de otros bugs, por eso decimos que no existe el software bugfree también.
El reciente problema de corrupción en ext4 en los kernels ESTABLES es un ejemplo de ello : http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ

Pensalo en la perspectiva de las políticas de releases de Debian.

Si a la persona de verdad le interesa tener las nuevas características de una versión mas moderna de X, solo tiene que hacer apt-pinning a testing.

Nueva versión != nuevas características únicamente

Las nuevas versiones incluyen fixs, MUCHOS ... y es lo que la gente de Debian tiene problemas de ver.
Ah, y en el caso del stack gráfico actuak, nuevos features se pueden considerar como fixs por que introducir nuevas extensiones sobre las que las apps. dependen las hace "funcionar".

Eso es básicamente lo que Debian Stable es, no puedes criticar que en esa rama de Debian las cosas estén atrasadas (en cuanto a versiones) pues ese es precisamente su propósito, así como el de los aviones es volar o el del un libro ser leído.

Versiones, fixs de las nuevas versiones y features.
Digamos las cosas completitas.

Creo que no tiene mas sentido seguir llenando el post con esto, tu criticas que en Stable las cosas son viejas (y en particular los drivers gráficos) y yo te digo que en eso consiste la rama Stable XDD

Yo prefiero una terminología menos tendenciosa y más correcta: OldStable
Para evitar discursos ambiguos.

Saludos.

Pues yo si veo una relación entre la antiguedad de un paquete y la estabilidad del mismo, pues mientras mas tiempo pase el paquete en testing/sid, mas posibilidades hay de que se descubran 'bugs' en el y mas posibilidades hay de que éstos sean 'fixeados' incidiendo así en la estabilidad del software en cuestión.

Los bugs se descubren por testear el software (tanto durante el desarrollo - estableciendo pautas de QA como unit testing - como durante el release por el uso de los usuarios, por que sí, es imposible aniquilar todos los bugs durante el desarrollo .. bah, no existe el software bug free) ... y tenerlo en una rama de la distribución que en todos lados se dice "no me uses" no sirve de absolutamente nada (ni siquiera la rama experimental)

Por que para cuando llega a testing u stable, ya muchas distros mainstream como Ubuntu sacaron ese software por la puerta y levantan todos los bugreports.

un pelín desactualizado

4 releases de mesa atrás en el peor de los casos, 2-3 en un caso promedio ... como una persona interesada (y con algo de conocimiento de) en el stack gráfico de linux te puedo decir que es muy dañino por que cambió mucho el ritmo de desarrollo de drivers gráficos (que es de lo que hablo cuando digo "los drivers en debian son crap" ... de eso, los drivers gráficos)

Aquí ni te voy a dar la razón, ni te la voy a quitar, pues tanto con Debian testing, como con Gentoo o Arch he tenido que hacer apaños y arreglar cosas después de algunos updates, aunque el mayor 'break' lo tuve en Archlinux y fue una de las razones por la que lo mandé a paseo...xD Respecto a lo de la estabilidad de Arch, no he visto rolling-release mas inestable en mi vida, ni tanta obsesión por añadir lo mas rápido posible cualquier ***** que el desarrollador de upstream haya añadido.

Yo los brakages más feos los tuve con Debian Testing (Sid ni lo toqué, gracias con la estabilidad de Testing) y Fedora.
las otras distros son relativamente estables en cuanto al tree respecta.

¿Hablas de la LTS? Es que no estoy muy enterado de las novedades referentes a Ubuntu.

Todavía no se resolvió nada ... pero con los drivers privativos ya delinearon como van a hacer, con los libres queda ver:

http://www.bryceharrington.org/wordpress/?p=91

Los parches referentes a la seguridad, son la prioridad en Stable y de hecho existe un grupo de personas dedicadas unicamente a esa tarea (y es la única rama que recibe este tipo de parches), otro tipo de parches no te voy a negar que si tardan mucho mas. Pero eso es parte de Stable, me refiero al hecho de 'no cambiar', osea, todos los paquetes que están en esa rama se consideraron en su momento lo suficientemente 'maduros' como para incluirse. Cuando se habla de la estabilidad de Debian (Stable) no se habla de que en esa rama no existan bugs, o existan menos que en las demás, se habla de que 'no cambia', y de que no hay necesidad de ningún cambio (excepto los parches de seguridad) pues todo lo que tiene que funcionar funciona. Las personas que usan Debian Stable en su escritorio, rara vez lo hacen 'a secas', hacen pinning a testing para tener la última versión de Iceweasel por ejemplo...

Entiendo, estabilidad "de versiones" ... bueno, la mayoría habla de estabilidad del software, y eso está muy mal.
pero el pinning es una cagada no sólo por la compatibilidad binaria, sino que hasta tenés que actualizar una libc por actualizar un firefox o loquesea Debian y hasta partes del sistema que no tienen nada que ver.

Es chanchísimo eso.

Saludos.