Torna indietro   Hardware Upgrade Forum > Software > Programmazione

ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere
HONOR ha introdotto con Magic6 Pro la funzione Magic Portal che consente, tramite intelligenza artificiale, di suggerire scorciatoie agli utenti in modo da permettere di passare e accedere facilmente ai servizi tra app e dispositivi con un semplice tocco. Vi spieghiamo qui come funziona
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 23-10-2017, 12:04   #21
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
si, ma non e' che stai facendo un 'casting'. Sono 1 e 3 che appartengono ai Reali e non agli Interi in quel caso. La divisione e' sempre matematicamente definita come un'operazione interna all'insieme su cui si applica.
E questo e' il punto. Io ho formalmente dichiarato la variabile di destinazione come float, quindi reale, chiarendo la mia intenzione di voler operare nel campo dei numeri reali.


Quote:
Originariamente inviato da GTKM Guarda i messaggi
Se stai facendo una divisione fra interi, nel campo dei numeri interi, non si scappa.
Ma x era float, non int.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Il C fa la divisione fra due interi e, GIUSTAMENTE, restituisce il risultato intero. Gli altri linguaggi possono pure permetterti di assegnare 1.3333 ad un intero senza troncare, resta il fatto che MATEMATICAMENTE 1.3333 NON e' intero.
E infatti x era float. E faccio notare che gli insiemi N e Z sono contenuti in R! Dunque e' perfettamente lecito pretendere che quella divisione restituisce un float invece di un int.

Come, ripeto, molti linguaggi fanno.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 12:25   #22
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Quote:
Originariamente inviato da pabloski Guarda i messaggi

E infatti x era float. E faccio notare che gli insiemi N e Z sono contenuti in R! Dunque e' perfettamente lecito pretendere che quella divisione restituisce un float invece di un int.

Come, ripeto, molti linguaggi fanno.
Tu hai scritto:
Quote:
int a;
int b;
dicendo quindi di voler operare nel campo dei numeri interi. Per cui, la divisione che vuoi usare e' definita negli interi e dara' come risultato UN INTERO.

Il fatto che N "appartenga" a R non ha alcuna rilevanza matematica. Tu vuoi fare una divisione IN N.

Cosi' come, nel campo dei numeri reali, l'equazione che ho scritto prima NON HA SOLUZIONE. EPPURE R e' "contenuto" in C.

Il fatto che altri linguaggi ti permettano di assegnare 0.33 ad un intero non e' un motivo per sputtanare la matematica.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 13:40   #23
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Aggiungo che, forse, di matematica i progettisti del C qualcosina ne capivano, visto che Dennis Ritchie era laureato in Fisica e Matematica applicata.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 15:29   #24
ingframin
Senior Member
 
L'Avatar di ingframin
 
Iscritto dal: Apr 2010
Città: Leuven
Messaggi: 667
Wow, che mega discussione, non ho aperto hwupgrade per un paio di giorni...
Senza entrare nel merito di C vs resto del mondo (a me C piace, lo uso per i miei progetti hobbistici e per codingame!) in azienda non ho mai visto usare haskell.
Nel mondo embedded C e C++ si usano tantissimo assieme a Python, quest'ultimo per i test e per l'interfacciamento pc->sistema embedded.

C++ non mi dispiace ma per certe cose è davvero complicato. Inoltre non l'ho mai usato per lavoro (a differenza di C e Python), quindi sono abbastanza un principiante.

Siccome ho mandato tutto al diavolo, ho lasciato il lavoro e ho cominciato un dottorato all'università, non devo più sottostare ai dettami dell'industria e posso sbizzarrirmi per i prossimi 4 anni.

Perciò volevo tentare Haskell. Secondo me viene bene per analizzare i dati e fare statistica. Il compilatore (almeno a detta del web) è ottimo e gira bene dappertutto. Inoltre sono abbastanza convinto di poterlo usare per AI.

Ocaml è più facile di haskell ma il supporto per Windows è orrendo
__________________
L'elettronica digitale non esiste, è solo elettrotecnica con interruttori piccoli!
ingframin è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 22:31   #25
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Sei serio? Quindi se il professore di matematica ti dava da fare 1/3 tu dicevi che faceva zero? nonostante stesse spiegando i numeri reali?

Suvvia non siamo banali. Una divisione NON INTERA ( cioe' il risultato non dev'essere intero ) tra interi e' un numero reale, non un intero.

Del resto se chiedi a Python quanto fa 1/3 lui risponde 0.33333.

Se poi vogliamo stravolgere pure la mamematica per difendere il C...
Invece hanno ragione loro, proprio se tiriamo in ballo la matematica: su un dominio definito, le operazioni sono omogenee e definite nello stesso dominio. Quindi una divisione intera restituisce un risultato intero.

In Python:
Codice:
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
DreamPie 1.2.1
>>> 1 / 3
0: 0
Che poi non si capisce il motivo per cui una divisione dovrebbe restituire per forza un float (numero "reale").

