Ciao Emi…ebbene si…confesso nemmeno a me funziona oggi… devo guardare meglio ma non sarà possibile prima di venerdi…
Maledetti script…lo dicevo che non volevo mettermici… peggio di una droga…ahahahahaha 
Non ti preoccupare Giuspa. Non c’e’ fretta.
Con gli script ci vuole calma e metodo … e’ una partita a scacchi … 
Approfitto per iniziare a confondere le idee al buon Federico … 
( Oppure per addormentarlo … )
Scusa se parto terra terra … mi trovo male a fare diversamente…
C’era una volta Rhino 2 e in McNeel ebbero la fantastica idea di dotarlo di script, in modo che la gente la smettesse con tutti quegli stupidi wish e si scrivesse gli script senza rompere …
Risultato: la gente ha iniziato a sparare wish anche per gli script … 
Non divaghiamo …
Si usava il VBScript come linguaggio e per poter comunicare con Rhino si usava “l’oggetto Rhino”.
‘Oggetto’ nel gergo dei programmatori. E’ un modo per dire che nello script tu scrivevi piu’ o meno:
vertice = Rhino.AddPoint( Array( 0, 0, 100 ) )
e lo script disegnava un punto 100 mm sopra l’origine e salvava il suo identificatore, detto anche ObjectID, nella variabile “vertice”
Federico, hai un’infarinatura di programmazione ad oggetti (detta anche OOP) ?
Potrebbe essere utile, come vedi abbiamo gia’ trovato un oggetto … 
… se no non importa, ci arriviamo ugualmente.
Comunque si usavano i “metodi” RhinoScript, ad esempio qui abbiamo usato
AddPoint()
RhinoScript e’ il nome che fu dato a questo software (cioe’ Rhino.AddPoint() eccetera …) che ci permetteva di ammattire felicemente su uno script per ore e ore … rendendoci estremamente felici (noi scriptomani siamo gente strana …)
In pratica si usava questa “Libreria di funzioni”, detta appunto RhinoScript.
La libreria RhinoScript permetteva di fare parecchie cose (non subito su Rhino 2… ma col tempo si’)
Si potevano disegnare oggetti, trasformarli, operare sugli attributi degli oggetti e c’erano anche diversi metodi per permettere l’input all’utilizzatore.
Gli oggetti Rhino, quelli che vediamo sullo schermo, erano individuati tramite gli identificatori, come gia’ accennato, alias ObjectID alias Guid … sono valori definiti da Windows, che RhinoScript usa per distinguere un oggetto dall’altro.
Questi benedetti Guid (permettimi di chiamarli cosi’ d’ora in poi) fanno riferimento agli oggetti registrati nel data base di Rhino: un Guid <–> un oggetto
Naturalmente Rhino salva da qualche parte tutto cio’ che noi disegniamo, e per questo usa un data base che chiama
RhinoDoc
E’ il nome di un oggetto (rieccoli …) … Veramente (e qui lo so che inizio a incasinare tutto … mannaggia) e’ il nome della “Classe” degli oggetti in questione.
Vuol solo dire che possono esistere piu’ oggettti di tipo RhinoDoc.
Ognuno e’ un data base di oggetti geometrici. Ad esempio se apriamo piu’ sessioni di Rhino. ognuno avra’ il suo bell’oggetto RhinoDoc che contiene tutte le belle cose: curve, solidi ecc che vediamo sullo schermo.
Una classe e’ semplicemente un tipo di dati: come i numeri interi, i numeri decimali, i testi, le immagini ecc.
(Classe e’ sinonimo di Tipo)
Come possiamo definire molti numeri che appartengono al ‘tipo’ ‘Interi’
Cosi’ possiamo definire piu’ oggetti di tipo RhinoDoc.
Torniamo a RhinoScript: lui quando costruisce, ad esempio, una curva, ti restituisce un Guid.
Usando quel Guid (e niente altro !) tu puoi far riferimento a quella curva nello script.
Abbiamo detto che possono esistere piu’ oggetti RhinoDoc, ma questo non ci deve confondere, perche’ Rhino (cioe’ una sessione di Rhino) normalmente usa un solo oggetto RhinoDoc, cioe’ un solo data base di oggetti.
Ed e’ lo stesso usato da RhinoScript. Infatti non c’e’ differenza tra gli oggetti che disegniamo tramite un comando o tramite uno script … sono tutti fratelli li vediamo tutti insieme sullo schermo senza poterli distinguere.
Queto e’ un punto importante, perche’ significa che RhinoScript non e’ separato da Rhino, ma si appoggia al suo data base di oggetti.
Per cui non avrebbe senso uno script ( in RhinoScript ) senza una sessione Rhino.
Quello che volevo comunicare e’ questo:
Uno script RhinoScript usa solo gli oggetti geometrici del data base di Rhino (il suo RhinoDoc).
… Che NON sono quelli definiti dai componenti di Grasshopper, a meno che tu li cuocia e allora vengono copiati nel data base di Rhino (cioe’ nel suo RhinoDoc).
Poi, altra brillante idea di McNeel, secondo me anche meglio della prima, hanno introdotto IronPython, cioe’ un ambiente alternativo per gli script. E la cosa ha iniziato a svilupparsi parecchio.
Tra l’altro, in McNeel hanno scritto una librerie di funzioni per IronPython che cerca di imitare fedelmente la vecchia libreria RhinoScript.
E la hanno chiamata “rhinoscriptsyntax” in quanto, naturalmente, replica per quanto possibile la sintassi di RhinoScript.
E qui inizia l’inghippo … hehehehe …
Ma se sara’ il caso, proseguiro’ la prossima volta.
Se non si capisce niente invece, fatemelo gentilmente sapere, please, cosi’ evito di intasare ulteriormente il forum senza motivo … grazie
Mi scusa per gli errori e saro’ grato a chi li correggera’
Ciao, buonanotte !
Si è capito benissimo.
Non so dirti quanto “infarinato” sia come programmazione ad oggetti, quindi facciamo finta di partire da 0.
Comunque comicio a capire cose che prima avevo in parte intuito, diciamo che la nebbia comincia a diradarsi…
Ora sono curioso sul proseguo
1 Mi Piace
Cioe’ se parliamo di classi e oggetti, sai cosa sono e come si usano ?
In generale, ovviamente, tanto ogni linguaggio li declina a suo modo …
Oppure ne hai solo sentito parlare ?
grazie
P.S.
Hmmm … pero’ se hai capito quanto detto sopra, direi che siamo a posto.
A noi non serve altro, e comunque non saprei dirti molto di piu’ … 
OK, alla prossima.
Diciamo che a volte faccio confusione perchè non conosco la definizione esatta di classe e oggetti.
A scuola non ne ho mai sentito parlare ed è solo da un annetto che stò un po entrando in questo mondo.
Ne ho sentito parlare solo su qualche tutorial che mi sono letto in rete ma nulla più.
Su cosa sono le classi e oggetti faccio affidamento a quello che mi hai spiegato e che mi stò studiando.
Grazie mille
Ciao Federico.
Scusa, sono curioso …
A scuola cosa hai studiato di programmazione ?
Se te lo dico ti metti a ridere… Ho studiato da elettrotecnico e ora faccio il disegnatore e programmatore CNC per una falegnameria. A scuola ho fatto un po’ di turbo pascal. Quando mi sono diplomato sapevo cos’era un ciclo for, while, la condizione if-else e qualche tipo di dato e nulla più.
Beh, veramente no …
Personalmente trovo l’attuale organizzazione di scuola e lavoro abbastanza assurda.
Prima devi studiare come un matto senza nemmeno provare a fare qualcosa di concreto.
Poi devi smettere di studiare di colpo (almeno per la maggior parte e’ cosi’) e iniziare a lavorare a testa bassa.
Le aziende pretendono di trovare gente che conosce gia’ il lavoro … possibilmente per via genetica.
Secondo me la scuola ti da’ alcune nozioni di base e ti insegna a imparare. Parlo della scuola per i ragazzi.
Perche’ non dovrebbe finire mai, in un modo o nell’altro, e per le aziende dovrebbe essere normale insegnare il lavoro a chi inizia.
Forse parlo cosi’ anche per esperienza personale.
Io ho studiato meccanica e ho imparato a fare il modellatore ‘a bottega’ da mio padre.
Il laboratorio di mio padre era una vera scuola. Lui prendeva gli apprendisti e insegnava loro tutto quanto con grande pazienza e impegno. Molti dopo si sono a loro volta messi in proprio.
(Poi abbiamo dovuto chiudere e adesso faccio il disegnatore da dipendente … non ci sono taglaito …lasciamo perdere)
Credo comunque che almeno alcune cose studiate a scuola ti servano nel tuo lavoro, e spero che il lavoro ti piaccia.
In fondo il Pascal e il linguaggio del controllo numerico concettualmente sono la stessa cosa.
E anche gli script per GH.
In pratica ho fatto un lavoro simile al tuo per diversi anni. Modellatori anziche’ falegnami, pero’ usavo il CAD/CAM per preparare i percorsi utensili per fresare i pezzi.
E Rhino era molto comodo. Alcuni percorsi semplici che capitavano spesso li facevamo direttamente su Rhino. Eeeeeh, bei tempi …va beh, lasciamo perdere la nostalgia.
Comunque una cosa penso proprio di invidiartela … il buon odore del legno !
Ecco:
Un thread così mi mancava da tempo. Stile vecchio NG.
E’ del tutto evidente che quando partecipano le persone che hanno voglia di fare, la piattaforma usata (Discourse / NG) conta meno.
1 Mi Piace
Dunque, torniamo al nostro caro problema con rhinoscriptsyntax su GH.
Tieni conto che per me e’ un terreno anche piu’ scivoloso del solito, data la mia poca dimestichezza con la cavalletta, comunque … proviamo
Questa e’ l’immagine postata da Giuseppe, e … in pratica dice tutto … 
Ragioniamo un momento.
Abbiamo gia’ visto che rhinoscriptsyntax puo’ operare solo su oggetti contenuti in un data base RhinoDoc (diciamo in un oggetto RhinoDoc, tanto per non perdere di vista l’OOP 
)
Quando usiamo rhinoscriptsyntax in Rhino (non in GH) questo non da’ problemi. Rhino possiede il suo bell’oggetto RhinoDoc e tutto funziona.
Se pero’ vogliamo usare rhinoscriptsyntax in Grasshopper, sorge un problemino: GH non possiede un data base RhinoDoc, lui gli oggetti geometrici li registra altrimenti.
E allora il povero rhinoscriptsyntax come fa ? Gli manca la materia prima …
Per ovviare a cio’, quando IronPython e’ stato attivato anche per GH, in McNeel hanno aggiunto a GH un oggetto RhinoDoc, che ai normali componenti di GH non serve.
Serve pero’ al componente Python, quando usa le fuzioni rhinoscriptsyntax.
Questo data base di oggetti ausiliario in GH e’ stato chiamato ghdoc.
E permette alle funzioni rhinoscriptsyntax di funzionare.
Ad esempio possiamo usare rs.AddLine() e definire una nuova linea.
La linea sara’ salvata in ghdoc e la funzione che la costruisce ci restituisce il suo bel Guid, anch’egli salvato in ghdoc.
( E’ RhinoDoc che ‘appiccica’ il Guid all’oggetto. Senza RhinoDoc, niente Guid …)
Cosicche’ se dopo vogliamo ad esempio spostare la linea, possiamo usare rs.MoveObject(), passandogli il Guid ottenuto prima.
Quindi se noi apriamo un componente Python in Gh e iniziamo ad usare rhinoscriptsyntax, lui usera’ come data base per gli oggetti ghdoc, questo significa che non sara’ capace di raggiungere gli oggetti nel data base di Rhino, ma solo quelli che lui stesso (rhinoscriptsyntax) ha costruito e registrato in ghdoc.
E questo nel nostro caso (punto di inserimento del blocco) e’ un problema, perche’ il blocco lo troviamo solo nel RhinoDoc di Rhino.
(Voi mi avete insegnato che GH non lo importa direttamente)
Ma … in McNeel ne inventano una piu’ del diavolo …
… E hanno pensato di porre rimedio a questa situazione incresciosa …
Facendo in modo che il data base RhinoDoc usato da rhinoscriptsyntax in GH non sia una costante, ma sia settabile dall’utilizzatore.
L’oggetto ghdoc viene si’ usato da rhinoscriptsyntax in GH, ma solo di default, non necessariamente.
Questo e’ il punto essenziale: e’ possibile fare in modo che rhinoscriptsyntax in GH usi un data base diverso da ghdoc.
Come ci dice l’immagine sopra, per settare l’oggetto RhinoDoc usato da rhinoscriptsyntax in GH si usa la variabile scriptcontext.doc.
Cioe’ quando nel componente Python c’e’ una funzione rhinoscriptsyntax, questa per sapere quale oggetto RhinoDoc deve usare, guarda cosa c’e’ scritto nella variabile scriptcontext.doc.
Come abbiamo detto, di default, scriptcontext.doc punta a ghdoc.
Ma puo’ benissimo puntare al RhinoDoc di Rhino, basta settarla convenientemente.
Ed e’ proprio quello che ci dice il messaggio nell’immagine.
Se noi (come per il caso del blocco) abbiamo bisogno che rhinoscriptsyntax usi il data base di Rhino, basta settare scriptontext.doc.
Seguendo queste istruzioni, e’ possibile ottenere dal blocco il punto che ci serve:
qui il parametro di input del componente Python l’ho chiamato guid
OK, spero di non essermi avvitato eccessivemente con il ragionamento … sempre ammesso che sia giusto …
Mi fermo qui … mi sono confuso le idee da solo a sufficienza …
Eventualmente un’altra volta parliamo di RhinoCommon.
… Anche se … in piccola parte in realta’ ci abbiamo gia’ ficcato il naso … hehehehe
Si’, beh. Resta comunque impossibile tener sott’occhio il thread come si poteva fare sul NG.
Forse il forum IT e’ considerato adatto ai discorsi senza fretta. Piu’ per i ragionamenti e le speculazioni che per l’assistenza immediata (come e’ di moda oggi).
In effetti noto che diversi utilizzatori italiani preferiscono chiedere direttamente sul forum USA, spesso facendo sfoggio di quello che a un ignorane come me sembrerebbe un inglese piuttosto maccheronico, mentre qui capirsi sarebbe molto piu’ semplice.
Condivido appieno la tua opinione.
Infatti ora che mi piacerebbe dedicare più tempo ad approffondire questi discorsi sulla programmazione non riesco perchè devo sfornare disegni a manetta e a casa i miei bimbi non mi vogliono dividere con nessun altro impegno (a ragione, mi vedono già poco). Spero di avere più tempo sotto le feste…
Per quanto riguarda l’odore del legno qui non se ne sente un gran che, anzi, ormai per le varie certificazioni usiamo quasi esclusivamente mdf ignifugo che puzza quando lo lavori e “mangia” le frese molto velocemente 
E’ ovvio che tu dia la precedenza ai bimbi
Quanto al legno, vedo che la modernita’ non risparmia nemmeno i falegnami …
Anche per i modellatori il tempo del legno e’ ormai molto lontano. credo che si usi solo piu’ del compensato piu’ che altro a fini strutturali.
Una curiosita’ … per cosi’ dire. Si fanno ancora stampi per termoformatura in compensato incollato e fresato.
Soprattutto sopra certe dimensioni.
Le caratteristiche del legno in certi casi sono ancora ineguagliate.
Credo che siamo in molti ad essere ridotti a sperare nelle feste per riuscire a fare qualcosa … volontariamente
A presto.
A me invece me le hai schiarite alla grande!!!
Mi hai risparmiato qualche mal di testa .
Ho un una domanda che mi è sorta pensando su queste cose (quando comincio a volte sono pesante, lo riconosco). In Rhino si riesce a fare riferimento per certe operazioni a parti di oggetti tenendo premuti i tasti shift ctrl mentre si seleziona con il mouse. Questo ci consente di selezionare una superfice da un solido, ad esempio, senza estrarla. Ed ecco la mia domanda: si riesce a fare riferimento, in qualche modo, in grasshopper a una parte di un oggetto?
Ho provato ma già il componente guid di grasshopper mi da problemi.
Intanto ti ringrazio moltissimo.
Mah … non saprei proprio … spiacente.
Provero’ a indagare un po’ … 
… ma non so se ne ricavo qualcosa …
Forse qualche esperto di GH sa come fare …
Giuseppeeeee … hai qualche dritta ? 
EDIT:
Giuspa, ho trovato questo: Difference between python script and python in grasshopper - Grasshopper
Sembra che qualche modo ci sia, se ho capito …
Tu sai a cosa si riferisce Giulio ? Grazie.
Non garantisco le mie qualità di “interprete autentico di Giulio”… ma immagino si riferisca al fatto che GH non è ideale per la selezione dei sub-objects. Ci sono modi per farlo ma non viene… incoraggiato 
Nell’esempio che allego l’idea è che se parti da un parallelepipedo che assegni alla brep iniziale puoi decomporlo nelle srf costituenti e “passarlo” al documento Rhino via geometry cache. A quel punto in Rhino hai la brep e le componenti. Puoi ad esempio spostare una faccia… a questo punto la modifica passa nuovamente a GH con Cache In. e nel mio esempio trovi il centroide anche della faccia spostata.
… non mi viene in mente altro… 
sub-objects.gh (4.4 KB)
Grazie Giuspa !
… Federico avra’ capito le tue spiegazioni.
Io non so nemmeno cos’e’ la geometry cache …
Grazie Giuseppe!
Purtroppo questo sistema non si addice a quello che avevo in mente di fare, (anche se l’ho gia fatto ma cercavo un modo più intelligente per farlo).
Comunque ho imparato come funziona geometry cache che fin ora era, per me, un componente sconosciuto comparso nelle ultime versioni di cavalletta
Speriamo che in futuro si possa fare riferimento a parti di oggetto più o meno come si fa riferimento agli oggetti interi.
Grazie ancora.
Ciao.
tipo una casella postale… 
Ciao Federico,
torno alla carica con … le dispense per scriptare in GH.
Avevo detto che il prossimo passo sarebbe stato RhinoCommon ( sempre se tu sei d’accordo ).
In ogni caso questa sera ho fatto un po’ tardi, quindi non rompo piu’ di tanto … almeno spero …
Pensavo di dire due parole introduttive sui famosi oggetti ( OOP ), tanto per capire cosa fare di RhinoCommon.
Per fare in fretta ho provato a scrivere una semplicissima classe in Python, per toccare con mano.
class con:
# contatore #
def __init__( self, n ):
self.num = n
def aggiungi1( self ):
self.num += 1
def togli1( self ):
self.num -= 1
def scrivi( self ):
print 'Contatore = ' + str( self.num )
def setta( self, n ):
self.num = n
ct = con( 0 )
ct.scrivi()
ct.aggiungi1()
ct.aggiungi1()
ct.scrivi()
ct.togli1()
ct.scrivi()
ct.setta( 9 )
ct.scrivi()
Non l’ho provata con Rhino/IronPython (solo sul Python ‘classico’ ), ma dovrebbe funzionare lo stesso.
Se no avvisami per favore.
E’ una cosa abbastanza stupida: un semplice contatore:
Saro’ stringato, eventualmente chiedi delucidazioni su cio’ che non e’ chiaro.
inizia con la parola ‘class’
e tutte le istruzioni seguenti indentate riguardano la classe: in pratica definiscono i vari metodi.
Forse lo avevo gia’ detto … un ‘metodo’ e’ una funzione privata relativa a una classe.
Come vedi, ogni funzione ha un parametro (il primo) chiamato ‘self’ .In teoria puo’ avere un altro nome, ma ci complicheremmo solo la vita.
‘self’ si riferisce a un oggetto della nostra classe.
I metodi hanno questa peculiarita’: hanno necessariamente il loro oggetto di riferimento, per cosi’ dire.
Cioe’ non ha senso eseguire un metodo se non gli passiamo l’oggetto come parametro.
Questa particolarita’ si vede anche quando chiamiamo i metodi (vedi in fondo, dopo la classe)
Il primo parametro, cioe’ l’oggetto, viene scritto prima del nome del metodo, seguito da un punto.
E’ solo questione di sintassi. E’ come chiamare una fuzione generica, solo che il primo parametro lo scriviamo all’inizio invece che dopo la parentesi aperta.
E’ anche utile per distinguere a vista i metodi dalle normali funzioni.
Ma come costruiamo gli oggetti appartenenti alla classe ?
Usando il metodo
__init__()
Python usa questo metodo per costruire nuovi oggetti, solo che lo richiamiano con un altro nome (tanto per complicare le cose … ). invece di
__init__
usiamo il nome della classe.
Per cui l’istruzione
ct = con( 0 )
richiama il metodo
__init__()
della classe ‘con’ tramite il nome ‘con’ e costruisce un oggetto di tipo (o classe) ‘con’
la variabile ‘ct’ conterra’ quindi un contatore, cioe’ un oggetto 'con’
A questo oggetto (che appartiene alla classe ‘con’ ) possiamo applicare (altro modo di dire) i metodi della classe ‘con’ , come vedi nelle istruzioni seguenti.
C’e’ anche questa differenza: il metodo
__init__()
viene usato come una normale funzione, senza l’oggetto con il punto davanti.
Ed e’ logico, l’oggetto non esiste ancora, e’ il metodo stesso che lo costruisce.
Naturalmente i metodi di ‘con’ non possiamo richiamarli con oggetti di classi diverse.
Ogni oggetto puo’ ‘usare’ solo i metodi della sua classe.
Puoi vedere che nei vari metodi usiamo l’espressione ‘sefl.num’
si tratta di una variabile specifica della classe (dato che e’ scritta con il ‘self’ e il punto davanti)
Questo vuol dire che ogni oggetto appartenente alla classe ‘con’ avra’ la sua variabile ‘num’ personale, per cosi’ dire.
Nell’esempio abbiamo un solo oggetto, ma se provi a definirne altri, vedrai che le relative variabili ‘num’ sono indipendenti tra di loro.
Un oggetto e’ una ‘scatola’ che puo’ contenere diversi dati, qui abbiamo solo la variabile ‘num’ , ma possiamo definire tutte quelle che vogliamo.
Per ora mi fermo.
Se ti interessa e trovi il tempo, puoi provare a modificare l’esempio scritto sopra e a sperimentare.
Oppure a scrivere delle nuove classi e vedere come fuzionano …
Ciao !
p.s.
c’e’ ancora una cosa da dire sulle classi … eventualmente un’altra volta