Creazione pacchetto rpm per fedora

[Anonymous]

Dunque ciao darwin sono maurotec di arduino, sposto qui la discussione perchè
prettamente tecnica.
Quello che ho fatto è la seguente:
Il comando javac presente nello script compile di default in fedora 12 non c'è
allora ho installato tramite il gestore di pacchetti :
java-1.6.0-openjdk-devel-1.6.0.0-43.1.8.3.fc12.i686, che si è portato alcune
dipendenze appresso.

Eseguendo ./compile si verificano degli errori e delle avvertenze sul fatto
che la codifica non utf8 te li mostro:
src/AppleSpecific.java:4: package com.apple.eawt does not exist
import com.apple.eawt.*;
^
src/AppleSpecific.java:38: cannot find symbol
symbol: class ApplicationListener
class AppleSpecific implements ApplicationListener{
^
src/AppleSpecific.java:52: cannot find symbol
symbol : class ApplicationEvent
location: class AppleSpecific
public void handleAbout(ApplicationEvent evt)
^

la seconda volta che lancio compile i messagi di avvertimento non li vedo più.
ok mancano delle dipendenze in particolare la riga import com.apple.eawt.* se
non sbaglio dice che non può importare una serie di moduli, quelo che mi
preoccupa è la scritta apple.

Secondo te che altri pacchetti devo installare per portare avanti il compile
senza errori?

[Davide Bucci]

Ciao e benvenuto qui,
come ho già avuto modo di dirti sul forum di Arduino, sono molto contento che
qualcuno si interessi a facilitare la vita ai nostri amici che usano Linux e
che cercano qualcosa tipo un pacchetto rpm.

Veniamo alla tua domanda. E' perfettamente normale che non compili, perché ho
utilizzato nel codice alcune estensioni tipiche di un ambiente MacOSX. Non è
poi un gran problema e difatti è stato semplice fare in modo che non vengano
affatto utilizzate una volta che l'archivio Jar è creato.
Per compilare però (alle volte penso che mi farebbe comodo un preprocessore
anche in Java), ci sono alcune linee da commentare in un file. Riporto qui
quanto ho scritto nel README:

3.1 Compile and run the sources from a MacOSX operating system (>=1.3.9) 
------------------------------------------------------------------------

If you have MacOSX, you just open up a terminal window, go into the 
fidocadj/trunk directory and type:

  ./rebuild

And FidoCadJ should be automatically compiled and run.

3.2 Compile and run the sources from another operating system
-------------------------------------------------------------

If you type the ./rebuild command directly as described in section 3.1, you
will probably stumble in a lot of errors. The Java compiler is complaining 
that there are some Apple-stuff related classes which are not found.
You need to edit a little the following file:

fidocadj/trunk/src/FidoMain.java

You should search the following lines (around line 314 and something):

        // Probably, you need to strip this code if you need to compile the
        // program under a non-Apple platform.

        if(Globals.weAreOnAMac) {
            AppleSpecific a=new AppleSpecific();
            a.answerFinder();
        }

You should comment the code block as follows:

        // Probably, you need to strip this code if you need to compile the
        // program under a non-Apple platform.

