Plky o JMRI

[sidlo]

Nezapomínám a nikdy jsem tvoje slova nerozporoval.
I tady platí dvě základní poučky, které nás učili ve škole:
1. Každý technický problém má řešení, když je dostatek času a prostředků.
2. Času a prostředků není nikdy dost.

[belgarat]

@sidlo: nechci se hadat, problem je v tomto:

nebo SW který nesplňuje standardy dnešních požadavků na UI a umí splnit i ty nejnáročnější požadavky na provoz

Nejde o DNESNI pozadavky. JMRI je psane hloupe dlouhodobe, bavime se o "standardech" ustavenych jeste pred rokem 2000. Trochu jde omluvit kod, ktery prezil od Java 1.1.8 (ackoliv nejde moc omluvit to ze ho nevyhodili ) ... ale minimalne od doby Java 1.3 uz je fakt hodne velky ulet suplovat garbage collector rucnim null-ovanim referenci apod.

Otazka je, zda software, ktery nedodrzuje zakladni principy technologii, ktere pouziva (a ted nemluvim o GUI!)...

umí splnit i ty nejnáročnější požadavky na provoz,

Update: chci tim rict, ze je nutne k tomu pristupovat ne jako k software pro rizeni kolejiste, ale jako k detske hracce. Muze se kdykoliv rozbit, udelat jakoukoliv "pakarnu" a na cim modernejsim HW se nasadi, tim hur. Odhaduji, ze kdyby to nekdo pustil na vice-procesorovem (ne vice-jadrovem, ale opravdu zvlast patice) stroji, dely by se zajimave veci.

[Brejla]

... Muze se kdykoliv rozbit, udelat jakoukoliv "pakarnu" a na cim modernejsim HW se nasadi, tim hur. Odhaduji, ze kdyby to nekdo pustil na vice-procesorovem (ne vice-jadrovem, ale opravdu zvlast patice) stroji, dely by se zajimave veci.

Chtěl bych vidět toho dobrodruha nebo spíš blázna, který by se tento kutilský produkt odvážil nainstalovat na nějaké moderní výkonné víceprocesorové stanici (maximálně možná tak na nějakém veteránovi těsně před smrtí). Tyto drahé víceprocesorové stanice s většinou nainstalovanými náročnými softwary si nikdo nedovolí zaplevelit podobnými udělátky a ohrozit tak jejich spolehlivý provoz. My tedy rozhodně ne
Takže tvoje řečnická otázka zůstane velmi pravděpodobně nezodpovězena...

[belgarat]

No hlavni potiz je v tom ze - byl jsem poucen, tak chytry nejsem - ze na x86_64 je cache pomerne konzistentni a to zejmena v ramci jednoho chipu. Hlouposti ktere JMRI panove provadeji s nesynchronizovanim dat kam pristupuje vic vlaken se prave na "obvyklem" hardwaru uspesne maskuji. Navic asi monitor-exit flushne vsechny cache. Akorat kdyz Hotspot obcas dobre (bez ironie) zoptimalizuje vysledny assembler a dojde k preusporadani operaci ...
Na RISC architekturach by tomu nestacil ani padak, jak rychle by sletel.

Edit: jo, jsem umanuty a paranoidni ...potiz je ze kdyz se nedodrzi specifikace, a pak "nekdo" vymysli nejake (bez ironie) vyborne vylepseni (HW, OS, JVM) ... tak se plati ucty.

Edit2: dost kecu, zkusim vylepsit aspon neco ... otazka je, jestli nehasim horici les kyblickem z piskoviste.

[sidlo]

Chtěl bych vidět toho dobrodruha nebo spíš blázna, který by se tento kutilský produkt odvážil nainstalovat na nějaké moderní výkonné víceprocesorové stanici

Tady s tebou souhlasím. Centrálu za pár tisíc Kč, která komunikuje s okolím rychlostí několik desítek kilobaud připojit k víceprocesorovému počítači v ceně řádově několik set tisíc Kč, tak to může napadnout pouze ne zcela duševně zdravého jedince. Něco takového by normálního člověka v životě nenapadlo.

[Brejla]

Chtěl bych vidět toho dobrodruha nebo spíš blázna, který by se tento kutilský produkt odvážil nainstalovat na nějaké moderní výkonné víceprocesorové stanici

