Re: Usare FidoCadJ direttamente dal browser

funziona per chi ha il S.O. linus ubuntu 9.10?

Tenendo per me i commenti su Java, il fidocad originale a me va perfettamente sotto Linux con Wine.

Reply to
asdf
Loading thread data ...

asdf:

Sono con te.

Ma FidocadJ va meglio.

Reply to
F. Bertolazzi

Il 24/04/2010 1.41, F. Bertolazzi ha scritto:

il "buon samaritano" questa volta concorda col Bertolazzi :)

Non lo so, sotto linux FidoCadJ non l'ho ancora provato (l'ho appena provato una volta sotto Win)... Cmq anche FidoCad funziona benissimo in emulazione, a me non ha mai dato nessun problema.

Reply to
Paolo Squaratti

Paolo Squaratti:

Nono, non sei tu il "buon samaritano" a cui mi riferivo nell'altro thread.

Sì, ma FCJ è più veloce, ti permette di mettere gli attributi ai componenti, di definire linee tratteggiate e "frecciate", di vedere il componente che stai per inserire, di esportare gli schemi in Eagle, PDF, PNG eccetera.

E, nel tuo caso, non ti obbliga manco ad usare l'emulatore.

Reply to
F. Bertolazzi

Per quanto riguarda Java, devo dire che non capisco bene questa posizione. Non =E8 un linguaggio perfetto, ma dopo alcuni anni di utilizzo, alla fine devo dire di trovarmi molto bene. Conosco piuttosto a fondo anche il C++ e lo uso per elaborazioni numeriche non banali (ho scritto e mantengo un software per la simulazione di propagazione elettromagnetica in guide d'onda dielettriche), interfacciandomi con varie librerie scientifiche in Fortran e C. Trovo il C++ ancora insuperabile per applicazioni come queste, in cui per forza di cose sono obbligato a fare molta attenzione a dettagli come la gestione della memoria (lavoro con matrici di 10000 elementi di lato...). Tuttavia, per software legati ad interfaccia utente grafica, l'approccio di Java =E8 comodo, portabile su tutte le piattaforme e fornisce risultati tutto sommato decenti con uno sforzo moderato. Oramai, non =E8 neppure tanto lento e per certe cose =E8 perfino confrontabile al C++. Forse l'unica cosa scomoda sono i due/tre secondi necessari a lanciare la macchina virtuale, cosa percettibile in un'applet ma molto meno quando uno utilizza un'applicazione. Non sono un professionista, ma la mia esperienza mi ha mostrato come quando scrivo software in Java tendo ad introdurre qualche bug in meno rispetto al C/C++. Sono dell'idea che ad un utente non dovrebbe importare molto con che strumenti =E8 realizzato un certo programma, ma dovrebbe piuttosto concentrarsi sul fatto se ci si trova bene oppure no, cosa che dipende molto pi=F9 dal programmatore che dal linguaggio scelto. C'=E8 il fatto che bisogna che Java sia installato nel sistema, ma questo avviene molto spesso ed =E8 per esempio fornito di default su MacOSX.

Reply to
Darwin

Darwin:

Come disse il mio professore, concludendo il corso di "Programming Languages", sono stati fatti tre linguaggi fondamentali: Assembly, Fortran e Algol. Dopodiché tutti gli altri linguaggi non hanno migliorato la produttività dei programmatori se non in modo meno che marginale, un 10% circa.

Ciò che ha veramente rivoluzionato la produttività sono state le IDE. Quella di Java è al livello dell'unica cosa buona che ha fatto Micro$oft, ovvero la IDE di VB?

Non credo fosse intenzione di nessuno interessarsene se non per fare qualche battutina gratuita.

Invece di perder tempo a rispondere a queste stupidaggini, lavora sugli attributi di FCJ! ;-)

Reply to
F. Bertolazzi

Il 26/04/2010 10.14, F. Bertolazzi ha scritto:

Ah, ok, avevo pensato ti riferissi a me...

Sugli attributi, linee, ecc concordo e sono tutte cose molto utili, sulla velocità mi sembra cmq più veloce il vecchio, ma magari è perchè io lo uso su pc scarsi... Usato in emulazione probabilmente le velocità tra il J e non J si equiparano, devo provare il J sotto linux... ciao

Reply to
Paolo Squaratti

Il 26/04/2010 10.33, Darwin ha scritto:

