Italian lamentela sulla nuova versione

[LucaMs]

Mezz'oretta per accendere il tablet, lanciare "l'app", prelevare il log e te lo dico ...

I : 1
J : 1
I : 2
J : 1
I : 3
J : 1
I : 4
J : 1
I : 5
J : 1
I : 6
J : 1
I : 7
J : 1
I : 8
J : 1
I : 9
J : 1
I : 10
J : 1
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 3
J : 3
J : 3
J : 3

 

[Star-Dust]

Il concetto della Sub Resumable esiste in altri linguaggi?

 

[LucaMs]

Il concetto della Sub Resumable esiste in altri linguaggi?

Lessi (bau) qualche post in cui si diceva di sì, ma io non so quali siano e tantomeno li ho mai usati.

[messo il log]

 

[Star-Dust]

Mezz'oretta per accendere il tablet, lanciare "l'app", prelevare il log e te lo dico ...

I : 1
J : 1
I : 2
J : 1
I : 3
J : 1
I : 4
J : 1
I : 5
J : 1
I : 6
J : 1
I : 7
J : 1
I : 8
J : 1
I : 9
J : 1
I : 10
J : 1
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 2
J : 3
J : 3
J : 3
J : 3

non capisco nemmeno il perché dia questo risultato

 

[udg]

non capisco nemmeno il perché dia questo risultato

Non ho ancora installato le nuove versioni di B4A/B4J, ma da quello che ho letto il punto fondamentale è che Sleep/WaitFor agiscono come un "return" nell'ambito del codice in cui sono eseguiti.
Nel caso specifico, ad ogni iterazione su i, viene lanciata la sub Mostra che ovviamente parte da j=1 e poi va in sleep causando un return alla prossima i (ed una nuova esecuzione di Mostra). Questo spiega la serie i1,j1,i2,j1,i3,j1...
Poi ci sono tutti i primi "risvegli" dei 10 giri di i e quindi hai 10 volte j2.. etc.

Se quanto precede è corretto, dovremmo concludere che le 10 iterazioni su 1 sono più veloci di un singolo risveglio di sleep(0).

 

[LucaMs]

Non ho provato ma penso che con VB.Net il risultato sarebbe stato:
i: 1

j: 1
j:2
j:..
J:100

i:2

j: 1
j:2
j:..
J:100

etc.

mentre con queste resumable il controllo torna alla routine chiamante e l'esito è completamente diverso.

Ho provato adesso e confermo che quello è stato il risultato.

 

[LucaMs]

Se quanto precede è corretto, dovremmo concludere che le 10 iterazioni su 1 sono più veloci di un singolo risveglio di sleep(0).

Non è tanto una questione di velocità quanto il fatto che il controllo, con uno sleep nella routine chiamata, torna alla routine chiamante, cosa che non avviene con il DoEvents di VB.Net.

 

[Star-Dust]

Non ho ancora installato le nuove versioni di B4A/B4J, ma da quello che ho letto il punto fondamentale è che Sleep/WaitFor agiscono come un "return" nell'ambito del codice in cui sono eseguiti.
Nel caso specifico, ad ogni iterazione su i, viene lanciata la sub Mostra che ovviamente parte da j=1 e poi va in sleep causando un return alla prossima i (ed una nuova esecuzione di Mostra). Questo spiega la serie i1,j1,i2,j1,i3,j1...
Poi ci sono tutti i primi "risvegli" dei 10 giri di i e quindi hai 10 volte j2.. etc.

Se quanto precede è corretto, dovremmo concludere che le 10 iterazioni su 1 sono più veloci di un singolo risveglio di sleep(0).

Ok, fatico ancora a seguire il flusso del programma.
Ergo non ha lo stesso ruisultato di DoEvents anche se é Sleep(0)... quello zero non é davvero zero

 

[Star-Dust]

Insisto che DoEvents si può sostituire con quello che é un metodo nativo delle Threads che esiste in android e quindi non creato dal compilatore come WaitFor, Sleep e forse anche DoEvents

Dim jo AsJavaObjectDim l As Long = 500
jo.InitializeStatic("java.lang.Thread").RunMethod("sleep", Array(l))

O meglio far eseguire in background il thread e fermarlo con il comando Sleep presente nella libreria Threading che non blocca la GUI anzi permette di aggiornarla... almeno cosi dice lo sviluppatore

 

[LucaMs]