In Python, dove si può fare questo:
Codice:
>>> from fractions import Fraction
>>> a = Fraction(1)
>>> b = Fraction(3)
>>> c = a / b
>>> c
1: Fraction(1, 3)
>>> print c
1/3
a questo punto avrebbe molto più senso restituire una frazione, che è di gran lunga più preferibile in quanto perfettamente in grado di rappresentare la divisione, al contrario dei float che possono restituire soltanto un'approssimazione.
Perché non girano su Atmel, ma su ben più potenti ARM Cortex-M3 o M4, e con parecchia memoria flash e RAM a bordo.

Anche jerryscript richiede parecchie risorse:

"Only few kilobytes of RAM available to the engine (<64 KB RAM)
Constrained ROM space for the code of the engine (<200 KB ROM)"


E anche la più scarsa scheda per MicroPython richiede una valanga di risorse:

"96 MHz Cortex M4 CPU with hardware floating point
512KiB flash ROM and 128KiB RAM"


Queste schede vanno bene per giocarci con qualche progetto amatoriale, ma se devi realizzare qualcosa di serio, e mi riferisco a prodotti da migliaia o molti più pezzi, diventano assolutamente antieconomici e praticamente impossibili da adottare, perché trovi degli Atmel (che fanno schifo, eh! Mica fa piacere lavorare con così poche risorse) a prezzi da quasi un ordine di grandezza meno.
Quote:
Si tutto bello, ma qui il punto sono le astrazioni che il linguaggio offre al programmatore. Lo scopo dei linguaggi di programmazione e' di avvicinarsi il piu' possibile al modo di pensare dell'uomo. Il C invece e' molto piu' vicino ala macchina che all'uomo.
Purtroppo il C non è nemmeno vicino alla macchina, visto che rimane comunque un'astrazione troppo elevata. Se fosse realmente vicino alla macchina, si potrebbero fare certi giochetti per migliorare le prestazioni in certi ambiti. Invece si deve ricorrere all'assembly.

Comunque in linea generale è vero che un linguaggio cerca di essere strutturato in modo da essere più facilmente fruibile dall'uomo, ma non è sempre così, e soprattutto la cosa che non si può dimenticare è che importante l'ambito di utilizzo.

I linguaggi servono a risolvere determinati problemi: è questo lo scopo primario per cui sono nati.
Quote:
E no, avvicinarsi all'uomo non vuol dire creare un runtime da 2GB, pieno zeppo di garbage collector, compilatori jit e altre diavolerie. Esistono altre strade, quella seguita da Haskell ad esempio.
Che è scarsamente efficiente, però. E fa venire il mal di testa proprio all'uomo di cui parlavi prima.
Quote:
Rust mi aiuta ad evitare errori stupidi e in piu' mi offre l'efficienza e il determinismo di un linguaggio senza garbage collector. Come la mettiamo? In C come fai? Il modello di programmazione del C ti aiuta ad evitare le race conditions? NO!
Ma almeno ha una sintassi più semplice di Rust. Quelli che hanno progettato Rust si sono dimenticati proprio degli esseri umani che dovrebbero usarlo.
Quote:
In ambiti dove i bug sono una cosa seria, si cerca di evitare C e compagni come la peste. Haskell e' usatissimo nell'industria finanziaria per questa ragione. I linguaggi funzionali in generale sono usati in ambiti come quello aerospaziale, medicale, industriale. I microcontrollori programmati esclusivamente in C fanno parte del passato, oggi ci si guarda intorno prima di buttarsi a capofitto su C/C++.
Vedi sopra: a livello amatoriale si può usare altro. Ma nell'industry, dove il numero di pezzi da produrre è molto elevato, C e C++ rappresentano l'unica alternativa all'assembly.

E anche qui ti assicuro che i bug sono una cosa serissima.
Quote:
Originariamente inviato da pabloski Guarda i messaggi
E questo e' il punto. Io ho formalmente dichiarato la variabile di destinazione come float, quindi reale, chiarendo la mia intenzione di voler operare nel campo dei numeri reali.
Ma l'operazione di divisione l'hai applicata a due numeri interi: è questo il punto.
Quote:
Ma x era float, non int.
E quindi DOPO converti il risultato in float.
Quote:
E infatti x era float. E faccio notare che gli insiemi N e Z sono contenuti in R! Dunque e' perfettamente lecito pretendere che quella divisione restituisce un float invece di un int.

Come, ripeto, molti linguaggi fanno.
A questo punto è meglio che il risultato sia una frazione, come ho detto sopra: almeno non perdi precisione per strada.

