¿Habéis visto el Ibex 35...? Abril 2011 +

You must be registered for see images

<object type="application/x-shockwave-flash" data="http://zappinternet.com/v/jupZmePdiL" height="331" width="400"><param name="movie" value="http://zappinternet.com/v/jupZmePdiL" /><param name="allowFullScreen" value="true" /></object><br /><a href="http://www.zappinternet.com/video/jupZmePdiL/Mortero-FAIL">Mortero FAIL</a>
 
Propicios días :roto2:

salgo de mi cubil un momento y paso a saludar y tal...

ando solventando mis problemas de latencia que ya comenté hace un par de semanas... de nuevo el "rescate" viene de la mano de openCL, verdadero "behemoth" de fruta masiva donde los haya.

Vuelvo al roundtrip de submilisegundo, mi humor mejora, la deudaférica de esta desgracia de país vuelve a rondar el 5,6%, de nuevo vamos a morir y a ser intervenidos 100 veces... ¿qué más se puede pedir?

pipos y saludos (y fran200 y MM, a ver si al menos os dejáis caer a saludar!)

Yo aquí veo indicios de que el posting ordinario comienza a recuperarse, si los rumores de reaparición de MM y F200 se confirma podría no ser necesario un QP2.

Ahora en serio, duda informática, tengo un problemón de los rellenitos, resulta que mientras banana abandonaba el club del sub-milisegundo yo intentaba entrar en el club del sub-segundo pero las cosas están estancadas.

El caso es que tengo un s-c-r-i-p-t en php que se encarga de coger los datos del broker, hacer los cálculos y pasarlos a la base de datos, pues bien, resulta que cuando el s-c-r-i-p-t está funcionando no hay ningún problema pero si cierro el navegador el s-c-r-i-p-t no "muere" sigue funcionando en "alguna parte".

Lo sé porque la base de datos sigue recibiendo inputs a intervalos regulares.

He probado de todo, limpiar la caché de los navegadores, buscar procesos ocultos con tropecientos programas...., no funciona nada, la única solución es detener el servicio mysql.

¿Alguna idea de por qué tengo ese s-c-r-i-p-t rebelde?.

Otra cosa, la estructura de control del s-c-r-i-p-t php está hecha chapuceramente con gotos, no lo he hecho con case porque había leído que iba más lento, ¿puede ser por eso?.
 
<object type="application/x-shockwave-flash" data="http://zappinternet.com/v/jupZmePdiL" height="331" width="400"><param name="movie" value="http://zappinternet.com/v/jupZmePdiL" /><param name="allowFullScreen" value="true" /></object><br /><a href="http://www.zappinternet.com/video/jupZmePdiL/Mortero-FAIL">Mortero FAIL</a>

Y en toda regla. Hoy la pasta esta yendo para el bono que ya ha bajado hasta 5,50.:tragatochos:
 
A ver si dejan de marear la perdiz y se ponen manos a la obra para completar la segunda ala de este batman en diario de casi un año de edad 😛

Pd. Buenas tardes y tal.
 

Adjuntos

Archivo oculto para usuarios no registrados
El problema viene porque asocias la ejecución en navegador (client side) con la ejecución remota (server side). Cuando tú usas el navegador para lanzar el php en remoto, en realidad esa ejecución está teniendo lugar en el contenedor http de la máquina remota (sea un IIS, un apache, o lo que sea).

En ese momento se produce un "detach", esto es, el php remoto sigue su ejecución independientemente de la conexión html que lo inició (tu navegador, en este caso).

Así que si luego vas y cierras el navegador, al php como que se la chifla, le da exactamente igual. Por eso sigues leyendo actividad de tu código, porque realmente _sigue_ en activo.

Tienes que añadir una condición de salida explícita para que el código termine "de verdad". Teniendo en cuenta, además, que tras el detach inicial has perdido cualquier posibilidad de comunicación con tu código.

Yo aquí veo indicios de que el posting ordinario comienza a recuperarse, si los rumores de reaparición de MM y F200 se confirma podría no ser necesario un QP2.

Ahora en serio, duda informática, tengo un problemón de los rellenitos, resulta que mientras banana abandonaba el club del sub-milisegundo yo intentaba entrar en el club del sub-segundo pero las cosas están estancadas.

