FidoCadJ 0.24.9 alpha

[gvee]

Grazie, domani la provo. Così vedo meglio le traduzioni nel caso siano da rivedere.

[gvee]

Provato su Debian 12 con la versione 25 di Java sulla workstation personale.

Funziona bene (non ne avevo dubbi) ma la Debian è in inglese quindi dovrò per forza provarlo su Windows (pure in inglese ma cambiare lingua dovrebbe essere questione di secondi credo). Ancora non sono riuscito a compilarlo li. Mi fa talmente caxxre che mi sta passando la voglia di lavorare..

[DarwinNE]

Ci dovrebbe essere un'opzione da linea di comando per provare FidoCadJ con un altro locale:

Codice: Seleziona tutto

./dev_tools/run -l es

lo script run che si trova in dev_tools si aspetta di essere chiamato dalla directory principale.

[gvee]

Provato su Windows. Mi è servito ad aprire un'altra pull request.

Da ignorantone di Java, chiedo: è proprio necessario fare riferimento alla versione Java in dev_tools/compile (come sotto) ?

Codice: Seleziona tutto

JAVA_VERSION="25"
JAVA_TARGET_VERSION="25"


Se si deve mantenere una dipendenza, forse è meglio far sì che la versione sia opzionale, appunto per come si fa con le opzioni -debug nel for loop qualche linea più sotto.

[gvee]

Ho anche un suggerimento riguardo alla gestione delle librerie personali.

Sembra che FidoCadJ si aspetta che il file della libreria, di una o di più, sia/siano presente/i nella cartella specificata dalle opzioni, p.e. (su Linux):

Codice: Seleziona tutto

/home/$USER/.fidocadj/libs/

Sarebbe interessante far sì che questa cartella sia considerata come radice per una ricerca ricorsiva al suo interno, in modo da poter usare più file in più subdirectories.

Viene comodo nel caso di avere varie librerie personali su github o altrove quindi organizzate in directories distinte. Si fa un clone all'interno della cartella e cosi con altre possibili. È, tra l'altro, una opzione backward compatibile con versioni anteriori, se non mi perdo nulla.

[theking0]

...
Da ignorantone di Java, chiedo: è proprio necessario fare riferimento alla versione Java in dev_tools/compile (come sotto) ?

Codice: Seleziona tutto

JAVA_VERSION="25"
JAVA_TARGET_VERSION="25"


...

Ciao, ho visto che nella pull request hai inserito anche quella modifica del file "compile", non ho ancora provato a compilare su tutti i sistemi, ma cambiando dalla 16 alla 25 potrebbero insorgere dei problemi.
Proviamo ad attendere un riscontro anche di DarwinNE, vediamo com'è meglio procedere.

..
Sarebbe interessante far sì che questa cartella sia considerata come radice per una ricerca ricorsiva al suo interno, in modo da poter usare più file in più subdirectories. ....

Questa sarebbe una modifica strettamente legata al sistema operativo, ogni OS ha i sui percorsi preferenziali per i settaggi e cartelle dei programmi, forse la soluzione migliore è creare e settare un percorso nella cartella portable del programma, come era stato suggerito qualche post fa.

[gvee]

Ciao, ho visto che nella pull request hai inserito anche quella modifica del file "compile"

Scusa, è accidentale, in realtà non era mia intenzione inserirla. Scartala se vuoi ovviamente.

[DarwinNE]

Proviamo ad attendere un riscontro anche di DarwinNE, vediamo com'è meglio procedere.

Ho visto anch'io questa modifica nella pull request. Se devo essere sincero non saprei come procedere. In passato FidoCadJ non era fornito con un runtime di Java, quindi la mia politica è sempre stata quella di richiedere una versione di Java abbastanza vecchia. L'idea era che non si dovrebbe pretendere ad una persona che vuole provare il nostro programmino di fare un aggiornamento di Java. Ovviamente, c'è un limite a questo nel senso che nell'evoluzione di Java sono stati piano piano introdotti costrutti e novità molto utili e sarebbe semplicemente stupido non usarli in FidoCadJ.

Se però FidoCadJ viene distribuito con un runtime di Java, il discorso cambia.

Detto questo, quelle opzioni da me oggi generano un warning, perché non ho Java 16 istallata, ma la 22:

Codice: Seleziona tutto

warning: [options] location of system modules is not set in conjunction with -source 16
  not setting the location of system modules may lead to class files that cannot run on JDK 16
    --release 16 is recommended instead of -source 16 -target 16 because it sets the location of system modules automatically

Penso che l'opzione suggerita dal warning, ovvero la --release sia stata introdotta più di recente rispetto a quando avevo guardato quel problema.

[DarwinNE]

Scusa, è accidentale, in realtà non era mia intenzione inserirla. Scartala se vuoi ovviamente.

Nessun problema, la questione è rilevante. Alla peggio si decide come procedere e si correggono di conseguenza

[theking0]

Si, alla fine compila sempre con il JRE che si sta usando, semplicemente segnala che non è quello settato come argomento di compilazione.

Non è tanto per il pacchetto con il JAR già compilato, ma va considerato anche se qualcuno vuole compilare da sorgenti.

Da quello che vedo nel codice non vengono usato costrutti dichiarati obsoleti e tantomeno quelli integrati nelle ultime versioni, anche se a dire il vero non ho provato a compilare con la 16, cosa che andrebbe verificata.