Sarò sincero, è una posizione più di principio che dettata da dati di fatto. Più che altro è dettata dal ricordo dei vecchi programmi in Java sulla macchina virtuale, diciamo negli anni 2002/2003, probabilmente scritti anche male, che erano lentissimi rispetto a programmi in altri linguaggi come il C++. Cmq il tuo programma in particolare l'ho ancora provato poco e quindi non posso esprimermi, anche se onestamente mi sembra un buon prodotto e gira abbastanza veloce, anche se, come dicevo in un'altro post, a me sotto win sembra ancora più veloce il vecchio, ma ce l'ho su un pc un po' scarso... ciao

Reply to
Paolo Squaratti

n

=E0

Non sono del tutto d'accordo. Trovo che la programmazione ad oggetti sia qualcosa di spaventosamente potente. Anche l'utilizzo dei template =E8 molto comodo. Poi, da un certo punto di vista, tutti i linguaggi Turing-completi sono equivalenti...

t,

Penso che esistano degli ottimi IDE per Java, ma non sono la persona giusta per rispondere a questo quesito perch=E9 sono anni che gli IDE mi fanno venire l'orticaria... Ma questa =E8 una cosa che dipende solo da me e dal mio modo di programmare.

Lo so, lo so :-)

Reply to
Darwin

di

va

Lo so, per quello ne parlo :-) La situazione =E8 migliorata moltissimo negli ultimi anni, non parlo solo per difendere il mio programmino. Ormai si inizia a parlare realisticamente di Java anche per risolvere alcuni problemi numerici. Per esperienza per=F2 mi sono accorto che pi=F9 che il fatto di utilizzare Java o il C++ conta... il programmatore! Java ha per esempio una biblioteca standard molto completa, moderna ed articolata ed =E8 molto facile utilizzarla in maniera sub-ottimale. C'=E8 anche da dire che molti programmi Java si riconoscono per il loro look and feel Metal che non =E8 molto bello... Per questo, con FidoCadJ utilizzo il l&f nativo, anche se non ho fatto nessuno sforzo per adattarlo al meglio a Windows, per esempio (non usando quasi mai questo sistema operativo).

Tieni conto che la macchina su cui sviluppo ha ormai pi=F9 di 5 anni, quindi anch'io sono molto sensibile a questo genere di problemi. Le mie prove le ho fatte su MacOSX e su Windows con un portatile pi=F9 recente; su Linux ho ricevuto invece dei feedback contrastanti. Quello che =E8 sicuro =E8 che per disegnare una finestra e disporre gli elementi di interfaccia, Java =E8 molto pi=F9 lento di una soluzione nativa, dato che Java utilizza un sistema completamente skinnable. Comunque, le ultime versioni di FidoCadJ fanno un refresh del disegno su cui si sta lavorando da 4 a 10 volte pi=F9 rapido di quelle di un anno fa.

Reply to
Darwin

Paolo Squaratti:

O, più probabilmente, perché non hai l'ultima versione.

Reply to
F. Bertolazzi

Darwin:

Io no. Hanno, inevitabilmente, una granularità troppo sottile o troppo grossa. Con sabbia e massi si fanno brutti edifici, meglio i mattoni e il cemento.

Se ho capito bene, a dire il vero è proprio perciò che ancora detesto Java. Appena uscito Bill cercò di sabotarlo, introducendo centinaia di classi

*simili* a quelle di Sun, e non ci si capiva più nulla.

Male. Mi sa sei peggio di SB. ;-)

Reply to
F. Bertolazzi

Il giorno Mon, 26 Apr 2010 15:18:24 +0200, "F. Bertolazzi" ha scritto:

Sta storia degli oggetti l'hanno pompata in modo tale che hanno rotto gli 'oggetti', o forse dovrei dire 'gioielli'?

A me non dispiace nonostante le graffe, ma non ci ho fatto niente di complesso, ho soprattutto modificato cose fatte da qualcun altro per le mie esigenze, d'altra parte abbiamo un cocopro che usa praticamente solo java.

Bene :-P

SB che programma ancora con soddisfazione gli AVR (ultimamente anche un ARM) in macroassembler, e usa sempre più spesso Python, un linguaggio che mi piace proprio perchè è poco tipizzato (cosa che invece a te naturalmente non va), e ora che si può usare con le QT rende possibile fare le cose in poco tempo.

Certo l'ide non è quello di VB6, ma a me il C++ fa venire l'orchite e se uno deve fare delle cose multipiattaforma Python è un buon compromesso tra velocità e usabilità.

-- ciao Stefano

Reply to
SB

SB:

Ovvove!

Usi Python solo su PC o anche sui controller?

Scherzi a parte, il thread su i.h.e.d mi ha veramente entusiasmato. La prossima volta che dovessi fare un front-end su PC non avrei dubbi.

Reply to
F. Bertolazzi

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.