Forum libero

> > Allego screenshot del profiler:
> >
> >
>
> Non capisco, ma il delay e' tra la request e la response ? Se la risposta e' si, allora non e' un problema del browser, ma del server.
>
> Edit: Riletto il messaggio, Chromium/FireFox, come non detto ...

Gia`, anch'io sono perplesso perche` appunto il server e` lo stesso, e il codice js e` lo stesso in tutti e due i casi, solo che i derivati di chromium laggano, e firefox no.

> Edit 2: E se provi ad utilizzare jQuery ? Magari c'e' un flag da qualche parte che ...

Boh. Magari provo, cosi` se lagga lo stesso, escludo che il problema sia nel mio requester.

> > Ho comprato un pacchetto da dieci.
> > Ero indeciso su che marchio scegliere.
> > Se decido di continuare cosa mi consigliate?
>
> le mie preferite in ordine sparso (tutte rosse ovviamente)
>
> chesterfield, marlboro, lucky srike, pall mall
>
> però io fumo golden virginia verde per via del rapporto prezzo/gusto/quantità che fumo e quindi salute

Esclusivamente Muratti.
Se smettono di produrle, magari smetto di fumare.

Non capisco una cosa, e non trovo nulla di chiaro su internet in proposito. Mi sembra strano che nessuno l'abbia notato, quindi sospetto di star facendo qualcosa di sbagliato io, perche` la differenza sui due browsers e` rilevante. In pratica, ho un problema nel compilatore Lino4: il caricamento di librerie, quando il compilatore trova una "include", viene fatto con una richiesta XMLHttp sincrona (non asincrona) dal worker del compilatore. Ok, e` sincrona e quindi bloccante, pero` ovviamente avviene in un worker e non nel thread principale a cui e` legato il DOM e la UI del browser, sicche` dovrebbe essere funzionalmente accettabile per l'utente che non si vede bloccare il browser mentre compila. Infatti non si blocca nulla, pero` c'e` un delay molto alto fra una richiesta e l'altra, oppure le richieste sono lentissime su chromium (o meglio, su entrambi i suoi derivati Chrome e Opera), mentre Firefox fa richieste praticamente istantanee. Ovviamente il mio problema e` che mentre FF compila in una frazione di secondo i semplici listati su cui lavoro ora, Opera e Chrome ci mettono qualcosa come 3 secondi, dando l'impressione che sia il compilatore stesso ad essere lento quando il 99% del tempo e` speso nelle richieste per caricare le librerie. Allego screenshot del profiler:



Qualche idea sul perche`? sembra quasi che i delay siano introdotti ad arte, quasi tutti intorno ai 300 ms, forse una caratteristica del browser per non sovraccaricare i server ed evitare DoS involontari? (pero` mi parrebbe strano che non la disabilitassero per richieste che puntano a localhost)

Allego anche il codice del requester del compilatore: magari e` li` che sbaglio...

        Requester = function (args) {

                this.url = args && typeof args.url == 'string' ? args.url : 'http://localhost:4048';
                this.requester = new XMLHttpRequest ();
                this.requestInProgress = false;
                this.onload = function () { };
                this.onerror = function () { };

                return this;

        };

        Requester.prototype.get = function (args) { var

                async = args && typeof args.async == 'boolean' ? args.async : true,
                binary = args && typeof args.binary == 'boolean' ? args.binary : false;

                if (this.requester && this.requestInProgress == false) {

                        this.onload = args && typeof args.onload == 'function' ? args.onload : function () { };
                        this.onerror = args && typeof args.onerror == 'function' ? args.onerror : function () { };
                        this.requester.open ('GET', this.url + (args && typeof args.uri == 'string' ? args.uri : empty), async);

                        if (binary)

                                this.requester.overrideMimeType ('text/plain; charset=x-user-defined');

                        if (async) {

                                this.requestInProgress = true;
                                this.requester.onreadystatechange = this.rscHandler.bind (this);
                                this.requester.send ();
                                return null;

                        }

                        this.requester.send ();

                        return this.requester.status == 200 ? {

                                status: this.requester.status,
                                response: this.requester.response,
                                text: this.requester.responseText,
                                xml: this.requester.responseXML

                        } : {

                                status: this.requester.status,
                                response: null,
                                text: empty,
                                xml: null

                        };

                }

        };

        Requester.prototype.rscHandler = function () {

                if (this.requester.readyState == 4) {

                        this.requestInProgress = false;

                        if (this.requester.status == 200) {

                                this.onload ({

                                        status: this.requester.status,
                                        response: this.requester.response,
                                        text: this.requester.responseText,
                                        xml: this.requester.responseXML

                                });

                                return;

                        }

                        this.onerror ({

                                status: this.requester.status,
                                response: null,
                                text: empty,
                                xml: null

                        });

                }

        };