Ma poi, visto che R è contenuto in C, perché non convertire direttamente la divisione in un numero complesso?
Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
MM. cosa intendi con 'analisi dati'? Secondo me se devi fare script per calcoli spicci + statistica python va benone.
Concordo. Di recente s'era affacciato anche R specificamente per questo tipo di calcoli / applicazioni, ma Python è tornato a sopravanzare anche in questo campo, forte dell'enorme supporto che ormai ha, e che continua a espandersi.
Quote:
Detto questo io consiglio vivamente a chi piace l'informatica(non la programmazione nb.) di imparare Haskell perche' non ho mai trovato un linguaggio piu' pedagogico. e' veramente una bestia strana rispetto al 99% degli altri linguaggi.
Prova con Prolog. A me è bastato Scheme prima e soprattutto Prolog dopo, all'università. Per cui... ho già dato.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 24-10-2017, 09:35   #26
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Tornando in tema, chi si trova in ambiente Windows puo' scegliere indistintamente tra F# e Haskell, o uno e' "meglio" dell'altro?
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 24-10-2017, 10:48   #27
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Quote:
Originariamente inviato da cdimauro Guarda i messaggi

"96 MHz Cortex M4 CPU with hardware floating point
512KiB flash ROM and 128KiB RAM"


Queste schede vanno bene per giocarci con qualche progetto amatoriale, ma se devi realizzare qualcosa di serio, e mi riferisco a prodotti da migliaia o molti più pezzi, diventano assolutamente antieconomici e praticamente impossibili da adottare, perché trovi degli Atmel (che fanno schifo, eh! Mica fa piacere lavorare con così poche risorse) a prezzi da quasi un ordine di grandezza meno.

Purtroppo il C non è nemmeno vicino alla macchina, visto che rimane comunque un'astrazione troppo elevata. Se fosse realmente vicino alla macchina, si potrebbero fare certi giochetti per migliorare le prestazioni in certi ambiti. Invece si deve ricorrere all'assembly.
Mi chiedo una cosa però il tempo speso ad inseguire i SEGFAULT, memory leak ecc del C che sicuramente un programmatore perderà (perché anche se uno un genio magari sotto stress si "emoziona" e il C è sempre pronto a metterlo nello stoppino) non supereranno in breve i 20 / 30 € risparmiati per comprare una scheda decente?
Se poi magari i programmatori sono 5 / 6 tutti occupati a cercare di risolvere a suon di baccate bug diversi...

Noi abbiamo trovato in un codice C che sarà un 1'000'000 di righe bug che sono apparsi dopo 15 anni cambiando qualcosa in un posto totalmente diverso... ci siamo stati un mese a trovarlo!

Mah...

Comunque sì la divisione tra 2 interi fa un intero eventualmente con il resto

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Tornando in tema, chi si trova in ambiente Windows puo' scegliere indistintamente tra F# e Haskell, o uno e' "meglio" dell'altro?
Difficile rispondere credo alla fine vada un po' a gusti... F# ha il vantaggio di avere accesso a tutto il runtime .NET (che però a F# non piace tantissimo visto che tutto dovrebbe essere immutabile e null non esiste in F#) così puoi interoperare con C#, VB.NET o IronPython se ti piace...

Haskell ha il concetto di null?
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!

Ultima modifica di fano : 24-10-2017 alle 10:51.
fano è offline   Rispondi citando il messaggio o parte di esso
Old 24-10-2017, 11:29   #28
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Dunque, da un punto di vista didattico, e' meglio andare di Haskell rispetto a F#?
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 24-10-2017, 11:57   #29
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
No .. o almeno, in Haskell puoi definire i concetti che ti pare nel programma. Quindi se ti serve null te lo crei (solitamente e' usato il tipo Maybe.. ma ovviamente e' opzionale)
Direi che se si usa un linguaggio funzionale (o se si dovesse ridisegnare un nuovo linguaggio di qualsiasi tipo) e uno pensa di re-introdurre null sta facendo qualcosa di sbagliato.

In F# "puro" non esiste null tutte le API sono riscritte per usare un concetto analogo a Maybe purtroppo null può riapparire come "poison" se si chiamano librerie scritte in C#.

Microsoft sta cercando per la versione 8.0 di C# di introdurre il concetto che gli oggetti sono sempre non null un po' l'inverso del nullable che fecero per i tipi primitivi in versioni precedenti... credo sia davvero difficile retrofittare un linguaggio pensato per avere null ovunque a non averli più.

Il null è un errore da un 1'000'000 di €

Fibonacci in F#:

Codice:
// Recursive function that implements the looping
// (it takes previous two elements, a and b)
let rec fibsRec a b =
  if a + b < 400 then
    // The current element
    let current = a + b
    // Calculate all remaining elements recursively 
    // using 'b' as 'a' and 'current' as 'b' (in the next iteration)
    let rest = fibsRec b current  
    // Return the remaining elements with 'current' appended to the 
    // front of the resulting list (this constructs new list, 
    // so there is no mutation here!)
    current :: rest
  else 
    [] // generated all elements - return empty list once we're done

// generate list with 1, 2 and all other larger fibonaccis
let fibs = 1::2::(fibsRec 1 2)
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!

Ultima modifica di fano : 24-10-2017 alle 12:00.
fano è offline   Rispondi citando il messaggio o parte di esso
Old 24-10-2017, 17:01   #30
ingframin
Senior Member
 
L'Avatar di ingframin
 