        /* if(Globals.weAreOnAMac) {
            AppleSpecific a=new AppleSpecific();
            a.answerFinder();
        }       */

And everything should compile fine.

In altre parole, bisogna commentare alcune linee che fanno riferimento alla
classe AppleSpecific intorno alla linea 314 della file src/FidoMain.java.
Devo decidermi ad utilizzare le tecniche di rifilessione per evitare
quest'operazione, mi ci andrà qualche giorno. Tuttavia posso assicurare che
basta questa piccola correzione e che diversi sono già riusciti a compilare i
sorgenti con Linux.

Per quanto riguarda gli errori relativi all'UTF-8 non ne sono a conoscenza,
potrebbe darsi che vengano fuori con una versione di Java più recente della
mia. Puoi fare copia/incolla qui, per favore?

Se serve altro, fammi sapere

[Anonymous]

Ok ora compila ed a run-time non vedo alcun errore, però ho dovuto
decommentare la seconda riga dell script "compile", tuttavia sul mio PC la
lentezza lo rende non usabile.

Il PC in questione:
Initializing CPU#1
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU1: AMD Athlon(tm) II X2 260 Processor stepping 03
checking TSC synchronization : passed.
01:05.0 VGA compatible controller: ATI Technologies Inc 760G
2048 Gb RAM

Fedora 12
Linux version 2.6.32.26-175.fc12.i686.PAE

Cosa si può fare per rendere il programma un pò più reattivo, così com'è non
ha molto senso impacchettarlo, comunque ho trovato le line guida per
impacchettare applicazioni java, così i pacchetto rispetterebbe le direttive
di fedora.

Quello che segue è quello che ho fatto da console:

Installo: java-1.6.0-openjdk-devel-1.6.0.0-43.1.8.3.fc12.i686
che si porta queste dipendenze
Mar 08 13:26:46 Installed: jna-3.2.7-8.fc12.i686
Mar 08 13:26:48 Installed: swing-layout-1.0.3-4.fc12.i686
Mar 08 13:26:48 Installed: javahelp2-2.0.05-8.fc12.noarch
Mar 08 13:26:50 Installed: netbeans-platform-6.7.1-2.fc12.noarch
Mar 08 13:26:54 Installed: 1:java-1.6.0-openjdk-devel-1.6.0.0-43.1.8.3.fc12.i686

Creare patch per commentare le seguenti righe nel file src/FidoMain.java (4 righe a partire dalla 314)
    /*if(Globals.weAreOnAMac) {

                AppleSpecific a=new AppleSpecific();

                a.answerFinder();

            }*/
Altrimenti non compila. 
commentate ok.
Errore run-time
[mauro@localhost fidocadj-0.23.5-svn163]$ ./run 
Exception in thread "main" java.lang.NoClassDefFoundError: ScrollGlassPane
    at FidoFrame.init(FidoFrame.java:384)
    at FidoMain.main(FidoMain.java:327)
Caused by: java.lang.ClassNotFoundException: ScrollGlassPane
    at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:334)
    ... 2 more
Riprovo da capo così, azzerando tutto:
[mauro@localhost fidocadj-0.23.5-svn163]$ ./compile 
src/circuit/ParseSchem.java:1961: warning: unmappable character for encoding UTF8
        // Il codice � replicato dalla funzione draw().
                     ^
src/circuit/CircuitPanel.java:263: warning: unmappable character for encoding UTF8
        [B]                 B�zier
                             ^
src/circuit/CircuitPanel.java:716: warning: unmappable character for encoding UTF8
        // Add a B�zier polygonal curve: we need four clicks.
                  ^