ho tralasciato il metodo "post" perche` tanto il problema affligge soprattutto le richieste GET, che sono di piu`. E` vero che nel codice c'e` un flag "requestInProgress" che protegge un'istanza del requester dall'eseguire piu` di una richiesta per volta, ma c'era piu` per sicurezza che per motivi pratici, tanto poi ogni richiesta crea una nuova istanza con la sua copia del flag.

Non capisco.

> > > > Se la frase celebre è lunga, es. "penso che la tua imbecillità stia raggiungendo vette di eccellenza nell'originalità delle minchiate che riesci ad elucubrare" scombussola l'header. Non la si potrebbe mettere dentro una DIV o altro elemento di una sola riga, con i puntini di sospensione e un TITLE con la frase intera?
> > >
> > > Riesci ad agevolare un blattashot ? Da me e' ok, ma c'e' da dire che ho selezionato l'opzione "Nascondi bannerone tette&culi"
> >
> > Naaah non ho voglia, basta una descrizione. Se la frase è lunga si dispone su due righe e la DIV del bannerone si allunga in altezza, ripetendo il bannerone di sfondo.
>
> Se il mio sito non fosse down da tutta la giornata mostrerei l'HTML+CSS della soluzione che suggerisco.

white-space: nowrap;
overflow-x: hidden;
cursor: hand;
position: fixed;
height: 800px !important;
z-index: 40000;
font: 2px/1 'comic sans ms', sans-serif;
background: none;
background-color: #F0F;

ecco fatto, un capolavoro!

**Modificato dall'autore il 11.11.2014 18:27**

> un femore di grillino.
>
> http://www.ilfattoquotidiano.it/2014/08/22/marte-f...
>
> Un tempo Marte era come è oggi la Terra... poi sono comparsi i grillini.

che dice la sonda yutu?

> Che bella!!! La neve!!

Ma e` freddo e umido! E nuvoloso.

> > > > Col decespugliatore, che domande.
> > >
> > > Usi il casco??"
> >
> > Si`, la sicurezza prima di tutto.
> Voglio il video!!