Iscritto dal: Apr 2010
Città: Leuven
Messaggi: 667
Quote:
Originariamente inviato da Antonio23 Guarda i messaggi
[ot] non sei piu' in Nokia? [/ot]
No, ho dato le dimissioni in primavera e ho finito di lavorare li il 31 agosto.
Ho fatto application per un dottorato alla ku leuven e mi hanno preso!
Ora mi occupo di comunicazioni wireless tra droni.
La situazione in Nokia era diventata un po' ripetitiva e i miei progetti costantemente cancellati e alla fine mi sono seccato.
Anche perché finché non finivo un progetto per intero non ero indipendente dagli altri per portare avanti un progetto da solo. Poi mi ero anche stufato di testare convertitori DC/DC. Purtroppo ogni mia proposta di qualcosa di innovativo veniva blastata all'istante, anche col mio capo che mi dava manforte.
Vedremo quando finisco qui, sicuramente tenterò di rientrare in Nokia (magari ai bell labs?).
__________________
L'elettronica digitale non esiste, è solo elettrotecnica con interruttori piccoli!
ingframin è offline   Rispondi citando il messaggio o parte di esso
Old 24-10-2017, 20:02   #31
ingframin
Senior Member
 
L'Avatar di ingframin
 
Iscritto dal: Apr 2010
Città: Leuven
Messaggi: 667
Crepi il lupo!
__________________
L'elettronica digitale non esiste, è solo elettrotecnica con interruttori piccoli!
ingframin è offline   Rispondi citando il messaggio o parte di esso
Old 27-10-2017, 06:44   #32
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da fano Guarda i messaggi
Mi chiedo una cosa però il tempo speso ad inseguire i SEGFAULT, memory leak ecc del C che sicuramente un programmatore perderà (perché anche se uno un genio magari sotto stress si "emoziona" e il C è sempre pronto a metterlo nello stoppino) non supereranno in breve i 20 / 30 € risparmiati per comprare una scheda decente?
Se poi magari i programmatori sono 5 / 6 tutti occupati a cercare di risolvere a suon di baccate bug diversi...
E' una mera questione di numeri. Se hai da realizzare un progetto che prevede la realizzazione anche di solo 1000 schede, 20€ in più a pezzo sono 20 mila € che devi scucire. 20K/€ sono circa 6-9 mesi di stipendio di uno sviluppatore (in Italia).

Anche se lo metti un mese intero soltanto a fare debug sul SoC economico, hai comunque risparmiato un sacco di soldi rispetto all'impiego del SoC che ti costa 20€ in più.

E parliamo di 1000 pezzi. Ma per certi progetti puoi arrivare ad avere anche 100 mila, o anche 1 milione di pezzi. E lì anche UN solo euro di differenza pesa moltissimo.

Purtroppo con l'embedded è così. Gioie, ma soprattutto dolori. Che si devono sorbire gli sviluppatori (chi non vorrebbe il SoC più strafico da programmare con linguaggio che uno preferisce e/o che gli fa risparmiare tempo in debug?).

Alla fine per l'azienda è spesso molto, ma molto più conveniente spendere qualche mese/uomo che vagonate di soldi in SoC più costosi.
Quote:
Noi abbiamo trovato in un codice C che sarà un 1'000'000 di righe bug che sono apparsi dopo 15 anni cambiando qualcosa in un posto totalmente diverso... ci siamo stati un mese a trovarlo!

Mah...
Ma serve unit test, ecco il punto. Anche con linguaggi come il C.

Quel progetto sarà frutto di un modo di lavorare "all'antica", dove il testing si faceva a mano, a prodotto finito. Poteva andare bene 15 anni fa, ma non oggi. Specialmente con tutte quelle linee di codice.