Tady s tebou souhlasím. Centrálu za pár tisíc Kč, která komunikuje s okolím rychlostí několik desítek kilobaud připojit k víceprocesorovému počítači v ceně řádově několik set tisíc Kč, tak to může napadnout pouze ne zcela duševně zdravého jedince. Něco takového by normálního člověka v životě nenapadlo.

Centrálu v ceně několika tisíc stejně jako další periferie se nebojím připojit a běžně to děláme. Oni se totiž aktualizace instalují jinak dost blbě a stáhnout aktualizaci a poslat ji rovnou do centrály stanici nijak neublíží (ochrany jsou samozřejmostí). Ale nainstalovat na tuto stanici tu změť nelogicky uspořádaných znaků označovanou jako JMRI třeba jen na vyzkoušení, když nemám jistotu kde všude to co napáchá, se rozhodně neodvážím.
Toto byla jen reakce na Belgaratův námět (nebo spíš povzdech) vyzkoušet, jak by se případně to "DÍLO" mohlo chovat a jak je provedení toho testu asi pravděpodobné. Já ho rozhodně zkoušet ani používat nebudu.

[sidlo]

Toto byla jen reakce na Belgaratův námět (nebo spíš povzdech) vyzkoušet, jak by se případně to "DÍLO" mohlo chovat a jak je provedení toho testu asi pravděpodobné. Já ho rozhodně zkoušet ani používat nebudu.

Chtěl bych jenom připomenout že nikomu nevnucuji používat JMRI a současně nikomu nebráním aby používal stejný software jako má Brejla.

[belgarat]

Panove. Byl to recnicky povzdech. Co hrozi realneji je, jak jsem psal: kdyz se Hotspotu (nebo GraalVM) "podari" preusporadat kod (pricemz specifikace poskytuje pomerne velkou volnost), vznikne "nahodna chyba". Uz jsem takovych par videl, a "skvele" se lovi. Zalozit programovani na predpokladu "mne to funguje, tak to funguje" je blbost.
V pripade JMRI mi shodou okolnosti (nesnazil jsem se) vznikla hned pri startu null pointer exception, a ani s odkazem na konkretni paragrafy specifikace jsem nebyl s to autorovi vysvetlit, v cem je potiz. Pritom objektivne - mne padala NPE, jemu ne (to ze si spatne vylozim formalni popis a udelam chybu je bohuzel bezne, nejsem genius. V danem pripade ale experiment ukazal vysledek). V tom konkretnim se na tom podepsala hustota vypisu do logu (a tedy zpomaleni jednoho ze soutezicich vlaken).

[Brejla]

Toto byla jen reakce na Belgaratův námět (nebo spíš povzdech) vyzkoušet, jak by se případně to "DÍLO" mohlo chovat a jak je provedení toho testu asi pravděpodobné. Já ho rozhodně zkoušet ani používat nebudu.

Chtěl bych jenom připomenout že nikomu nevnucuji používat JMRI a současně nikomu nebráním aby používal stejný software jako má Brejla.

Díky za souhlas, ale zklamu tě. Náš software není běžně dostupný. Navíc pochybuji, že by ho někdo byl schopný nebo ochotný zaplatit

[sidlo]

Nezklamal jsi mě.
Řeči o kvalitě softwaru který není dostupný, řeči o kolejišti které nikdo neviděl, řeči o tajných přípravách modelů, ...
v kontrastu s kritikou reálného nasazení dostupného software, reálných kolejišť, reálných modelů, ...
to vše v podání jedné osoby
tak od těchto plků nemám žádné očekávání, tedy nenásleduje ani žádné zklamání.

[belgarat]

Jako vysoce pozitivni hodnotim v podstate encyklopedicke informace o schopnostech jednotlivych dekoderu, modelu a typu.

Bohuzel, i po zkusenostech NetBeans, JBuilderu a dalsich, panove verili tomu, ze lze udelat slusne generovane GUI. Lze, a jako rychly start je to vyborna vec; nemusi se programovat. Ale kdyz je generovane GUI jedina povolena volba ... one size fits all. Navic vypada, jak vypada:

* Divne misto na vrsku dialogu ? Nikoho nenapadlo ukotvit panely v hornim levem rohu
* Straaaasne dlouhy radek combo boxu ? Kdyz se jako volba pise cela veta, nestaci obrazovka. Mame tooltipy, ale neumime je pouzivat.
* Nezarovnane popisky, a ruzne dlouhe radky - ackoliv vytvareji dvojsloupec jmeno-hodnota ? Sice proti vsem doporucenim, ale "je to nase"
* Vysvetlujici popisky razene do sloupce, ale tvori tu zahlavi, tu pridavny (nezarovnany) sloupec, asi proto ze "to tak vyslo".
* Proc maji (desitkova) pole delena na cifry a uzivatel musi sestavovat z cifer radu vyslednou hodnotu ... coz znamena silene vysvetlivky - netusim. U bitovych poli to umeji lepe
* Ze zadny popisek nema podtrzene pismenko, a nemuzu pouzit Alt-znak je novy standard.
* Kdo by si myslel ze Ctrl+S ulozi, zapomente. Bylo mi vysvetleno, ze soubor neni dulezity, mam se divat na dialog jako obraz dekoderu (kdyz jej otevru ze seznamu a obsah se nacte ze souboru). Prima. Tak proc pri zavirani varuje, ze obsah neni ulozeny v souboru, a jestli chci, kdyz to neni dulezite.

Poznamka: u komplexnich dialogu se _doporucuje_ nazvy poli rovnat nalevo, protoze clovek co hleda "to co chce" muze hezky bezet odshora dolu po popiskach a nemusi hledat zacatky radku. Blbost, ale ergonomicka.

* Proc prvni sloupec zacina uprostred, a druhy nahore ? Aha, neumime pouzivat "anchor".
* Pravy sloupec - nez clovek najde v 8 textech to podstatne, cislovku KTERY vystup, chvili to trva. Pak uz vi, ze to dulezite neni na zacatku ("Function Output") ale uprostred a bez zvyrazneni.
* Kdyby se pouzil ramecek s titulkem "Function Output Behaviour", zacinaly by popisky tim dulezitym ... a nebyly by tak siroke
* Vsimate si velikanskeho rozbalovatka v pravem sloupci ? To proto, ze jedna z polozek obsahuje sahodlouhy popis, ktery ma byt v helpu nebo v tooltipu ... nebo se objevit jako vysvetlujici text pri vybrani.

A i proto, ze plytvame mistem na blbosti ma dialog cca 22 zalozek. Srovnejte s Train Controllerem

[Brejla]

Kdo to chce pochopit nebo spíše je schopen to pochopit, ten to pochopí. Přesvědčovat druhou skupinu je ztráta času, který lze využít mnohem efektivněji.

[belgarat]

Nevim zda bylo cilem 'presvedcovat'; spis ukazat ze v UI jsou zcela zbytecne chyby (nezarovnane, zbytecne texty, ...) i v ramci (taktez chybneho) konceptu, ze generovane UI je uzasne nejen pro specialisty (Sidlo) ale pro vsechny, a nic jineho neni treba.

Treba pro pripad sidla, a jeho 40 ruznych "scenaru" by bylo mnohem ucelnejsi zavest <group> sprazenou s combobox vybiratkem (resp. obecne hodnotou promenne 0..x) ... na panelu by se vybral scenar (vybiratko se 40 polozkami), a nasledne by se do zbytku zobrazil obsah one asociovane <group> (pripadny predchozi obsah se schova); nyni ma sidlo 40 panelu, ktere "otravuji" v titulku - stejne je najednou videt jen jeden scenar, tak proc je nemit alternujici ?

Je to trivialne udelatelne ... a je to ve fronte ...

[Kajinek11]

Zdravím své zkušenější kolegy. Pří běžném načítání CV z dekodéru ESU mi Decoder Pro (bez mého zásahu kamkoliv) přestal načítat s tím , že lokomotiva není rozpoznána. Po restartu PC i centrály Dr5000, výměně USB už jsem to nerozchodil. Zkoušel jsem všemožné kombinace, několik restartů, ale nic.. DR 5000 normálně čte a zapisuje CV, dává mi Loconet na COM8 ale Decoder Pro už se nehne.. Nevíte kde by mohla být chyba? PS: NA screenu je COM10 a červený, to už je jen z důvodu, že screen byl vytvořen po odpojení od centrály a zkoušel jsem ho na jiné USB, takže toho si nevšímejte.

[sidlo]

hledal bych chybu někde mezi centrála - ovladač - program

1. ve Windows ve správci zařízení by měly být COM porty pro DR5000 ve stavu normální funkčnost
2. ve správci zařízení si přečtu COMnnn na kterém běží LocoNet
3. po startu DecoderPro vyzkouším Zapnout/Vypnout centrálu, tím si ověřím že funguje spojení DR5000 -- DecoderPro