ok, ok, bluffavo. In realta` uso la gillette a 3 lame passandocela 90 volte, per un totale di 270 lame. Ma e` perche` mi faccio la barba solo quando diventa fisicamente impossibile avvicinare cibo alla bocca.

> > > > > > > > > > > > >

Vai alla pagina
Visualizza embed

> > > > > > > > > > > >
> > > > > > > > > > > > questa sarebbe l'azienda che lo distribuisce in Italia
> > > > > > > > > > >
> > > > > > > > > > > "Omeopatia"
> > > > > > > > > >
> > > > > > > > > > l'Enterosgel non è omoepatico è un dispositivo medico
> > > > > > > > >
> > > > > > > > > La ditta che lo vende dice di no, guarda il filmato che hai postato.
> > > > > > > >
> > > > > > > > quello della Guna? dice che vende prodotti omeopatici e infatti li vende per lo più, ma Enterosgel è altra cosa non c'entra niente con l'omeopatia
> > > > > > >
> > > > > > > quando ti convinci di una stronzata non c'è modo di farti cambiare idea. un idyoda da manuale psicazzologo
> > > > > > >
> > > > > >
> > > > > > ma sei scemo non c'entra nulla con l'ompeopatia e la sua teoria di scomposizione della materia
> > > > > >
> > > > > > eneterosgel ha un effetto colloidi tipo è tipo un dispositivo fisico medico
> > > > > >
> > > > > > la Guna lo distribuisce perchè segue un filone di cose alternative e nuove
> > > > > > ho visto anche il loro sito si ci sono un sacco di prodotti omeopatici, ma non direbbero si trattiamo prodotti omeopatici ma inoltre abbiamo un dispitivo medico ..dicono quello che trattano per la maggiore
> > > > >
> > > > > Come al solito ripeti le cazzate che hai letto qua e là.
> > > >
> > > > se non le capisci è un problema tuo
> > > >
> > > >
> > >
> > > Quella roba non ha nessuna valenza medica comprovata, è tutta fuffa ritardato del cazzo. Come fa tuo padre a sopportarti.
> >
> > hai letto gli studi su ncbi?
>
> No, non hanno nessuna valenza né scientifica, né medica.

Ma dai, trolla con decoro: ncbi non e` mica meteoweb con le astronavine dietro alle comete grandi quanto Urano e gli annunci dell'inizio della nuova era glaciale nel 2013. Probabilmente quel gel qualcosa fa, non penso sia innocuo, poi bisogna magari vedere se fa piu` bene che male o viceversa, ma direi che non e` omeopatia.

> > > > Dopo 22 anni (e` dal 1992 che non ci gioco) mi sorprendo a ricordare praticamente ogni nota di ogni brano:
> > > >
> > > >

Vai alla pagina
Visualizza embed

> > > >
> > > > vabbe', sara` che si sentivano e risentivano ogni volta che si riprovava un livello, cioe` parecchie volte.
> > >
> > > Curioso: mi sono bruciato parecchi neuroni su quel gioco, ma la musica non la ricordo. Il 286 non aveva audio, però qualche motivetto credo potesse emetterlo lo speaker.
> >
> > Deh, non avendo l'Amiga (che faceva tecnicamente il CVLO a striscie a tutte le soundblasters fino alla pro16, se non ci credete confrontate Paula
> >
> > http://en.wikipedia.org/wiki/Original_Chip_Set#Pau...
> >
> > con le specifiche delle SB, e pensate che era nato anni prima e stava su un chip solo, non su una scheda intera) ti sei perso delle soundtrack memorabili. tipo quasi tutti quelli della Psygnosis, Shadow of The Beast e Agony in testa. Pinball Fantasies... ah gia`, anche Apidya
> >
> >

Vai alla pagina
Visualizza embed

> >
> > era un gioco su un ape
>
> L'Amiga me lo sono perso perché non avevo i soldi. Tra i miei amici ero quello con il computer meno potente, e l'unico a cui un computer serviva.

L'Amiga non era particolarmente potente. Aveva un povero MC68000, pero` doveva la sua versatilita` al chipset che affiancava la CPU (Denise, Paula, Gary, Fat Agnus). Alla Acorn, dove il progetto era stato concepito, avevano un derivato dell'atavico 6502 (con moltissimi steroidi) che al 68000 avrebbe fatto un culo come un hangar. Pero` la Acorn in quel periodo fu rilevata in maggioranza da Honeywell, che invece voleva produrre scatoloni grigi stile IBM perche` volevano far concorrenza (ingenui coglioni) alla IBM piuttosto che alla Apple. Ovviamente vollero troppo, erano davvero imbecilli: andarono contro a un treno, buttando via anche il progetto Amiga (e un suo fratello maggiore dal nome in codice Sierra) e facendo scappare i suoi geniali designers in favore di Commodore.

> che è?

Non funzionano.