Ovviamente realizzare una test suite adesso penso sia impensabile e inutile, se dovete apportare giusto qualche modifica ogni tanto, raramente. Ma è da mettere seriamente in considerazione se ci lavorate più spesso, e non serve realizzarla subito: un po' alla volta, introducete test proprio nel codice che state andando a modificare.
Quote:
Originariamente inviato da ingframin Guarda i messaggi
No, ho dato le dimissioni in primavera e ho finito di lavorare li il 31 agosto.
Ho fatto application per un dottorato alla ku leuven e mi hanno preso!
Ora mi occupo di comunicazioni wireless tra droni.
La situazione in Nokia era diventata un po' ripetitiva e i miei progetti costantemente cancellati e alla fine mi sono seccato.
Anche perché finché non finivo un progetto per intero non ero indipendente dagli altri per portare avanti un progetto da solo. Poi mi ero anche stufato di testare convertitori DC/DC. Purtroppo ogni mia proposta di qualcosa di innovativo veniva blastata all'istante, anche col mio capo che mi dava manforte.
Vedremo quando finisco qui, sicuramente tenterò di rientrare in Nokia (magari ai bell labs?).
Quindi avresti pure intenzione di espatriare? Ricorda che gli "alieni" (è così che li chiamano in USA i lavoratori che provengono dall'estero usufruendo del visto H-B1) non hanno il posto assicurato, e che per risiedere permanentemente dopo un po' di anni devi avere la fortuna d'essere estratto a un'apposita lotteria.

In ogni caso spero che il cambio ti giovi e che ti trova bene col dottorato. Poi un lavoro uno come te lo trova sicuramente ovunque.

In bocca al lupo!
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 27-10-2017, 11:43   #33
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
E' una mera questione di numeri. Se hai da realizzare un progetto che prevede la realizzazione anche di solo 1000 schede, 20€ in più a pezzo sono 20 mila € che devi scucire. 20K/€ sono circa 6-9 mesi di stipendio di uno sviluppatore (in Italia).

Anche se lo metti un mese intero soltanto a fare debug sul SoC economico, hai comunque risparmiato un sacco di soldi rispetto all'impiego del SoC che ti costa 20€ in più.

E parliamo di 1000 pezzi. Ma per certi progetti puoi arrivare ad avere anche 100 mila, o anche 1 milione di pezzi. E lì anche UN solo euro di differenza pesa moltissimo.

Purtroppo con l'embedded è così. Gioie, ma soprattutto dolori. Che si devono sorbire gli sviluppatori (chi non vorrebbe il SoC più strafico da programmare con linguaggio che uno preferisce e/o che gli fa risparmiare tempo in debug?).

Alla fine per l'azienda è spesso molto, ma molto più conveniente spendere qualche mese/uomo che vagonate di soldi in SoC più costosi.
Guarda nel mio caso si tratta comunque di un normale X86, con ATOM a 1.91 GHz dual core certo non è tutta sta "fichezza", ma doversi ridurre a scrivere milioni di righe in C invece che in un linguaggio sensato tipo C# o Java non mica senso per me... è questione anche di mentalità temo i miei colleghi continuano a credere che C# sia interpretato e sghignazzano nella loro ignoranza
... nel caso di Cosmos poi sparirebbe anche un altro punto di "incertezza" il JIT essendo tutto compilato AOT certo se poi ci si mena la fava con il GC beh allora siamo fritti!
Più veloce, ma con memory leak? Boh...

Anche la parte più real time che non facciamo noi sempre schede ARM (prima erano Motorola quindi tipo "Amiga") che credo almeno 256 MB di RAM ce le abbiamo alla fine non credo che C sia davvero necessario lo è nella loro "mente"!
30 anni fa sarebbe stato scritto in Fortan e il "giovane ribelle" sarebbe stato quello che voleva scriverlo in C

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ma serve unit test, ecco il punto. Anche con linguaggi come il C.

Quel progetto sarà frutto di un modo di lavorare "all'antica", dove il testing si faceva a mano, a prodotto finito. Poteva andare bene 15 anni fa, ma non oggi. Specialmente con tutte quelle linee di codice.

Ovviamente realizzare una test suite adesso penso sia impensabile e inutile, se dovete apportare giusto qualche modifica ogni tanto, raramente. Ma è da mettere seriamente in considerazione se ci lavorate più spesso, e non serve realizzarla subito: un po' alla volta, introducete test proprio nel codice che state andando a modificare.
Sì alcune parti di quel codice sono anche più vecchie di 15 anni ho colleghi più giovani di quel codice pensa un po'
Comunque come faccio a fare un unit test visto che ho bisogno di periferiche esterne che si "sollecitano"? Dovrei simulare anche loro?
Spesso è richiesta anche un interazione umana...

Con le nuove versioni ri-scritti di sana pianta abbiamo iniziato a "simulare" la pressione dei tasti con xdotools, ma lo usiamo più per vedere se il C sta sbordando sul mio codice o se ci sonoo memory leak praticamente gli dici fai 10'000 transazioni e lo si lascia a soffrire tutto l'week end e poi vediamo se è sopravvissuto, ma non ho idea di come verificare che le 10'000 transazioni sono tutte giuste se non si è bloccato è OK per me
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 27-10-2017, 13:32   #34
ingframin
Senior Member
 
L'Avatar di ingframin
 
Iscritto dal: Apr 2010
Città: Leuven
Messaggi: 667
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
E' una mera questione di numeri. Se hai da realizzare un progetto che prevede la realizzazione anche di solo 1000 schede, 20€ in più a pezzo sono 20 mila € che devi scucire. 20K/€ sono circa 6-9 mesi di stipendio di uno sviluppatore (in Italia).
Confermo al 100%! Ho dovuto litigare anche per 10 centesimi in più a volte.
Inoltre il costo dello sviluppatore è una tantum, è un costo fisso, mentre i costi di produzione sono variabili. I costi fissi si dividono su tutta la produzione, quelli variabili aumentano. Quindi meglio spendere un po' di più in sviluppo (= pochissimo quando si va di produzione in volumi) che un poco di più su ogni unità prodotta.

È anche una questione di consumi comunque. SoC e processori più piccoli e con meno ram consumano molto meno di processori più sofisticati. Anche li si parla di milliwatt a volte ma su tante unità fanno la differenza. Io ho lavorato sui sistemi per VDSL e G.fast. Soprattutto questi ultimi a volte sono reverse powered = prendono energia dalla linea telefonica dell'utente. Li anche 100mW fanno la differenza perché il sistema deve poter accendersi anche con un solo utente collegato. Un utente fornisce mediamente 7~8W. Non è che per fare felice il programmatore di turno felice e contento puoi tirarne 50W.
Se vuoi farti un'idea poco precisa ma realistica di come vanno le cose, ti consiglio di giocare a Shenzhen I/O! (che è un gioco fichissimo tra l'altro )
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Quindi avresti pure intenzione di espatriare? Ricorda che gli "alieni" (è così che li chiamano in USA i lavoratori che provengono dall'estero usufruendo del visto H-B1) non hanno il posto assicurato, e che per risiedere permanentemente dopo un po' di anni devi avere la fortuna d'essere estratto a un'apposita lotteria.

In ogni caso spero che il cambio ti giovi e che ti trova bene col dottorato. Poi un lavoro uno come te lo trova sicuramente ovunque.

In bocca al lupo!
Crepi il lupo!
Ci sono i Bell Labs qui ad Anversa, non è necessario andare in USA
(Sempre ammesso che mi prendano, non è mica così facile entrarci )
__________________
L'elettronica digitale non esiste, è solo elettrotecnica con interruttori piccoli!

Ultima modifica di ingframin : 27-10-2017 alle 13:38.
ingframin è offline   Rispondi citando il messaggio o parte di esso
Old 27-10-2017, 21:14   #35
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Quote:
Originariamente inviato da ingframin Guarda i messaggi
Confermo al 100%! Ho dovuto litigare anche per 10 centesimi in più a volte.
Inoltre il costo dello sviluppatore è una tantum, è un costo fisso, mentre i costi di produzione sono variabili. I costi fissi si dividono su tutta la produzione, quelli variabili aumentano. Quindi meglio spendere un po' di più in sviluppo (= pochissimo quando si va di produzione in volumi) che un poco di più su ogni unità prodotta.

È anche una questione di consumi comunque. SoC e processori più piccoli e con meno ram consumano molto meno di processori più sofisticati. Anche li si parla di milliwatt a volte ma su tante unità fanno la differenza. Io ho lavorato sui sistemi per VDSL e G.fast. Soprattutto questi ultimi a volte sono reverse powered = prendono energia dalla linea telefonica dell'utente. Li anche 100mW fanno la differenza perché il sistema deve poter accendersi anche con un solo utente collegato. Un utente fornisce mediamente 7~8W. Non è che per fare felice il programmatore di turno felice e contento puoi tirarne 50W.
Se vuoi farti un'idea poco precisa ma realistica di come vanno le cose, ti consiglio di giocare a Shenzhen I/O! (che è un gioco fichissimo tra l'altro )
Quello di cui parli è un tipo di device con cui grazie al cielo non ho mai avuto il "privilegio" di giocare (chissà quanti bestemmie se no) non c'è nemmeno un OS in quei cosi giusto? Manco uno "guasto" come Linux?
Quindi si va di assembler o almeno il C si riesce ad usare?

