Non so se sia stato già postato, ad ogni modo volevo condividere con tutti, i passi con i quali FidoCAD ha funzionato sul mio sistema Linux (Debian squeeze):
#1: Installare i pacchetti Wine e wget
(usando il gestore pacchetti della propria distribuzione, es: apt-get, aptitude, synaptic, yum ecc.)
#2: Scaricare lo script winetricks da:
formatting link
e salvarlo nella propria home directory
#3: Dalla propria home eseguire da shell:
~$ sh winetricks vcrun6sp6
#4: Scaricare il setup di FidoCAD:
formatting link
Quindi eseguirlo con Wine
#5: Fatto...se tutto è OK...nel menù Applicazioni/Programmi -> Wine del proprio desktop dovrebbe trovarsi l'icona di lancio di Fidocad
Ciao. A me su Ubuntu 8.04 ha funzionato semplicemente installandolo su Wine senza particolari script. In particolare, non essendo pratico di debian, anche se ubuntu è un suo derivato, ho una domanda: a cosa serve di preciso lo script wintricks che esegui? ciao
--
Paolo _-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_
"Non discutere mai con un idiota, prima ti porta al suo livello e poi
ti batte con l'esperienza"
Il Thu, 20 May 2010 08:48:55 +0200, Paolo Squaratti ha scritto:
A me su Ubuntu 10.04 LTS e su Debian Squeeze, se non installo quel pacchetto non si avvia.
Wintricks è una utility per ogni OS Linux (e credo anche per altri OS basati su UNIX) che ti consente di scaricare file di libreria Windows (DLL, OCX ecc.), font TTF, necessari per far funzionare applicazioni con Wine.
Se lo lanci senza alcun parametro:
~$ sh ./winetricks
Ti elenca tutti i possibili "pacchetti" che puoi scaricare, selezionandoli.
Nel mio caso, lanciandolo con l'argomento "vcrunsp6"
~$ sh ./winetricks vcrunsp6
chiedo di installare appunto il pacchetto "vcrunsp6", che contiene i file di run-time (Service Pack6) per i software compilati con MS VC++: mfc42.dll, msvcp60.dll, msvcrt.dll
Senza mvcrt.dll, FidoCAD (almeno nel mio caso) si avviava, però appena facevo il copia&incolla dal newsgroup, non mi appariva lo schema, ma una finestra tutta nera.
Il Wed, 19 May 2010 23:40:25 +0200, F. Bertolazzi ha scritto:
Non lo conoscevo, lo proverò subito.
Ad ogni modo, volevo sottolineare che non noto alcuna differenza, benché minima, fra come FidoCAD gira sotto Windows e sotto Linux (almeno a tutta prima).
Questa è una schermata sotto Wine:
formatting link
Ciò conferma, secondo me, la notevole bontà del software scritto da Lorenzo Lutti, al quale non basteranno mai i ns. ringraziamenti per averlo reso disponibile gratuitamente; ho saputo che lo usano (con estrema soddisfazione di docenti e allievi) anche in molte scuole tecniche.
In effetti, per quanto ne so io, l'unica cosa in cui FidoCad =E8 decisamente pi=F9 comodo di FidoCadJ =E8 per preparare una nuova libreria di simboli, difficolt=E0 peraltro aggirabile tenendo un editor di testo aperto a fianco. Per il resto, molti mi hanno confermato che FidoCadJ funziona sotto Linux in maniera pi=F9 che soddisfacente, a condizione che un JRE sia installato.
Spesso è proprio quell'"essere in Java" a rappresentare un grosso problema, almeno per alcuni di noi fra i quali il sottoscritto. Non prendetela come una critica all'autore di FidocadJ che, anzi, dovrebbe essere ringaziato per lo sforzo. Casomai è la scelta di Java a non rappresentare la milgiore soluzione, sempre per alcuni di noi.
Fate questa prova: aprite FidocadJ a vuoto e cliccate ad una certa velocità nel frame con la griglia, senza muovere il puntatore, aggiungere o selezionare nessun oggetto, semplicemente cliccando e basta nella griglia vuota. Da me il carico della cpu va oltre il 40%, e se clicco molto veloce supera anche il 50%. Sto parlando di cliccare a vuoto senza fare o trascinare nulla. Ovviamente questo non succede con Fidocad che gira sotto WINE, che tra l'altro a partire ci mette circa un terzo di FidocadJ. Potrebbe anche essere colpa di un handling non ottimale dell'evento click nel codice di FidocadJ, ma sono convinto per esperienze precedenti che anche Java ci mette del suo, visto che l'approccio VM non è certo dei più efficienti.
Quando si tocca Java il rischio di scatenare flames è elevatissimo, perciò termino qui e, sperando di fare cosa gradita, butto un paio di link a sistemi per creare codice veramente nativo e multipiattaforma, oltre che molto efficiente.
La situazione, purtroppo, non =E8 cos=EC semplice. Ho gi=E0 avuto occasione di discutere a proposito di Java ed ho riassunto la mia posizione nel manuale di FidoCadJ e quindi non parler=F2 di quello, ma piuttosto mi limiter=F2 pi=F9 sotto a dire due cosette sulle performance grafiche dei due programmi. Il fatto di fare un programma multipiattaforma rende la situazione molto pi=F9 intricata di quello che pu=F2 sembrare a prima vista, sulla base della scelta Java/non Java e relative crociate.
re
Dovresti specificare quale JRE stai utilizzando. Diversi mi hanno riportato che con OpenJDK le prestazioni sono insoddisfacenti. Puoi provare se la situazione migliora con un JRE Sun? Inoltre, per diverse ragioni (che accenner=F2 solo parzialmente pi=F9 sotto) FidoCadJ lancia un ridisegno ad ogni click. Potrei probabilmente eliminare qualche ridisegno inutile, il che farebbe migliorare lo score nel tuo test, ma non cambierebbe sostanzialmente nulla riguardo all'impressione d'uso del programma.
Quello =E8 normale ed =E8 effettivamente legato a Java.
i=F9
La questione =E8 molto meno legata alla performance della JVM di quanto si possa pensare per tutta una serie di ragioni, prima fra tutte quella che le versioni recenti e di buona qualit=E0 delle JRE compilano in realt=E0 il codice al volo, raggiungendo prestazioni simili al codice nativo. Programmo abitualmente in C++ per problemi di calcolo scentifico, ho scritto sofware che gira su cluster di calcolo, ho l'abitudine di interfacciarmi a routine come ATLAS e LAPACK e so di cosa sto parlando quando parlo di prestazioni. FidoCadJ =E8 fortemente ottimizzato nel ridisegno, il che vuol dire che in un disegno ragionevolmente complesso (ne ho suggeriti diversi in passato per fare le prove), il tempo impiegato dal programma in questa operazione =E8 rappresentato per un buon 70% dal tempo che serve fisicamente per disegnare sullo schermo le diverse primitive, almeno per quanto riguarda i test che ho fatto sulla mia macchina di sviluppo (iMac G5 del 2005). Il ridisegno =E8 molto pi=F9 importante in FidoCadJ che in FidoCad, perch= =E9 FidoCad utilizza in maniera molto pesante il toggle XOR per disegnare elementi temporanei, il che gli evita di dover ridisegnare tutto per cancellarli. Succede che in ambienti grafici un po' avanzati come Quartz, usare il toggle XOR =E8 un autentico suicidio in termini di prestazioni perch=E9 in un programma di grafica ragionevolmente recente =E8 necessario avere a che fare con l'anti aliasing (che FidoCad non implementa). Anche disattivando l'anti aliasing, sistemi come Quarz (che assolutamente nulla hanno a che fare con Java) *non* possono avere performance soddisfacenti con il toggle XOR, perch=E9 questa tecnica =E8 ormai considerata obsoleta. Ricordiamoci anche che ormai =E8 considerato normale nei sistemi operativi recenti avere a che fare con elementi translucidi, e quindi con la trasparenza parziale degli elementi grafici, con cui il trucco dell'XOR *non* pu=F2 essere compatibile. Teniamo presente che FidoCadJ =E8 multipiattaforma, certo, ma io uso il programma su MacOSX e quindi ho tendenza a ottimizzare in questa direzione non utilizzando tecniche che forniscono deliberatamente performance insoddisfacenti su questo sistema operativo. Non per mancanza di volont=E0, ma questo =E8 il mio ambiente di lavoro e se non fosse stato cos=EC avrei usato FidoCad con Wine senza passare buona parte del mio tempo libero su FidoCadJ... Fermo restando che =E8 essenziale ridisegnare l'intero schema molto pi=F9 di frequente di quanto non facesse il FidoCad originale non avendo a disposizione il trucco dello XOR, resta il problema di farlo in fretta. In questo gioca un ruolo non indifferente come viene configurata la JRE. Se per una ragione o per un'altra la JRE *non* utilizza un'accelerazione hardware per fare le cosette di cui sopra (anti aliasing e alpha channel), le prestazioni grafiche sono deteriorate in maniera molto decisa. Io faccio i mei test nei sistemi operativi che ho installati sulle macchine di cui dispongo, ovvero MacOSX e Windows XP (non mi ricordo le versioni delle JRE, ma comunque sempre di origine SUN e ragionevolmente aggiornate). Durante i miei benchmark, mi sono accorto che su Windows XP il tempo di ridisegno di uno schema molto complesso =E8 nettamente inferiore su FidoCadJ rispetto a FidoCad. Il tempo puro e semplice necessario per disegnare le primitive grafiche =E8 qualcosa che non dipende dal fatto che uno utilizzi Java, il C++ o un BASIC interpretato, perch=E9 in qualunque implementazione degna di questo nome si far=E0 affidamento al sottosistema grafico fornito dal sistema operativo, oppure da delle librerie accelerate dall'hardware. La situazione non cambierebbe utilizzando QT, perch=E9 lo stesso problema si ripresenterebbe assolutamente identico, a meno di non utilizzare soluzioni deliberatamente obsolete che probabilmente produrrebbero performance disastrose su sistemi come Quartz.
Diverso =E8 invece il discorso per quel 30% del tempo che invece dipende effettivamente da Java e dall'algoritmo che ho scelto. A parte il fatto di scontrarsi con colli di bottiglia che possono apparire in alcune implementazioni insoddisfacenti della JRE (esistono e diversi si sono lamentati delle versioni disponibili sotto Linux), temo che il margine che uno possa aspettare di ridurre utilizzando del codice nativo sia insospettabilmente ridotto.
Naturalmente sarei molto felice di venir smentito con i fatti, ma non credo che con QT su MacOSX e Quartz si avrebbero prestazioni migliori di quello che fa FidoCadJ in Java.
Detto questo, =E8 assodatoo che su Linux ogni tanto ci sono dei problemi di prestazioni e mi piacerebbe che qualcuno potesse darmi una mano per risolverli, o almeno potesse darmi una mano per identificarne l'origine. Io faccio quello che posso, ho la massima simpatia per Linux, ma non ho una macchina su cui fare i test. Sospetto che le performance insoddisfacenti vengano pi=F9 da problemi di installazione della JRE che dal mio programma, ma non so come fare da solo per trovare una soluzione.
non essendo un programmatore mi fido di quanto affermi, ma avendo usato fidocadj qualche volta (per farci disegnini, non ho l'ardire di volerli chiamare progetti) non ho notato, in pratica, alcun problema. Penso che sia scontato che usando un qualsiasi programma in java ci siano anche controindicazioni.
Adriano
p.s. a me, per qualche motivo probabilmente del tutto irrazionale, non riesce a piacere wine. Forse perche' non mi fa funzionare quei 2 o 3 software che ancora mi tengono in qualche modo legato a win.
Non hai torto, wine non svolge del tutto bene i compiti per i quali era nato e non e' privo di bug. La borland col sistema di sviluppo Delphi, per fare un esempio, voleva entrare anche in ambiente Linux tramite la libreria wine. Dopo credo un anno ha abbandonato tutto per le grosse problematiche incontrate.
Quello =E8 un po' pi=F9 complicato :-) Molti si lamentano di Java per partito preso senza sapere che alcune problematiche... non sono affatto legate al linguaggio, ma ad un insieme di fattori di cui peraltro il programmatore fa parte. Con le conoscenze di cui dispongo, posso assicurare che se avessi scritto FidoCadJ in C++ nativo invece che in Java, l'unica cosa in cui sarebbe pi=F9 rapido sarebbe nell'avvio.
Ad ogni modo, ho recuperato e rimesso in funzione un vecchio portatile (P3 a 700 MHz con 256 MiB di RAM) con Linux Mandrake 10.1. Tutto vecchissimo, quindi. Ho scaricato una versione di JRE aggiornata dal sito Sun, un pacchetto rpm che si =E8 installato senza colpo ferire nonostante l'ambiente obsoleto. FidoCadJ 0.23.3 ci gira abbastanza bene, anche se ci sono dei rallentamenti evidenti con i disegni complessi. Ho quindi provato FidoCad, ma ho una versione preistorica di Wine non essendo riuscito ad aggiornarla e non =E8 molto stabile. Come prestazioni "velocistiche" nel ridisegno, FidoCad =E8 comparabile se non peggiore di FidoCadJ. Devo riuscire ad aggiornare Wine per rifare la prova.
Non =E8 mia intenzione dimostrare che FidoCadJ sia migliore di FidoCad, ma solo vedere se c'=E8 un problema oppure no. Se Java vi d=E0 fastidio usate pure Wine. Ne deduco per=F2 che se trovate FidoCadJ tanto lento su Linux con calcolatori recenti, vuole dire che c'=E8 qualcosa che non va nel vostro ambiente e consiglierei caldamente di aggiornare la JRE scaricandola direttamente dal sito di Sun. Dal canto mio, continuo volentieri nella ricerca di colli di bottiglia per quanto riguarda le prestazioni di FidoCadJ.
E non funziona su un G5. Uso VirtualBox per utilizzare Windows sul mio MacBook, che =E8 un Core Duo, ma non ho assolutamente lo spazio (e la voglia) di installare Linux. Ho recuperato invece un vecchio portatile PIII, vedi sopra.
Guarda, se devo essere onesto FidocadJ è uno dei due o tre programmi Java che mi hanno stupito per la sua rapidità, a parte ovviamente il tempo che ci mette per caricare tutto il malloppo Java all'inizio, ma quella non è certo colpa sua. Il problema che citavo era solo marginale, ma lo ritenevo indicativo proprio perchè invece del ridisegno di uno schema complicato era il refresh di un grafico vuoto, perciò immaginavo che una funzione apparentemente semplicissima una volta eseguita dentro la JVM potesse sprecare tanti cicli per nulla.
Come avrai capito, sono uno di quelli che non ama Java. Però non con il linguaggio in sè, che è appunto un linguaggio e basta e male non può fare, ma con l'approccio che spesso tende a far scegliere con leggerezza di far girare qualunque cosa su una macchina virtuale, con tutto quello che comporta. Non è molto diverso, almeno secondo me, dalla tendenza a voler "webbizzare" o "cloudizzare" qualunque cosa, che fa il paio con la follia tipica di una decina di anni fa di voler riscrivere tutto il mondo in Visual Basic. Se ci siete passati sapete di cosa parlo; per gli altri: beati voi!:-)
Secondo me, molti programmatori, soprattutto fa quelli alle prime armi, oggi scrivono software in Java non perchè vogliano renderli multipiattaforma ma perchè è l'unico linguaggio che conoscono, questo grazie anche allo stato pietoso dell'IT nostrana che spinge sempre più sviluppatori a buttarsi in uno dei pochi rami dove ancora si sviluppa qualcosa, quello gestionale/web, dove Java la fa da padrone. Secondo me gran parte del cattivo software in Java viene da li'.
Io lo ero, circa due vite precedenti e qualche era informatica fa (che sostanzialmente equivale quasi a non esserlo mai stato), quindi non escludo affatto che Java negli ultimi anni sia diventato abbastanza efficiente da non farti rimpiangere C e C++.
Nemmeno io. A parte il discorso dei click a vuoto che imputavo a Java, devo dire che FidocadJ mi ha fatto una bella impressione.
Dillo a me... purtroppo di software che non gira con wine ce ne è ancora troppo in giro, ma d'altra parte i programmatori non possono fare miracoli visto che il soft che non ci gira è sistematicamente chiuso e gli autori non collaborano nemmeno a pregarli in ginocchio. In questo contesto, i risultati di wine sono comunque da considerarsi un vero e proprio capolavoro. E comunque, piano piano, la lista del software che ci gira aumenta di continuo. L'altro giorno ho provato per l'ennesima volta e senza particolari speranze a installare e far girare il compilatore C per PIC di Mikroelektronika e ho notato che finalmente andava senza problemi. Erano anni che chiedevamo una cosa simile sui forum e alla fine siamo stati accontentati. A volte basta aver pazienza:)
Mi riapri una ferita non da poco. Kylix ha fatto sognare anche me; ero lì speranzoso quando Marco Cantù in persona venne a presentarlo ad una conferenza. Poi lo provai e rimasi profondamente deluso dalle prestazioni e dall'instabilità. Non so come abbiano fatto usando le librerie di wine ad ottenere prestazioni così scadenti, molto peggiori di quello che ci si poteva aspettare dalle macchne di allora, ma alla fine conveniva scrivere il software con Delphi e cercare di farlo girare con il wine di serie, oppure lasciar perdere e usare Delphi sotto Windows.
Per fortuna oggi il multipiattaforma Delphi-like esiste. Si chiama Lazarus, è totalmente free, molto compatibile con Delphi, genera codice nativo al 100% e non richiede nessuna virtualizzazione, ne' WINE o altri artifici. Dategli un'occhiata perchè è cresciuto moltissimo negli ultimi anni e merita davvero considerazione.
la mia non voleva essere un'accusa ai creatori di wine. Date le premesse (e quello che costa) fa anche troppo. Purtroppo non quello che serve a me, quindi non lo uso.
asdf wrote in news:yMaKn.172242$ snipped-for-privacy@twister1.libero.it:
Ma se alla fine (= non sempre, ma spesso) con wine sei costretto a tirarti in linux le varie DLL del mondo windows (per prime il "pollo fritto alla microsoft", MFC ;-) ) con tutti i problemi del caso (non ultimi le royalties), non si fa prima ad installare una sessione di windows in VMWare e buona notte?
(Ovvero emulazione vs virtualizzazione)
Beninteso, solo da un punto di vista di funzionalità per l'utilizzatore.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.