src/export/ExportInterface.java:94: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
src/primitives/PrimitiveBezier.java:15: warning: unmappable character for encoding UTF8
/** Class to handle the B�zier primitive.
                         ^
src/primitives/PrimitiveBezier.java:42: warning: unmappable character for encoding UTF8
    // A B�zier is defined by four points.
          ^
src/primitives/PrimitiveBezier.java:74: warning: unmappable character for encoding UTF8
    /** Create a B�zier curve specified by four control points
                  ^
src/primitives/PrimitiveBezier.java:259: warning: unmappable character for encoding UTF8
        // in the B�zier primitive, the four virtual points represent
                   ^
src/primitives/PrimitiveBezier.java:265: warning: unmappable character for encoding UTF8
            // Create the B�zier curve, which in the Java library is called a 
                           ^
src/primitives/PrimitiveBezier.java:358: warning: unmappable character for encoding UTF8
        if (tokens[0].equals("BE")) {   // B�zier
                                            ^
src/primitives/PrimitiveBezier.java:363: warning: unmappable character for encoding UTF8
            // Parse the coordinates of all points of the B�zier curve
                                                           ^
src/primitives/PrimitiveBezier.java:417: warning: unmappable character for encoding UTF8
        // If not, we check for the distance to the B�zier curve.
                                                     ^
src/primitives/PrimitiveAdvText.java:656: warning: unmappable character for encoding UTF8
    /** Rotate the primitive. Here we just rotate 90� by 90�
                                                    ^
src/primitives/PrimitiveAdvText.java:656: warning: unmappable character for encoding UTF8
    /** Rotate the primitive. Here we just rotate 90� by 90�
                                                           ^
src/primitives/PrimitivePCBPad.java:336: warning: unmappable character for encoding UTF8
    /** Rotate the primitive. Here we just rotate 90� by 90� by swapping the
                                                    ^
src/primitives/PrimitivePCBPad.java:336: warning: unmappable character for encoding UTF8
    /** Rotate the primitive. Here we just rotate 90� by 90� by swapping the
                                                           ^
src/geom/GeometricDistances.java:37: warning: unmappable character for encoding UTF8
    // point and a B�zier curve.
                    ^
src/geom/GeometricDistances.java:468: warning: unmappable character for encoding UTF8
        a B�zier curve. The curve is divided into MAX_BEZIER_SEGMENTS 
           ^
src/geom/GeometricDistances.java:473: warning: unmappable character for encoding UTF8
        @param x1 x coordinate of the first control point of the B�zier curve.
                                                                  ^
src/geom/GeometricDistances.java:474: warning: unmappable character for encoding UTF8
        @param y1 y coordinate of the first control point of the B�zier curve.
                                                                  ^
src/geom/GeometricDistances.java:475: warning: unmappable character for encoding UTF8
        @param x2 x coordinate of the second control point of the B�zier curve.
                                                                   ^
src/geom/GeometricDistances.java:476: warning: unmappable character for encoding UTF8
        @param y2 y coordinate of the second control point of the B�zier curve.
                                                                   ^
src/geom/GeometricDistances.java:477: warning: unmappable character for encoding UTF8
        @param x3 x coordinate of the third control point of the B�zier curve.
                                                                  ^
src/geom/GeometricDistances.java:478: warning: unmappable character for encoding UTF8
        @param y3 y coordinate of the third control point of the B�zier curve.
                                                                  ^
src/geom/GeometricDistances.java:479: warning: unmappable character for encoding UTF8
        @param x4 x coordinate of the fourth control point of the B�zier curve.
                                                                   ^
src/geom/GeometricDistances.java:480: warning: unmappable character for encoding UTF8
        @param y4 y coordinate of the fourth control point of the B�zier curve.
                                                                   ^
src/geom/GeometricDistances.java:486: warning: unmappable character for encoding UTF8
                and the B�zier curve specified by the control points.
                         ^
src/geom/GeometricDistances.java:510: warning: unmappable character for encoding UTF8
            // This is the parametric form of the B�zier curve.
                                                   ^
src/export/ExportSVG.java:179: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
src/export/ExportEPS.java:231: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
src/export/ExportPGF.java:197: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
src/export/ExportPDF.java:506: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
src/export/ExportEagle.java:162: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
src/export/ExportEagle.java:201: warning: unmappable character for encoding UTF8
        out.write("# B�zier export not implemented yet\n");
                      ^
src/export/ExportFidoCad.java:162: warning: unmappable character for encoding UTF8
    /** Called when exporting a B�zier primitive.
                                 ^
Note: src/FidoFrame.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
35 warnings

#### Ho decommentato la seconda linea nel file compile per compilare con Xlint:deprecation

[mauro@localhost fidocadj-0.23.5-svn163]$ ./compile                     
./src/FidoFrame.java:812: warning: [deprecation] show() in java.awt.Window has been deprecated
                show();
                ^
./src/FidoFrame.java:1392: warning: [deprecation] decode(java.lang.String) in java.net.URLDecoder has been deprecated
                                java.net.URLDecoder.decode(
                                                   ^
./src/FidoFrame.java:1689: warning: [deprecation] show() in java.awt.Window has been deprecated
            show();
            ^
3 warnings
[mauro@localhost fidocadj-0.23.5-svn163]$ 
Dopo ho commentato la riga 2 di compile e non dà più alcuno errore.

Se c'è un'altro utente fedora che può provare sarebbe utile, ripeto è
lentissimo sia ad aprire un menu che a visualizzare un simbolo grafico e la
vista e tutto.

Ciao.

[Davide Bucci]

Per la lentezza, ho provato il programma su un portatile con un pentium 3 a
700 MHz e 256 MiB di RAM. C'è installata una vecchia Mandrake del 2004 ma ho
aggiunto una macchina virtuale Java molto recente di origine Sun/Oracle.
La mia macchina di sviluppo è un iMac G5 dell'aprile 2005 ed il ridisegno del
disegno complesso che utilizzo per i test è abbondantemente sotto i 100 ms
(nell'ultima versione di FidoCadJ), mentre sale a 145 ms sul pentium III
disattivando però l'antialiasing. Il disegno è questo:

davbucci.chez-alice.fr/elettronica/fidocadj/tracciacurve_quad.fcd

Ho avuto diverse conferme che il problema gira molto bene anche sotto altre
distribuzioni di Linux. Vedi per esempio il messaggio 11 di questa
discussione:

http://www.electroyou.it/phpBB2/viewtopic.php?f=16&t=20801&st=0&sk=t&sd=a&sid
=21cacd8f57efa4c735d4676bf2f5cb3e&start=10#p154144

Qui c'è un'altra discussione molto interessante in cui approfondisco alcuni
aspetti tecnici legati a Java e le prestazioni di velocità di FidoCadJ:

http://groups.google.com/group/it.hobby.elettronica/browse_thread/thread/9b02
275bce16bdc9/8e4d01f540bd1948

Se mi è concesso citarmi:

Ne deduco però che se trovate FidoCadJ tanto lento su Linux con calcolatori
recenti, vuole dire che c'è 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.

Purtroppo, un altro utente Fedora si è lamentato in questa discussione:

https://sourceforge.net/projects/fidocadj/forums/forum/997486/topic/3474689

Se leggi i messaggi di Greybear, un uno dei messaggi della seconda pagina
riporta tempi allucinanti, segno evidente di un problema:

https://sourceforge.net/projects/fidocadj/forums/forum/997486/topic/3474689/i
ndex/page/2

Nel messaggio 13 della seconda pagina il problema viene risolto (credo con un
aggiornamento della macchina virtuale) e Greybear è finalmente riuscito ad
utilizzare in maniera accettabile il programma.

[Davide Bucci]

Dimenticavo i messaggi: sono tutti warning. Dovrò essermi dimenticato di
settare l'encoding corretto su un file (verificherò), mentre il problema con
lo "show" è buono a sapersi. La compilazione sembra essere andata a buon fine
perché non ci sono errori gravi.
Il motivo per cui non hai ottenuto nulla alla seconda esecuzione può darsi sia
dovuto al fatto che Java si è accorto che non c'era nulla da compilare e
quindi non ha neppure esaminato i file originanti i warning.

[greybear]

Scarica java dal sito della Sun e apri fidocadj con questo altro java. Sul mio
Fedora14 64bit sta sotto /usr/java/jre1.6.0_24/bin/java.
Java è questo: # /usr/java/jre1.6.0_24/bin/java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

Vedrai che la velocità ritorna normale ;)
Per motivi a me sconosciuti le openjdk danno questo problema con fidocadj e
purtroppo non si può disinstallare per via delle molteplici dipendenze con un
casino di programmi. Io per lo meno non mi arrischio.

[Davide Bucci]

Caro maurotec,
ho appena fatto un commit dei sorgenti versione 164 di FidoCadJ. Dovrebbe
compilarsi su Linux senza problemi, senza dover toccare i file (almeno in
teoria, se provi e mi fai sapere ti sarò riconoscente). Gli utenti MacOSX
dovranno però lanciare gli script 'compile' e 'rebuild' con l'opzione 'mac'
quando FidoCadJ verrà compilato su MacOSX. Ad ogni modo, il programma
segnalerà chiaramente l'anomalia se qualcuno si dimenticasse di farlo. Anche
il README è stato aggiornato. Mi servirebbe qualcuno che facesse la prova su
Windows se le istruzioni che ho scritte sono corrette oppure no.

Ciao, Greybear, grazie delle informazioni!

[Anonymous]

Ho avuto problemi con la connessione non mi apriva il forum. Vedo che i miei
dubbi erano fondati. Anche L'Ide java Arduino non è veloce ma si può usare, ma
fidocadj e inusabile, sembra proprio ci sia un modo di usare la openJDK per
fare andare i programmi veloce diverso da quello che si usa per la JRE sun.

Il punto della situazione è questo:
A poco senso fare un pacchetto per un distro qualsiasi, anche perchè cosa
indico come dipendenza, non posso certo mettere un pacchetto che non c'è nel
repo di fedora. Questo complica le cose, devo lavorarci un pò su.

Mi pongo delle domande:
Vedo dei nomi nei sorgenti che mi fanno pensare ci sia la possibilità che non
si stiano usando le librerie che sono installate sul sistema.
Es io ho questo su fedora:
Mar 08 13:26:46 Installed: jna-3.2.7-8.fc12.i686 Mar 08 13:26:48 Installed:
swing-layout-1.0.3-4.fc12.i686
Mi chiedo il sorgente di fidocadj le sta usando o ha all'interno dei
sostituti, la causa del lentezza potrebbe essere questa?

ho appena fatto un commit dei sorgenti versione 164 di FidoCadJ.

Bene mi dai una dritta per aggiornare il mio repo in locale, perche tra git
mercurial svn con cui ho avuto a che fare non ci sto capendo più nulla. Vabbe
al limite lo scarico di nuovo per intero.

Sono cotto passo e chiudo, devo codividere tutto anche il mal di denti che mi
tormenta.

Ciao.

[Davide Bucci]

Ho avuto problemi con la connessione non mi apriva il forum. Vedo che i miei
dubbi erano fondati. Anche L'Ide java Arduino non è veloce ma si può usare, ma
fidocadj e inusabile, sembra proprio ci sia un modo di usare la openJDK per
fare andare i programmi veloce diverso da quello che si usa per la JRE sun.

E' probabile, anche perché se il problema si manifestasse proprio dappertutto,
sarebbe facile risolverlo. Penso che ci sia un collo di bottiglia particolare
che rende pesantemente inadeguate le prestazioni, solo che non è facile fare
un debug a distanza. E' possibile che sia dovuto a qualcosa di non pulitissimo
che mi è scappato nel codice, altre volte che mi è capitato qualcosa del
genere è stata colpa mia (ma non proprio sempre). Forse un bug grafico? Per
una ragione o per un'altra le routine di disegno del driver che gestisce la
grafica non sono accelerate via hardware? Dovrei procurarmi una macchina su
cui installare una Fedora e vedere cosa succede... ma non prevedo di fare
nuovi acquisti hardware, per cui per adesso drizzate le antenne e fatemi avere
le vostre impressioni!

Vedo dei nomi nei sorgenti che mi fanno pensare ci sia la possibilità che
non si stiano usando le librerie che sono installate sul sistema.
Es io ho questo su fedora:
Mar 08 13:26:46 Installed: jna-3.2.7-8.fc12.i686 Mar 08 13:26:48 Installed:
swing-layout-1.0.3-4.fc12.i686
Mi chiedo il sorgente di fidocadj le sta usando o ha all'interno dei
sostituti, la causa del lentezza potrebbe essere questa?

Molto interessante. Dov'è che vedi i nomi di cui parli? Io non ho mai
richiesto cose strane, mi limito ad utilizzare il package Swing che dev'essere
disponibile per default. Non è che magari il problema viene proprio da lì?
L'IDE di Arduino è basata su Swing oppure no? L'uso di una certa libreria
oppure di un'altra dipende da com'è configurata la JVM e non c'entra con
FidoCadJ (o almeno non dovrebbe).
Comunque, so di gente che utilizza con successo il runtime OpenJDK con
FidoCadJ e le prestazioni sono eccellenti, quindi il problema potrebbe venire
da una versione in particolare, oppure da un problema legato all'interazione
con la macchina. Qual è la versione installata sulla tua macchina? Per
saperlo, basta scrivere da linea di comando:

java -version

Bene mi dai una dritta per aggiornare il mio repo in locale, perche tra git
mercurial svn con cui ho avuto a che fare non ci sto capendo più nulla. Vabbe
al limite lo scarico di nuovo per intero.

No, non c'è bisogno di riscaricare tutto (questa è la comodità di un sistema
di controllo di versione). Via linea di comando, ti metti all'interno della
tua copia locale del repository e scrivi:

svn update

E lui dovrebbe scaricare solo le differenze ed aggiornarti il repository alla
revisione 165 (ho lavorato un po' ieri).

Sono cotto passo e chiudo, devo codividere tutto anche il mal di denti che
mi tormenta.

Ahi, coraggio! Spero che oltre al mal di denti, FidoCadJ non ti faccia venire
anche il mal di testa!

[Davide Bucci]

Ciao Maurotec,
come procedono le cose? Sei poi riuscito a fare in modo che FidoCadJ giri ad
una velocità accettabile?
Mi piacerebbe sapere da dove può venire il problema ed in particolare se è
legato all'uso di Swing. Cambiando versione di Java come suggerito da
Greybear, le cose migliorano?

Davide

[Davide Bucci]

Questa discussione suggerisce alcuni spunti molto interessanti:

http://www.electroyou.it/phpBB2/viewtopic.php?f=16&t=24865&p=191015#p191015