Io per Cosmos a parte quello che faccio per il mio lavoro penso ai router ADSL / Fibra Ottica quelli hanno CPU ARM o MIPS "decenti" e Linux a bordo e dove gira Linux può girare anche Cosmos

Alla fine tornando IT nelle aziende linguaggi moderni come Haskell o F# è difficile che te li facciano usare, i capi di solito sono over 50 quindi C++ è già qualcosa di "esotico"
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 28-10-2017, 10:31   #36
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da fano Guarda i messaggi
Guarda nel mio caso si tratta comunque di un normale X86, con ATOM a 1.91 GHz dual core certo non è tutta sta "fichezza",
In ambito embedded, la tua piattaforma è l'equivalente di un'auto da Formula 1.
Quote:
ma doversi ridurre a scrivere milioni di righe in C invece che in un linguaggio sensato tipo C# o Java non mica senso per me... è questione anche di mentalità temo i miei colleghi continuano a credere che C# sia interpretato e sghignazzano nella loro ignoranza
... nel caso di Cosmos poi sparirebbe anche un altro punto di "incertezza" il JIT essendo tutto compilato AOT certo se poi ci si mena la fava con il GC beh allora siamo fritti!
Più veloce, ma con memory leak? Boh...
Come sempre, dipende dal contesto. E' chiaro che se hai un software complicato, con milioni di righe di codice, magari il C non è la scelta migliore. Un buon compromesso potrebbe essere rappresentato dal C++, usando estensivamente smart pointer & co., se le prestazioni rimangono molto importanti.
Quote:
Anche la parte più real time che non facciamo noi sempre schede ARM (prima erano Motorola quindi tipo "Amiga") che credo almeno 256 MB di RAM ce le abbiamo alla fine non credo che C sia davvero necessario lo è nella loro "mente"!
30 anni fa sarebbe stato scritto in Fortan e il "giovane ribelle" sarebbe stato quello che voleva scriverlo in C
30 anni fa avresti avuto 256KB di memoria, o poco più.