Ho provato il primo metodo che hai proposto, con javaobject (l'ho testato sul codice proposto prima).
Il log a questo punto è come quello di VB.Net ma il problema è che non aggiorna la GUI, quindi si legge 100 solo al termine di tutti i cicli.

 

[Star-Dust]

Ho provato il primo metodo che hai proposto, con javaobject (l'ho testato sul codice proposto prima).
Il log a questo punto è come quello di VB.Net ma il problema è che non aggiorna la GUI, quindi si legge 100 solo al termine di tutti i cicli.

Non posso inventare tutto io
Infatti preferisco la libreria Threading che aggiorna l'interfaccia grafica

 

[LucaMs]

Non posso inventare tutto io
Infatti preferisco la libreria Threading che aggiorna l'interfaccia grafica

eh ma che fai, in ogni caso in cui dovresti creare un loop-pausa con aggiornamento GUI, usi un thread?

 

[Star-Dust]

Ho visto questo codice di esempio pe rla libreria, dove c'è l'aggiornamento della GUI

Sub Button1_Click
Dim args(0) As Object 

Thread1.Initialise("Thread1")
Thread1.Name = "B4A Thread 1"
Thread1.Start(Null, "ThreadSub2", args) 
End Sub

Sub ThreadSub2
    Dim Count As Int
    Dim Params(1) As Object
    Do While Count < 1000
        ' instead of locking like Thread1 we could crudely just wait for the GUI to update
        ' some messages may be lost but this may not matter in some applications
        Count = Count + 1
        Params(0) = Count
        Thread2.RunOnGuiThread("Update2", Params)
        Thread2.Sleep(10)
    Loop
End Sub

Sub Update2(count As Int)
    EditText2.Text = count
    ProgressBar1.Progress = count /10
    Lock2.Unlock
End Sub

 

[udg]

Non è tanto una questione di velocità..

Mi riferivo alla velocità perchè in teoria sleep(0) potrebbe "risvegliarsi" prima che il ciclo di i arrivi a 10. In tal caso avresti una sequenza tipo:
i1 j1 i2 j1 i3 j1 i4 j2 j1 .. se il primo sleep del primo Mostra si risveglia subito dopo i4.

Sono certo che dovremmo studiare meglio tutta la questione e concordo pienamente con LucaMs quando nel forum inglese dice che una dettagliata spiegazione sarebbe opportuna, ma per il momento, sinceramente, non mi sento di dover convertire tutto il mio codice per utilizzare queste nuove possibiltà. (ps: DoEvents mai utilizzato, però).

Edit: una volta abbandonato il caro vecchio (e solido) concetto di flusso procedurale (il programmatore è una divinità che decide l'ordine in cui tutto avviene) per la programmazione ad eventi e quindi la gestione asincrona del flusso (l'utonto e il sistema operativo, scatenano eventi come e quando pare a loro) per quanto mi riguarda mi sento de-responsabilizzato; tutto può accadere, i problemi ci saranno di sicuro ma non dipenderanno interamente da me e quindi potrò dormire tranquillo. Qualcosa non va? Bene, è normale. Nulla funziona in modo perfetto; quindi neanche i miei sw.. (ps: e se, caro utonto, pretendi di pagarli "di meno e con lo sconto", sappi che ti porti a casa una mezza porcheria, nè più nè meno di ciò che compri quotidianamente nei negozi e nei supermercati)

 

[LucaMs]

Non concordo: un sw dev'essere stabile, anche malgrado gli eventi. E dipende da noi programmatori.

Per noi programmatori la gestione degli eventi complica un po' la vita, questo è vero.

Penso (a naso) che dovremmo abituarci ad usare in abbondanza la gestione delle eccezioni e dei flag di stato delle operazioni (molto utile anche per lo stato di un'Actiity).

 

[Star-Dust]

una volta abbandonato il caro vecchio (e solido) concetto di flusso procedurale ...

A me sembra tornare indietro.... come il tanto arcano GOTO 10 che ho abbandonato con fatica perché la programmazione strutturata vieta i salti incondizionati a ca...volo.... e poi .. nasce il Resume SUB che ti fa saltare il flusso come vuole........

hihihihihi

 

[LucaMs]

Cmq, non c'è da drammatizzare; tutta la programmazione è semplice come bere un bicchiere d'acqua:

 

[udg]

Penso (a naso) che dovremmo abituarci ad usare in abbondanza la gestione delle eccezioni..

Appunto. Passiamo da una situazione in cui abbiamo pieno controllo (e responsabilità) ad una navigazione a vista dove il nostro compito non è produrre logica ma imbastire un ampio set di eccezioni sperando che non ne salti fuori ancora una.
Un po' come le leggi in Italia: scrivi (male) una legge e poi prevedi 10mila eccezioni. Così ti assicuri il caos e la possibilità di interpretare le situazioni a tuo piacimento.

Se poi aggiungiamo ciò che MS ha insegnato a tutti noi: non perdere tempo a ripulire ossessivaente il codice, ma pensa a nuove funzionalità (anche se inutili) da dare in pasto agli utonti e confida nel marketing per consentire l'oblio delle tue caz..te strutturali e l'esaltazione dell'effimero di tendenza...

Comunque, visto che il passato ormai è andato e che questi commenti resteranno in giro per tanto tempo, battiamo tutti le manine e diciamo che tutto splende e che siamo convintamente contenti di utilizzare pienamente ciò che il presente ci offre (evviva il pensiero unico anche nel sw!).

 

[LucaMs]

e diciamo che tutto splende e che

va tutto bene, non c'è crisi ed i ristoranti sono sempre pieni

Ah, e che i treni sono sempre in perfetto orario!

 

[udg]

che i treni sono sempre in perfetto orario

Questa dei treni meglio evitarla. Non sia mai che qualcuno pensi ad una tua proibita nostalgia.. eheh