El caso es que tengo un s-c-r-i-p-t en php que se encarga de coger los datos del broker, hacer los cálculos y pasarlos a la base de datos, pues bien, resulta que cuando el s-c-r-i-p-t está funcionando no hay ningún problema pero si cierro el navegador el s-c-r-i-p-t no "muere" sigue funcionando en "alguna parte".

Lo sé porque la base de datos sigue recibiendo inputs a intervalos regulares.

He probado de todo, limpiar la caché de los navegadores, buscar procesos ocultos con tropecientos programas...., no funciona nada, la única solución es detener el servicio mysql.

¿Alguna idea de por qué tengo ese s-c-r-i-p-t rebelde?.

Otra cosa, la estructura de control del s-c-r-i-p-t php está hecha chapuceramente con gotos, no lo he hecho con case porque había leído que iba más lento, ¿puede ser por eso?.
 
Ahi esta tito Ben metiendo billetitos frescos. Quereis unos??? estoy de ronda aprovechad.

Por cierto, que opinais del EUR/USD?? esta peponcisimo, necesitan otro ataque a la deuda española... 😉
 
Buenas tardes
Pasaba para comentar que esta mañana el Stop profit me ha descabalgao
Cerrado corto de Ibex 10828>10400 +17,2% Buena galopada
Y he batido el IPC!!😀
S2
 
IBM e Intel presentan resultados al cierre...vermos lo que nos espera

No dudes que acabaran haciendo lo que quieran, o sea, subir. Si no, ya esta el tio ben para ello.😛

Ya estan lanzados, parece que lo huelen.
 
Última edición por un moderador:
Se sabe algo de los resultados?? donde los soleis mirar?

Edito: han tenido que salir buenos porque el dow esta subiendo despues del cierre. Como bien dijo alguien por aqui (no recuerdo quien fue) al final veremos maximos anuales esta semana...
 
Última edición por un moderador:


Mañana festival señores, mañana no habra problemas de deudas ni deficits ni nada. Cojan el billete.
 


Haran estos prejubilaciones tambien?? :XX::XX::XX:

El dax subiendo casi un 1% ahora.
 
IBEX:

You must be registered for see images


Todavía sin haber alcanzado la zona de soporte, el IBEX ha intentado un tímido avance al alza sin demasiado éxito. Vemos que durante la sesión de hoy el precio se ha peleado con la directriz alcista perdida y es de esperar que para mañana la cosa siga igual. El nivel de referencia de ultracorto plazo son los 10.450 puntos: debe romperlos con fuerza si quiere seguir avanzando en la senda de Pepón.

El RSI por fin ha roto y ha logrado salir de sobrecompra, pero el avance en el precio ha sido muy débil, lo cual nos indicia que el rebote podría no estar maduro todavía. Personalmente, mientras no vea esos 450 rotos con claridad, el escenario más probable para mí será un movimiento de congestión en busca del soporte, con poco rango y bastante aburrido.
 
Ya empezamos con los ordenadores... al menos en la guardería postean pechuga.

Como el mercado no ha avanzado demasiado y lo que tenía que decir del IBEX ya lo dije ayer, hoy voy a colgar una cosilla que dejé caer hará unas semanas. Todo muy hipotético, pero...

En gráfico mensual:

You must be registered for see images


Coincidiría con el final de las ayudas de la Fed, probablemente, por no hablar de la subida de tipos de interés...


Y así estamos ahora:

You must be registered for see images


Hay que dejar margen, que hablaríamos de un movimiento de largo plazo en escala mensual, pero ahí queda, con un objetivo pendiente en los 135.

Ya podemos empezar a afinar un poquito como podría ser ese giro. Repito, todavía todo muy hipotético, pero si os fijáis la vuelta al alza se ha producido justo en los niveles previstos...

You must be registered for see images


Este sería el escenario si los mercados, básicamente los yankis, que son los que andan más fuertes, quisieran hacer un nuevo máximo.

Continuaremos con el seguimiento de la situación durante estos días.
 
Camino de ello van los americanos. Hasta el jueves tienen tiempo esta semana de llevarlo donde quieran. De momento todo pinta pepon no, lo siguiente.

Edito:
 
Última edición por un moderador:
Toy muuuy cansado así que no espero a las antípodas.

Solo entro para comentarles que Yahoo! ha lanzado un nuevo servicio llamado 4Cast, donde el perosnal puede hacer predicciones sobre las cosas más variopintas, incluída la tómbola, digo la bolsa.



Acaba de salir como Beta pública.