In ambito embedded 256MB, di sola RAM, sono una quantità spropositata, credimi.
Quote:
Sì alcune parti di quel codice sono anche più vecchie di 15 anni ho colleghi più giovani di quel codice pensa un po'
Comunque come faccio a fare un unit test visto che ho bisogno di periferiche esterne che si "sollecitano"? Dovrei simulare anche loro?
Spesso è richiesta anche un interazione umana...
In teoria tutto si potrebbe "mockare". Nella realtà bisogna vedere il codice com'è scritto, e quindi se, pur usando il C, siano state definite in maniera decente le interfacce per l'interazione coi vari "componenti".

Da questo punto di vista riuscire a creare mock per creare test potrebbe essere un'ottima occasione per dare una sistemata al codice, in modo da renderlo meglio ingegnerizzato.

Se invece è roba "spaghetti-code", come purtroppo prevedo da quello che hai scritto finora, allora leggi sotto.
Quote:
Con le nuove versioni ri-scritti di sana pianta abbiamo iniziato a "simulare" la pressione dei tasti con xdotools, ma lo usiamo più per vedere se il C sta sbordando sul mio codice o se ci sonoo memory leak praticamente gli dici fai 10'000 transazioni e lo si lascia a soffrire tutto l'week end e poi vediamo se è sopravvissuto, ma non ho idea di come verificare che le 10'000 transazioni sono tutte giuste se non si è bloccato è OK per me
Se il software è dotato d'interfaccia grafica, e gira su un s.o. abbastanza conosciuto (Windows, Linux, MacOS X, Android), ci sono dei framework / librerie per simulare non solo la pressione di tasti e movimenti del mouse, ma anche per interagire coi widget della UI.

L'ultimo anno alla Intel l'ho passato a scrivere o riscrivere centinaia di test per testare i nostri prodotti, usando fMBT (al quale ho contribuito pesantemente per Windows, e in parte per Linux). Con questo accedere ai widget e manipolarli è un gioco da ragazzi (e su Windows è ultra veloce).

Quindi se il software di cui parlavi è così complicato che non riuscite (o non volete!) neppure a scrivere unit test, potreste scrivervi una test suite per casi d'uso che simulino abbastanza fedelmente il comportamento dell'utente.
Quote:
Originariamente inviato da ingframin Guarda i messaggi
Confermo al 100%! Ho dovuto litigare anche per 10 centesimi in più a volte.
Inoltre il costo dello sviluppatore è una tantum, è un costo fisso, mentre i costi di produzione sono variabili. I costi fissi si dividono su tutta la produzione, quelli variabili aumentano. Quindi meglio spendere un po' di più in sviluppo (= pochissimo quando si va di produzione in volumi) che un poco di più su ogni unità prodotta.

È anche una questione di consumi comunque. SoC e processori più piccoli e con meno ram consumano molto meno di processori più sofisticati. Anche li si parla di milliwatt a volte ma su tante unità fanno la differenza. Io ho lavorato sui sistemi per VDSL e G.fast. Soprattutto questi ultimi a volte sono reverse powered = prendono energia dalla linea telefonica dell'utente. Li anche 100mW fanno la differenza perché il sistema deve poter accendersi anche con un solo utente collegato. Un utente fornisce mediamente 7~8W. Non è che per fare felice il programmatore di turno felice e contento puoi tirarne 50W.
Non ho voluto tirare in ballo anche i consumi per non appesantire troppo la discussione (che "purtroppo" deraglia, quando diventa interessante ), ma concordo assolutamente con tutto quello che hai detto.

Anche in ambito automotive tenere a bada i consumi è molto importante. Non è che, perché c'è una grossa batteria, ci si può permettere il lusso di consumare quanto vogliamo. Anche quando la macchina viene spenta, per questioni di ripartenza "istantanea", la circuiteria potrebbe trovarsi in modalità sospensione, e dunque consumare continuamente corrente.
Quote:
Se vuoi farti un'idea poco precisa ma realistica di come vanno le cose, ti consiglio di giocare a Shenzhen I/O! (che è un gioco fichissimo tra l'altro )
Ho visto il video, e il gioco è molto bello. Però non fa per me: troppe cose da fare e poco tempo a disposizione, per cui se devo smanettare con assembly et similia allora è meglio che rimetto mano ad alcuni progetti che ho in sospeso (emulatore 8086 scritto in Python. E finito questo ho un altro progettino che mi circola in mente da anni, riguardo a 68K & Amiga, ma non è il classico emulatore ).

Lo faccio vedere alla prole: magari gli viene voglia di imparare a smanettare con queste cose.
Quote:
Crepi il lupo!
Ci sono i Bell Labs qui ad Anversa, non è necessario andare in USA
(Sempre ammesso che mi prendano, non è mica così facile entrarci )
Ah, non sapevo. Sarebbe ottimo.

