Onderwerp: OpenCPN installeren op Linux systeem

Dat is dan met de PPA voor Bionic neem ik aan?

Ik heb denk ik gevonden waar het misgaat in de code.
Voor het omzetten van het getal 52.123456 naar de tekst “52.123456” wordt de functie Printf gebruikt. Die functie kijkt standaard naar de taal van de gebruiker, maar dat hebben ze op een andere plek in de code uitgezet voor het hele programma.
Ik heb het probleem ook niet in een nieuwe kale installatie op Mint 19.3.

Mijn vermoeden is dat een plug-in die instelling weer aan zet. Welke plug-ins heb je geactiveerd?

Het is in de code overigens ook op te lossen door i.p.v. Printf een andere functie te gebruiken om getallen in tekst om te zetten.

Menno schreef :
Hallo Menno,

Momenteel heb ik de volgende plugins actief: Dashboard, ChartDownloader, Launcher, MeteoVache, Grib, VDR,Dashboard_Tactics, DR, Watchdog, otcurrent, Race Start Display, OCPN Draw, GPS Odometer.

Het zou natuurlijk mooi zijn als je die bug kunt oplossen. Maar voor de goede orde: ik ben zelf geen programmeur maar slechts een goedbedoelende leek die pas sinds kort is overgestapt op Linux. Het wijzigen van functies en codes in plugins is iets dat voorlopig nog boven mijn pet gaat.

In mijn Linux-systeem stond de instelling voor "Numeric" op nl_NL.UTF-8. Sinds ik dat heb gewijzigd in en_US.UTF-8 loopt OpenCPN bij mij probleemloos. Ik weet eerlijk gezegd niet precies of ik nu wel of niet de PPA voor "bionic" heb.

Als dit jou iets zegt: mijn software sources zijn
Main(tricia) packages.linuxmint.com
Base (bionic) ftp://ftpserv.tudelft.nl/pub/Linux/archive.ubuntu.com

Vrgr, Roel

Ik kan het probleem zelf niet reproduceren, maar ik heb bij de Bug Report in Flyspray een mogelijke oplossing toegevoegd.

Menno schreef : Lijkt op het eerste gezicht niet verkeerd

Work around:
Ik zet mijn locale vaak op Ierland. Dan heb je wel de euro, maar geen komma probleem.

rooiedirk schreef :
En de koffie is daar véél lekkerder!

Is het niet een kwestie van de . en , functie omdraaien ? In Windows ben ik daar wel mee bekend dat een . en , in een getal in een andere taal, een heel ander weergave van een getal geeft,
, wordt dan gebruikt voor aan geven van duidzenden, . voor tienden enz.

Onlangs is er iets veranderd in een aantal functies in de gcc Compiler met name in printf functies e.d. Even zoeken op restrict type qualifier.

henkvd schreef :
Dat is inderdaad het probleem. In Linux kan je dat voor het hele systeem instellen d.m.v. de Locale omgevings-variabelen, in het geval van getallen LC_NUMERIC. Als je het systeem op Nederlands instelt wordt die variable nl_NL.

Een Nederlandse locale zorgt voor komma’s als decimaalscheidingsteken, de meeste Engelse locales gebruiken daarvoor een punt. Voor in de gebruikersinterface wil je de instellingen uit de locale gebruiken, maar voor databestanden wil je 1 standaard gebruiken, over het algemeen is dat hetzelfde formaat als programmeertalen gebruiken voor getallen: met een punt.

Voor sommige functies bestaat er een versie die gebruik maakt van de locale en een versie die de standaard van de programmeertaal gebruikt. In dit geval bijv. FromDouble (gebruikt locale) en FromCDouble (gebruikt het formaat van de C programmeertaal).

3Noreen schreef :
Ik heb erop gezocht, maar ik kan niks vinden wat hiermee te maken heeft.

Menno schreef :
Ik heb zelf even zitten kijken en het lukt mij ook niet om de fout te reproduceren (debian buster met bionic opencpn). Daarbij heb ik de launcher en meteovache niet kunnen inladen. Verder is het even op de laptop thuis, dus een GPS track aanmaken is lastig hier.

Zou Seanymph een aantal zaken kunnen testen?
(1) Ik kan zo een opencpn versie met de patch van Menno klaarstomen zodat je zijn patch kan testen. Als ik daarbij een oud versienummer gebruik wordt deze opencpn-versie bij de eerstvolgende update weer overschreven wordt door de originele, indien gewenst.

(2) Zou je de plugins een voor een weg kunnen gooien en kijken wanneer het probleem ophoud. Daarvoor zou ik wel eerst een backup (kopie) maken van ~/.opencpn en ~/.local. Als je die route gaat kan ik je wel voorzet geven wat je moet doen, welke commando's. Daar hoort eigenlijk nog een 2e test achteraan waarbij je dan alleen de verdachte plugins weggooid.

Als je daar geen zin in hebt heeft het weinig zin bovenstaande in detail uit te leggen.

Ik heb de patch even in github gezet, maar het zou wel fijn zijn dat deze getest is voor ik vraag deze in OpenCPN op te nemen. Optie (1) zou niet alteveel tijd moeten kosten. Optie (2) heb je meer tijd voor nodig.

reuver schreef :
Uiteraard wil op allerlei manieren proberen te helpen, maar sinds ik zelf met dat probleem kampte heb ik niet alleen in mijn systeem de Numeric van NL gewijzigd naar US-en, maar is ook zowel OpenCPN als Linux geupdate. Zoals ik momenteel werk heb ik dus geen enkel probleem en ik weet niet of het dan zin heeft om iets uit te testen.

Misschien handig als ik eerst eens mijn Numeric weer terugzet naar NL om te kijken of ik dan weer tegen dat probleem aanloop? Ga ik wel even eerst m'n routes en tracks enzo veilig stellen.

OK, Numeric teruggezet op NL en in OpenCPN (5.2.4) zo'n beetje alle plugins geïnstalleerd die er te installeren zijn. Diverse keren alles opnieuw opgestart maar OpenCPN blijft probleemloos draaien. Alle routes, tracks en waypoints precies hoe ze moeten zijn.

Ik vermoed dat bij de laatste update die bug er uit is gehaald. Zal handleiding weer aanpassen. Sorry voor de ophef.

Seanymph schreef :
Alleen maar fijn dat je niet alleen klaagt maar ook meedenkt.