Hay que hacerse cuenta Yahoo!, lo que no es muy recomendable si vas pedir algún crédito (básicamente tarjetas). Pero como ya tengo una para Yahoo!Pipes, pues... probaré.
 
El problema viene porque asocias la ejecución en navegador (client side) con la ejecución remota (server side). Cuando tú usas el navegador para lanzar el php en remoto, en realidad esa ejecución está teniendo lugar en el contenedor http de la máquina remota (sea un IIS, un apache, o lo que sea).

En ese momento se produce un "detach", esto es, el php remoto sigue su ejecución independientemente de la conexión html que lo inició (tu navegador, en este caso).

Así que si luego vas y cierras el navegador, al php como que se la chifla, le da exactamente igual. Por eso sigues leyendo actividad de tu código, porque realmente _sigue_ en activo.

Tienes que añadir una condición de salida explícita para que el código termine "de verdad". Teniendo en cuenta, además, que tras el detach inicial has perdido cualquier posibilidad de comunicación con tu código.

Gracias por contestar banana, verás, el caso es que no estoy haciendo nada en remoto, estoy ejecutando el php directamente en el navegador del servidor, por eso no comprendo que siga ejecutándose y haciendo inserts en la base de datos una vez cerrado el navegador y limpiada la caché.

Ya sé que php no es para eso y que es algo raro hacerlo así, pero en teoría debería funcionar, de hecho funciona, el problema viene porque a veces al ejecutarlo en el navegador no me saca ni salida por pantalla ni nada, se queda el navegador en blanco pero el s-c-r-i-p-t funciona e inserta en la base de datos pero ya fuera de control, es decir, entra en ese bucle del que no puedo sacarlo ni cerrando navegador ni nada.
 
poltergeist ?, fantasmas ?, bugs ?

Todo es posible en la Dimensión Desconocida !

😀
 
A los buenos días!

Gracias por contestar banana, verás, el caso es que no estoy haciendo nada en remoto, estoy ejecutando el php directamente en el navegador del servidor, por eso no comprendo que siga ejecutándose y haciendo inserts en la base de datos una vez cerrado el navegador y limpiada la caché.

Ya sé que php no es para eso y que es algo raro hacerlo así, pero en teoría debería funcionar, de hecho funciona, el problema viene porque a veces al ejecutarlo en el navegador no me saca ni salida por pantalla ni nada, se queda el navegador en blanco pero el s-c-r-i-p-t funciona e inserta en la base de datos pero ya fuera de control, es decir, entra en ese bucle del que no puedo sacarlo ni cerrando navegador ni nada.

A mi también me extraña mucho tu problema, supongo que será consecuencia de estar en win 😀

No te contesté porque esa circunstancia que comentas nunca se me ha dado y eso que llevo unos cuantos años de PHP a las espaldas (los suficientes como para que me haya podido pasar alguna vez), lo único que se me ocurre es que hayas puesto tu s-c-r-i-p-t en el cron o como se llame el artilugio que usa win para tareas automatizadas, o que le hayas dicho al código php que algo se ejecute en segundo plano ¿usas alguna orden que ejecute un s-c-r-i-p-t externo como exec o algo parecido?

Lo del exec es lo más probable que se me ocurre, ahí el PHP si que podría estar perdiendo el control de lo que ejecuta, entonces al cerrar el navegador el s-c-r-i-p-t seguiría en marcha.

PD: Pepón es mi pastor.
 
Yo aquí veo indicios de que el posting ordinario comienza a recuperarse, si los rumores de reaparición de MM y F200 se confirma podría no ser necesario un QP2.

Ahora en serio, duda informática, tengo un problemón de los rellenitos, resulta que mientras banana abandonaba el club del sub-milisegundo yo intentaba entrar en el club del sub-segundo pero las cosas están estancadas.

El caso es que tengo un s-c-r-i-p-t en php que se encarga de coger los datos del broker, hacer los cálculos y pasarlos a la base de datos, pues bien, resulta que cuando el s-c-r-i-p-t está funcionando no hay ningún problema pero si cierro el navegador el s-c-r-i-p-t no "muere" sigue funcionando en "alguna parte".

Lo sé porque la base de datos sigue recibiendo inputs a intervalos regulares.

He probado de todo, limpiar la caché de los navegadores, buscar procesos ocultos con tropecientos programas...., no funciona nada, la única solución es detener el servicio mysql.