Pur essendo americano, preferisco rimanere in ambito europeo, e vicino all'Italia. La vita negli USA non mi è mai interessata né attratto (tutt'altro), eccetto in gioventù, dove è facile farsi prendere dal mito.
Quote:
Originariamente inviato da fano Guarda i messaggi
Quello di cui parli è un tipo di device con cui grazie al cielo non ho mai avuto il "privilegio" di giocare (chissà quanti bestemmie se no) non c'è nemmeno un OS in quei cosi giusto? Manco uno "guasto" come Linux?
Quindi si va di assembler o almeno il C si riesce ad usare?
La differenza fra usare C o assembly la fanno sostanzialmente le risorse a disposizione. Se hai una manciata di Flash e uno sputo di RAM, direi che non hai alternative all'assembly. Se hai già 1-2KB di RAM e 8KB di Flash, potresti già prendere in considerazione il C.

Ovviamente al netto delle specifiche del progetto. Se hai troppo roba da implementare, o delle sezioni troppo "time critical", il C potrebbe non essere sufficiente.

Non è possibile, insomma, dare una risposta certa sull'argomento, senza scendere nei requisiti.
Quote:
Io per Cosmos a parte quello che faccio per il mio lavoro penso ai router ADSL / Fibra Ottica quelli hanno CPU ARM o MIPS "decenti" e Linux a bordo e dove gira Linux può girare anche Cosmos
Ma potrebbe girare anche un s.o. in versione "metal", come BareMetal OS.

In tutta onestà, per certe cose vorrei avere le mani quasi completamente libere (ancora di più che con BareMetal OS). E' per questo che da tempo mi frulla in mente la realizzazione di un s.o. ridotto all'osso e che consenta di avere pieno accesso nonché controllo di tutte le risorse hardware.
MetalOS sarebbe una manna per far funzionare molti emulatori, ad esempio, che al momento sono pesantemente castrati dagli innumerevoli layer fra codice dell'emulatore e hardware.
Quote:
Alla fine tornando IT nelle aziende linguaggi moderni come Haskell o F# è difficile che te li facciano usare, i capi di solito sono over 50 quindi C++ è già qualcosa di "esotico"
L'unica è portare un proof-of-concept che mostri concretamente qualche vantaggio.

Con F# dovrebbe essere molto più facile, perché alla fine è basato su .NET, per cui ciò che produci in F# può essere "consumato" da C++/CLR, C#, IronPython, ecc., e viceversa.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 31-10-2017, 13:52   #37
ingframin
Senior Member
 
L'Avatar di ingframin
 
Iscritto dal: Apr 2010
Città: Leuven
Messaggi: 667
Quote:
Originariamente inviato da fano Guarda i messaggi
Quello di cui parli è un tipo di device con cui grazie al cielo non ho mai avuto il "privilegio" di giocare (chissà quanti bestemmie se no) non c'è nemmeno un OS in quei cosi giusto? Manco uno "guasto" come Linux?
Quindi si va di assembler o almeno il C si riesce ad usare?

Io per Cosmos a parte quello che faccio per il mio lavoro penso ai router ADSL / Fibra Ottica quelli hanno CPU ARM o MIPS "decenti" e Linux a bordo e dove gira Linux può girare anche Cosmos

Alla fine tornando IT nelle aziende linguaggi moderni come Haskell o F# è difficile che te li facciano usare, i capi di solito sono over 50 quindi C++ è già qualcosa di "esotico"
I sistemi per tlc tipicamente hanno un Linux custom a bordo e si programmano in C++ e hanno un interprete python per script di test e configurazione.
Purtroppo non posso scrivere i dettagli su internet, ma sarebbe interessante far vedere (soprattutto agli studenti) come è fatto un sistema reale.
__________________
L'elettronica digitale non esiste, è solo elettrotecnica con interruttori piccoli!
ingframin è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
Recensione HONOR Pad 9: ampio display e audio top per il tablet per l'intrattenimento Recensione HONOR Pad 9: ampio display e audio to...
Lamborghini, nuovo logo e font, ora abbr...
Xbox Series X si veste di bianco, ma &eg...
La Porsche Boxster elettrica beccata in ...
L'iPad da 10,9" (Wi-Fi, 64GB) è sceso a ...
Dell, calo del mercato PC: licenziati 13...
Alfa Romeo Milano, scopriamo profilo e l...
Hisense vende un TV FHD 32 pollici con Q...
Cisco Webex anche in auto: ora è ...
Phil Schiller, il boss dell'App Store di...
Lola in Formula E insieme a Yamaha, due ...
Motorola MA1 è l'accessorio ideale per u...
Tineco e aspirapolveri senza fili, la nu...
Blocco note, c'è un modo per ripr...
Relic Entertainment dice addio a SEGA: l...
SPATIUM M580 FROZR, il nuovo SSD PCIe Ge...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 13:11.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www3v