Premessa: ho seguito da molto tempo il “discourse INT”, in cui ho potuto soffermarmi su alcuni esempi di modellazione afflitti, come spesso accade, da qualche bug (bug segnalati da utenti e prontamente inseriti nella lista di risoluzione RH…).
Ogni tanto osservo anche il “bug track” di Rhino e noto, con mio stupore, che molti bug importanti (per esempio, di shell, fillet, booleane, ecc.) evidenziati durante lo sviluppo di Rhino 6 (nelle prime fasi WIP e successive Beta) sono stati, per così dire, ‘spostati’, nella lista di bug da risolvere in un tempo futuro (Rhino 7), se non sbaglio (e non parlo di wish, o di comandi nuovi e features varie).
Domando: “E’ normale che un bug noto, cioè messo in evidenza nei tempi di sviluppo di Rhino 6, debba essere risolto successivamente, in Rhino 7?”.
In tal modo, vedremo il funzionamento corretto di alcuni comandi soltanto fra molti anni (senza motivo di critica, conosciamo tutti i tempi biblici di sviluppo); frattanto, nella neo-nata versione di Rhino, gli utenti si beccheranno gli stessi e i soliti ‘difettucci’ (se non altro, quelli noti, già segnalati da tempo),
(a meno che non si utilizzi la versione WIP di Rhino 7, destinata, come giusto che sia, a pochi “eletti”).
Scelte di sviluppo, insindacabili, per carità, però…
Direi … dipende.
Intanto dal tipo di bug … nel senso che, secondo me, puo’ capitare che sia riconosciuto come bug un comportamento di Rhino che potrebbe dipendere da un algoritmo, da un’impostazione data a una certa feature … magari da qualche operazione geometrica nel kernel di Rhino. ( Sparo a casaccio, eh … )
Per cui se rimediare a quel bug significa riscrivere un bel po’ di roba, o magari una parte ‘critica’, usata da diversi comandi … temo si debba decidere quando e come affrontare il problema.
Rischio di fare un ‘patch’ veloce, che magari mi incasina Rhino da un’altra parte, oppure aspetto di avere abbastanza tempo per riorganizzare quella parte di codice come si deve ?
Credo che si debbano considerare i vari bug individualmente …
Poi non so come funzioni il bug-tracker … magari qualcuno segnala un bug, ma altri non lo considerano un bug … chi lo sa … … non ho idea su chi ‘battezzi’ ufficialmente i bug …
Poi … non so … magari la cosa capita anche ad software, solo che non lo sa nessuno …
Con Rhino invece, il problema e’ di dominio pubblico …
Quello che dici è ragionevole, ma…
Circa due anni fa misi in evidenza un bug riscontrato in una operazione di “shell”; a farla breve, il comando ad una certa tolleranza restituiva superfici con un piccolo bordo aperto; quasi certamente il problema risiede nell’intersector, ecc. ecc., mi disse allora Pascal. In ogni caso tale bug venne inserito prontamente nella lista.
Saranno passati, non so, due anni e mezzo, forse tre… e ho potuto notare come tale esempio sia diventato un bug da risolvere in Rhino 7. Complessità o meno, non si rischia che taluni bug, andati un po’ nel dimenticatoio per favorire la risoluzione di problemi, forse, di minore entità o di altro genere, vengano risolti magari in versioni molto lontane? azzardo un pochetto… (le aspettative per ogni nuova versione sono tante, e gli utenti si aspettano che certe operazioni, finalmente, funzionino tutte, o quasi; non è poca roba aver scoperto che un certo fillet in Rhino 5 impallava le superfici e in Rhino 6 funziona bene come dovrebbe; pensa se lo stesso venisse risolto lontanamente, che so, in Rhino 7 o in Rhino 8: una tragedia!).
Credo che la scaletta sia dettata da quanti utenti riscontrano lo stesso bug…
Se solo 1% degli utenti trova un problema e, per risolverlo, serve fare delle modifiche gravose o, peggio, trovare un sistema che funzioni in tutti i casi senza rischiare di far peggio (noi diciamo “pedo il tacon del sbregh” che vuol dire “peggio la toppa rispetto allo strappo”), allora viene rinviato a momenti più “consoni”.
Come consigliato da Vittorio, posta il problema così da capire di cosa si parla e, nel caso sia effettivamente una mancanza di McNeel non averci dato il giusto peso, glielo si fa notare…
A volte serve un pò di pressing per tenere alta l’attenzione.
Purtroppo non ho più i file, dovrei recuperarli nel discourse int, appena posso li cerco e li posto qua.
Comprendo tutta la faccenda, parecchio complessa nell’organizzazione e gestione di ogni aspetto legato, appunto, ai cosiddetti bug, innumerevoli e presenti in ogni dove.
Nella mia ingenuità credevo che, una volta appurato il bug (se di bug si tratti), questo venisse risolto nella versione corrente e non rimandato a data futura (tra diversi anni per intenderci).
Era solo una mia curiosità, nulla di grave, considerando il fatto che quantomeno McNell lo fa presente (l’eventuale difetto), mentre altre software house lo nascondono, giusto come dite voi, dando l’idea che da versione in versione (ne sfornano una ogni anno) abbiano sistemato tutto, e invece… (bravi mistificatori).
Per me e’ un problema … lessicale (se si dice cosi’ …)
Anche a me risulta che i bug (anticamente, per cpsi’ dire … ) fossero delle semplici sviste, o cose del genere, per esempio sbagli a scivere il nome di una variabile, o dimentichi un’istruzione ecc.
Ora invece vengono chiamate bug carenze di ogni tipo … secondo la valutazione di chiunque …
A questo punto risolvere un bug puo’ diventare un’impresa … che rasenta l’impossibile
… Si dovrebbero usare altri termini …cosi’ non si capisce piu’ niente …
Ho trovato questo, per esempio, un banale bug segnalato da diverso tempo e purtroppo ancora non risolto (guardando il bug tracking).
Comando “OrientOnCrv”, opzione “su curva”… lo snap ‘int’ non funziona (pur essendo attivato), così mi ricordo… (pertanto, se si vuole spostare in maniera precisa il pentagono lungo la curva rossa risulta un pochetto difficoltoso trovare l’esatta intersezione). Spero abbiate capito (per spiegare ‘sta faccenda nel discourse INT ho dovuto scrivere e tradurre fiumi di parole, un poema! Alla fine hanno compreso e segnalato il bug… che soddisfazioni!).
Provate a pensare se codesta “banalità”, niente di trascendentale, venisse tralasciata per svariati motivi e risolta in Rhino 8, fra 10 anni. Voi utenti che avete acquistato la licenza di Rhino 6 non vi incazzereste un po’? (problema segnalato un anno prima che uscisse Rhino 6).
Qualcosa non torna allora: come sia possibile che in v5 funzioni e in v6 non più?
Hai usato il comando “OrientOnCrv”? e poi cliccato su “su curva”, ti dice di scegliere un punto base, ecc.
Il comando esatto è “Orienta perpendicolare a curva”, in italiano, il problema occorre quando si seleziona l’opzione tra parentesi “su curva”: gli snap non funzionano (né ‘int’, né ‘cen’ in particolare).
Chi lo segnala. E generalmente deve testare le correzioni dopo. C’è un release di destinazione che decide il programmatore che ci lavora. I bug hanno diversi gradi di criticità. Quelli che fanno danni o crash sono considerati i più pericolosi. Possiamo non risolvere ma nessuno fa finta di non vedere.
Ecco, basta poco e fuoriesce la tua asprezza: io starei rompendo!
Potrai avere anche mille titoli, diplomi, lauree, master, onorificenze, ma se non possiedi cortesia e delicatezza nei modi, difficilmente le tue qualità potranno emergere o essere apprezzate dai molti. Chiamasi “savoir-faire”, non so se conosci questa parola (permettimi questo francesismo).
Il fatto che tu sia “il mega-ingegnere-esperto di-inventore del RhinoDay” non ti dà il diritto di sparare a zero o utilizzare modi alquanto cafoni che non si addicono ad un uomo istruito e di riconosciuto valore.
Questo è il possibile bug segnalato e discusso con Pascal e Brian James - https://mcneel.myjetbrains.com/youtrack/issue/RH-39731.
Confermo che anche qui sulla V5 non noto alcun comportamento strano… gli Osnap funzionano (Int compreso).
Non riesco a replicarlo…
Se ho capito bene dicono che manca una pausa per permettere alla macro presente nel menù di poter funzionare con l’opzione oncurve… appena mi arriverà la V6 proverò a vedere se riesco a replicare… ma mi pare tanto uno di quei casi che bisogna mettersi di impegno per riuscire a replicarlo…
Il fatto di dire che rimanderanno alla V7 l’eventuale soluzione è perchè devono riscrivere il comportamento di tutti i comandi per evitare di dover utilizzare le pause… mi pare più che comprensivo…
Se ho capito bene, basta l’opinione di una sola persona per registrare un bug, anche se altri potrebbero non considerarlo tale.
E’ una procedura molto garantista nei confronti degli utilizzatori, complimenti !
Emilio, non vorrei apparire pedante, però ogniqualvolta posto qualcosa, riscontro quasi sempre un modo di fare “prevenuto”… non è carino dire “stai solo rompendo”, oppure “meglio che esci da qua”, e altre battutacce di cattivo gusto. Essere definiti un “disturbatore” è davvero squallido, credimi; ma capisco che non si dirà mai qualcosa a mio favore, perché non possiedo alcun titolo (in Italia purtroppo funziona così, solo qua).
Se rileggi tra le righe non ho offeso nessuno, o detto chissà quali cose. Credo di essere educato, di dialogare in modo “normale”, ma se bisogna stare attenti anche alle ‘virgole’ che si dicono, allora siamo messi proprio male! (verrò fustigato se non sarò il guru della modellazione nurbs? se a volte divago un po’? se muovo qualche critica? se dico la mia a modo mio?).
Questo è un forum di discussioni libero, aperto, o c’è sottesa la volontà di dialogo soltanto tra gli “amici della cricca”? Vorrei capire come funziona, altrimenti mettiamo un pass, una sorta di bollino verde che certifichi e attesti l’appartenenza ad un “certo” sistema, o meglio ancora, un blocco (come in whatsapp).
… non ho idea su chi ‘battezzi’ ufficialmente i bug … 