¿Alguna idea de por qué tengo ese s-c-r-i-p-t rebelde?.

Otra cosa, la estructura de control del s-c-r-i-p-t php está hecha chapuceramente con gotos, no lo he hecho con case porque había leído que iba más lento, ¿puede ser por eso?.

Es posible que el programa se haya perdido con tanto goto y no este donde creas tu que esta. Puedes probar a ponerle unos prints (a un archivo, claro, el navegador ya lo has cerrado), que te diga por donde va, y despues reestructurar el codigo para quitarle todos los gotos, seguro que hay una forma mejor de hacerlo.
 
BL, es lo mismo. En el entorno "server side", el hecho de que la máquina que alberga el código php sea la tuya propia (localhost) o un servidor web remoto a 1000 Km. de distancia, es irrelevante.

Lo que de verdad importa es que el código PHP se ejecuta en server side por un proceso (digamos, el proceso servidor web) que nada tiene que ver con el proceso client-side que inició la petición (digamos, el proceso navegador web). Esa, y no otra, es la razón por la que tu código sigue ejecutándose en un "supuesto" segundo plano, aun cuando has cerrado el navegador mediante el cual lo lanzastes.

El hecho de que ambos programas (navegador y servidor web) residan en la misma máquina, es puramente anecdótico. Lo que importa es la separación entre procesos, que es total.

Abres tu navegador, lanzas la petición, y el servidor web comienza a liquidar tu php. Esta es la parte crítica que hay que entender para ver cómo funciona este asunto: "el servidor web comienza a liquidar", es decir, no es tu navegador el que ejecuta el php, sino el proceso servidor web. Ahora verás claro por qué sigue ejecutándose el código cuando cierras el navegador... y es porque el servidor web sigue perfectamente en pie y activo, ejecutando el php que le fue solicitado.

Tienes razón cuando dices que seguramente no es ésta la forma correcta de abordar este problema; estás lanzando un código y perdiendo el control sobre él (detach); esta aproximación te va a dar bastantes dolores de cabeza.

Como mal menor, y ya que estás en local con tu propia máquina, te recomendaría que al menos te olvidases del navegador y ejecutases tu PHP directamente con el intérprete de línea de comandos (ejemplo, php -i programa_de_bl.php).

El modificador -i es ejecución interactiva; esto te acercará más a lo que tú estás buscando, que es un entorno más "tradicional" en el que lo que yo ejecuto pasa a primer plano, y cuando se devuelve el control de la shell al usuario, es sólo porque la ejecución ha terminado realmente.

Tienes que poner atención en entender la sutileza de la diferenciación entre ejecuciones server-side y client-side; ahí reside todo el "misterio", que ya verás con el tiempo y la práctica como no es tal.


Gracias por contestar banana, verás, el caso es que no estoy haciendo nada en remoto, estoy ejecutando el php directamente en el navegador del servidor, por eso no comprendo que siga ejecutándose y haciendo inserts en la base de datos una vez cerrado el navegador y limpiada la caché.

Ya sé que php no es para eso y que es algo raro hacerlo así, pero en teoría debería funcionar, de hecho funciona, el problema viene porque a veces al ejecutarlo en el navegador no me saca ni salida por pantalla ni nada, se queda el navegador en blanco pero el s-c-r-i-p-t funciona e inserta en la base de datos pero ya fuera de control, es decir, entra en ese bucle del que no puedo sacarlo ni cerrando navegador ni nada.
 
Buenos días...

Vaya gap, parece que abriremos justo en la zona de referencia. A ver qué tal se porta BANKINTER, ya le toca un poco de amor pepónico.
 
Buenos días...

Vaya gap, parece que abriremos justo en la zona de referencia. A ver qué tal se porta BANKINTER, ya le toca un poco de amor pepónico.

sip, momento importante........ a ver q se hace al llegar a esta resistencia...... el DAX la ha roto por la noche pero a ver si la aguanta por el dia
 
A ver, vamos por partes:

poltergeist ?, fantasmas ?, bugs ?

Todo es posible en la Dimensión Desconocida !

😀

Descartado el factor paranormal, creo que el problema es cosa del "programador". 😀

A los buenos días!



A mi también me extraña mucho tu problema, supongo que será consecuencia de estar en win 😀

No te contesté porque esa circunstancia que comentas nunca se me ha dado y eso que llevo unos cuantos años de PHP a las espaldas (los suficientes como para que me haya podido pasar alguna vez), lo único que se me ocurre es que hayas puesto tu s-c-r-i-p-t en el cron o como se llame el artilugio que usa win para tareas automatizadas, o que le hayas dicho al código php que algo se ejecute en segundo plano ¿usas alguna orden que ejecute un s-c-r-i-p-t externo como exec o algo parecido?

Lo del exec es lo más probable que se me ocurre, ahí el PHP si que podría estar perdiendo el control de lo que ejecuta, entonces al cerrar el navegador el s-c-r-i-p-t seguiría en marcha.

PD: Pepón es mi pastor.

Ni cron ni exec.

Es posible que el programa se haya perdido con tanto goto y no este donde creas tu que esta. Puedes probar a ponerle unos prints (a un archivo, claro, el navegador ya lo has cerrado), que te diga por donde va, y despues reestructurar el codigo para quitarle todos los gotos, seguro que hay una forma mejor de hacerlo.

Tengo que mirarlo, todo es posible.

BL, es lo mismo. En el entorno "server side", el hecho de que la máquina que alberga el código php sea la tuya propia (localhost) o un servidor web remoto a 1000 Km. de distancia, es irrelevante.

Lo que de verdad importa es que el código PHP se ejecuta en server side por un proceso (digamos, el proceso servidor web) que nada tiene que ver con el proceso client-side que inició la petición (digamos, el proceso navegador web). Esa, y no otra, es la razón por la que tu código sigue ejecutándose en un "supuesto" segundo plano, aun cuando has cerrado el navegador mediante el cual lo lanzastes.

El hecho de que ambos programas (navegador y servidor web) residan en la misma máquina, es puramente anecdótico. Lo que importa es la separación entre procesos, que es total.

Abres tu navegador, lanzas la petición, y el servidor web comienza a liquidar tu php. Esta es la parte crítica que hay que entender para ver cómo funciona este asunto: "el servidor web comienza a liquidar", es decir, no es tu navegador el que ejecuta el php, sino el proceso servidor web. Ahora verás claro por qué sigue ejecutándose el código cuando cierras el navegador... y es porque el servidor web sigue perfectamente en pie y activo, ejecutando el php que le fue solicitado.

Tienes razón cuando dices que seguramente no es ésta la forma correcta de abordar este problema; estás lanzando un código y perdiendo el control sobre él (detach); esta aproximación te va a dar bastantes dolores de cabeza.

Como mal menor, y ya que estás en local con tu propia máquina, te recomendaría que al menos te olvidases del navegador y ejecutases tu PHP directamente con el intérprete de línea de comandos (ejemplo, php -i programa_de_bl.php).

El modificador -i es ejecución interactiva; esto te acercará más a lo que tú estás buscando, que es un entorno más "tradicional" en el que lo que yo ejecuto pasa a primer plano, y cuando se devuelve el control de la shell al usuario, es sólo porque la ejecución ha terminado realmente.

Tienes que poner atención en entender la sutileza de la diferenciación entre ejecuciones server-side y client-side; ahí reside todo el "misterio", que ya verás con el tiempo y la práctica como no es tal.

Mmm, entendido, pero es que cuando todavía no había puesto las consultas a la base de datos y salía el resultado por pantalla, dándole al botón de detener del navegador aparentemente se detenía, supongo que lo que se detenía era el navegador, que el s-c-r-i-p-t continuaba funcionando ¿no?

En ese caso, antes de darme cuenta de que seguía funcionando, habré llegado a tener al php haciendo lo mismo en segundo plano tropecientas veces y no notaba nada raro, será que consume pocos recursos.

Intentaré ejecutarlo sin navegador, ya veremos, otra opción es hacerlo en c+ y dejarme de inventos raros, una consulta, un parseo y un insert en base de datos no pueden ser tan complejos ni en c+ 😀

¿Es difícil hacerlo en phyton?
 
Exacto, BL... estas ejecuciones pueden ser (y serán!) concurrentes, dado que precisamente un servidor web está pensado para poder hacer spawn (crear) varios hilos y atender varias peticiones simultáneas.

Así que cada vez que pulsabas F5 o "refrescar" en tu navegador, en efecto, lanzabas una copia nueva de tu Missile_Launch_Control.php :roto2:
 

Estadísticas del foro

Temas
2.049.442
Mensajes
58.147.880
Miembros
190.830
Último miembro
Francisco Valero

El blog de burbuja.info

Volver