Témata

16

Windows a jiné systémy / Propojení domény s GMailem nebo Outlookem

« kdy: 19. 06. 2022, 20:26:27 »

Ahojte viem si nejako svoj email na vlastnej doméne (doménach) prepojiť s GMAILom (prípadne ďalšia možnosť outlook.com)? Obidve tieto služby majú fajn rozhrania. Pôvodne som mal na svojej VPS mail server axigen (nejakú free verziu), tá mi vyhovovala tiež nakoľko obsahovala aj webmail s krásnym rozhraním... Lenže po čase prestala fungovať.

Mám VPS s Windows Server 2019 (keďže väčšina webov mi beží pod .NETom) takže to bude asi komplikovanejšie ako s FreeBSD / Linuxom

Prosím vysvetlite mi základný princíp (alebo princípy) ako na to, detaily si už vygooglim sám. Vďaka

17

Vývoj / C++20x std::sregex_iterator - skrátený zápis for loop-u

« kdy: 10. 06. 2022, 22:22:02 »

ahojte C++ má syntaktický cukor ("foreach cyklus") pre prechádzanie objektov, ktoré obsahujú iterátor.

Kód: [Vybrat]

for (auto x : iterableObject)
{
}

každopádne ako doň prepísať toto:

Kód: [Vybrat]

auto linksBegin = std::sregex_iterator{ html.begin(), html.end(), linksRegex };
auto linksEnd = std::sregex_iterator{};

for (auto it = linksBegin; it != linksEnd; ++it) // dá sa tento riadok skrátiť?
{
	auto match = *it;
	if (match.size() > 2)
	{
		std::cout << match[2] << std::endl;
	}
}

18

Server / KRDC scaling na 150%

« kdy: 12. 11. 2021, 11:29:02 »

Ahojte nainštaloval som si do KDE Plasma aplikáciu KRDC, aby som sa mohol pripájať cez remote desktop (protokol RDP) na svoj VPS a managovať si ho (beží mi tam Windows Server 2019).

Každopádne všetko krásne funguje, len moj 4k monitor má jemnejší raster (4k na 32 palcov má mať natívne 150% scaling, ale KRDC používa 100%, v KDE mi normálne funguje 150% scaling len KRDC tento scaling nepreberá). Dá sa to nejako nastaviť, aby sa škálovalo na 150% (aspoň pri Full Screene), lebo takto je tam všetko strašne maličké. robiť sa s tým dá, ale oči si kaziť nechcem.

19

Vývoj / ESP IDF prerušovanie Wi-Fi pripojenia

« kdy: 23. 09. 2021, 22:39:19 »

Ahojte, neviem či mi tu bude vedieť niekto poradiť s mojim problémom, keďže je to dosť špecifickú vec... ale skúsim aj tu. Vyvýjal som aplikáciu pre ESP32, aplikácia obsahuje tento HTTP server https://github.com/fhessel/esp32_https_server (ktorý bol omnoho stabilneší ako bežne používaný AsyncWebServer) pôvodne som ju vyvýjal pod najrozšírenejším veľmi starým toolchainom obsahujúcom GCC 5.2 s chabou podporou C++ 17 a https://github.com/espressif/arduino-esp32 frameworkom (ale staršou verziou). Prekopal som to celé pod ESP IDF a s toolchainom obsahujúcim GCC 8.4 (s čiastočnou podporou C++ 20). arduino-esp32 je v novej verzii 4.x a pridal som ho do projektu ako IDF komponentu. Teraz je to viac customizovateľné a veľa vecí si viem nakonfigurovať cez idf.py menu konečne mám k dispozícii aj RTTI, ktoré som veľmi postrádal. Problém je, že čím viac možností konfigurácie mám, tým môže nastať viac problémov pri nesprávnej / neúplnej konfigurácii. Spustil som appku a funguje, ale pri refreshi stránky sa vždy preruší pripojenie (predtým pod starým toolchainom sa bežne neprerušovalo). Kým stránku nerefreshnem všetko ide ako má, websockety aj http requesty / resposny pracujú ako majú a spojenie je úplne stabilné. No pri refreshi to v konzole to vyzerá takto:

Kód: [Vybrat]

[HTTPS:E] An receive error occured, FID=57
[HTTPS:I] Connection closed. Socket FID=57
[HTTPS:I] Client closed connection, FID=60
[HTTPS:E] An receive error occured, FID=60
[HTTPS:I] Connection closed. Socket FID=60
[ 17058][I][WebsocketHandler.cpp:27] dumpFrame(): Fin: 1, OpCode: 8 (CLOSE), Mask: 1, Len: 2
[HTTPS:I] WS payload: length=2
[HTTPS:I] WS lost client, calling onClose, FID=-1
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40127b41  PS      : 0x00060b30  A0      : 0x80123f70  A1      : 0x3ffd7ff0

Vďaka prerušenému spojeniu sa žiaľ resetne celé zariadenie čo je neprípustné. Vygooglil som si túto diskusiu: https://github.com/fhessel/esp32_https_server/issues/85 vraj je problém v zlom Wifi pripojení.

1. Teraz neviem, či je to tým, že sa WiFi signál skutočne zhoršil (trošku som medzitým prestavoval pracovňu (kôli akvárku) a WiFi router som musel premiestniť na takú kovovú skrinku - a neviem či to nepohlcuje rádiové vlny)...

2. Alebo je problém v tom, že som ešte niečo cez to idf.py menu nenakonfiguroval úplne dobre. Sú tam stovky rôznych volieb... Každopádne viem, ktorý riadok v kóde to spôsobuje, otázka je či na to má vplyv konfigurácia WiFi pripojenia niekde v idf menu, alebo musím použiť to krkolomné riešenie, ktoré som si vygooglil https://github.com/fhessel/esp32_https_server/issues/85#issuecomment-724652455 ?

Aké voľby treba použiť v konfigurácii idf menu, možno sú niekde nejaké timeouty alebo čo ja viem čo? Aké voľby používate vy pri konfigurácii esp idf? Vďaka.

20

Desktop / KDE Plasma, ako nastavit 3 monitory s roznym DPI

« kdy: 20. 09. 2021, 20:58:28 »

Zatial som neinstaloval SK klavesnicu, tak sa ospravedlnujem ze pisem bez diakritiky.

Nainstaloval som si Arch Linux s KDE Plasma. KDE bezi cez kompozitor s renderovacim backendom cez OpenGL 3.1

Problem je ze mam 3 monitory ten stredny ma 4K rozlisenie na 32 palcov, tie dva po stranach maju full hd na 23 palcov ten 4K ma teda hustejsi raster (takze nativne skalovanie ma 150%). fullhdcka,  maju menej husty raster a nativne skalovanie 100%. Akurat v KDE v nastaveni monitora sa da nastavit skalovanie len pre vsetky 3 monitory naraz. Ako tento problem vyriesit? Skusal som nastroj XRandr ale vystup neni moc pekny. Niekde som sa docital ze by mohol pomoct wayland, takze som ho skusal nainstalovat, ale po odhlaseni a prihlaseni do KDE s waylandom system zamrzne. Pomoze len tvrdy reset.

21

Vývoj / CMake - ako zistiť typ compilera?

« kdy: 18. 09. 2021, 20:48:35 »

Ahojte, zapol som si farby vo výstupe z buildovania / linkovania, keďže ten štandartný výpis bez farieb je trošku neprehľadný a trvá mi chvíľku, kým sa v tom zorientujem (totiž kompilovanie pre vačšinu compilerov spúšťam priamo cez konzolu). Pre GCC som to zapol takto:

Kód: [Vybrat]

set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fdiagnostics-color")
set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fdiagnostics-color")

Lenže compilerov mám niekolko (Clang a GCC v linuxe) a (vo Windowse mám dokonca 2 CLangy, 3x GCC a k tomu niekoľko verzií MSVC a ešte nvidiácky NVCC). A potreboval by som ten farebný výpis zapnúť podľa použitého compilera, správnym parametrom. Ide mi len o CLANG a GCC, (MSVC nepotrebujem nakoľko ho nekompilujem cez konzolu, a vo Visualku je ten zoznam chýb, celkom prehľadný. A NVCC je len na Cuda. Takže v hre sú len GCC a CLANG. Lenže CLang používa trochu iný parameter, ako GCC... Tak som to riešil if-om:

Kód: [Vybrat]

if (CMAKE_GENERATOR STREQUAL "Ninja")
  if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fcolor-diagnostics")
    set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fcolor-diagnostics")
  endif ()
  if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fdiagnostics-color")
    set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fdiagnostics-color")
  endif ()
endif ()

Akurát CMAKE_CXX_COMPILER_ID obsahuje prázdny string. Myslím, že je to preto, že enviroment variables CC a CXX nemám v systéme zadefinované. Mám to takto schválne, kôli tomu, že mám v systéme veľa compilerov a keby som tie variables vyplnil musel by som to neustále prepisovať. Takto mi to deteguje automaticky podľa toho či použijem ninja, make, alebo generujem solutiony pre visualko a keď chcem iný compiler ako defaultný, tak ho zadám ako konzolový parameter. Existuje ešte nejaký spôsob ako v CMAKE zistiť verziu compilera, aj bez toho aby som mal vyplnené CC a CXX variables? Skúšal som aj "boolovské" CMAKE_COMPILER_IS_GNUCXX, ale tiež som tam nemal hodnotu.

22

Vývoj / C++ fmt.dev a flush

« kdy: 03. 09. 2021, 17:00:12 »

Ahojte ako v knižnici fmt.dev docielim aby sa mi pri printovaní textu, ten text aj hneď vložil na štandartný výstup? Keď urobím toto:

Kód: [Vybrat]

fmt::print("Connecting to WiFi ");
while (!wifi.is_connected_to_ap())
{
    fmt::print(".");
    vTaskDelay(250 / portTICK_PERIOD_MS);
}
fmt::print("\nThe device is connected.\n");

Text sa nevypisuje.

Keď to prepíšem do STL a pridám tam flush:

Kód: [Vybrat]

fmt::print("Connecting to WiFi ");
while (!wifi.is_connected_to_ap())
{
    std::cout << ".";
    std::cout.flush();
    vTaskDelay(250 / portTICK_PERIOD_MS);
}
fmt::print("\nThe device is connected.\n");

Tak sa loading normálne vypisuje. Má fmt libka niečo ako flush?

23

Hardware / Aký telefón s eSIM?

« kdy: 29. 08. 2021, 12:31:53 »

Ahojte chcel by som si kúpiť telefón s eSIM. Ktorý model by ste mi doporučili? Telefón by mal mať aspoň fullHD+ rozlíšenie (viac výhodou) 6 GB ram alebo viac a 64GB úložisko, alebo viac. Display by mohol mať cca 6,5 palcu. Taktiež batéria aspoň 5000mAh. Chcem len telefón s Androidom na iOS nie som zvyknutý. Doteraz som mal Blackberry potom, Xperie a niekoľko Xiaomi a teraz mám Samsung, ale a už ďalší Samsung nechcem, lebo ma sklamala veľmi slabá výdrž batérie (prakticky každý deň ho musím nabíjať) chcel by som telefón čo mi vydrží aspoň 2 - 4 dni na jedno nabitie. Na hry to nepotrebujem ale ak by to malo vyššiu frekvenciu displeja aspoň 90Hz tak by som nebol proti. Ale neni to podmienka.

Takže by som poprosil nejaké tipy na telefón s Androidom s eSim. Alebo ak máte nejaký zoznam telefónov s eSIM tak poprosím o odkaz. Pretože, tam kde som hľadal, v technických špecifikáciách eSIM nebolo uvedené a doslova každý model som si musel prelustrovať googlom.

Našiel som síce túto stránku https://esim2fly.com/esim-supported-devices/ kde sú uvedené telefóny s eSIM, ale nechce sa mi veriť že tento štandard podporuje len tak málo modelov.

24

Vývoj / C++ using v hlavičke šablóny

« kdy: 17. 08. 2021, 16:35:42 »

Ahojte, občas by som si chcel sprehladniť kód a zabrániť zbytočnému prepisovaniu rovnakého kódu a tak v C++ pomerne veľa používam typové aliasy. Problém je, že v hlavičke šablóny typový alias definovať nemôžem, alebo hej? Uvediem príklad kedy by sa mi hodil typový alias:

Kód: [Vybrat]

template <
	typename BeginRecordType,
	typename RecordType = BeginRecordType,
	typename ...Args
>
using _Table = Table<BeginRecordType, RecordType, Args...>; // už tu by sa mi hodilo definovať typový alias
class Table : public ranges::view_facade<_Table>
{
public:
	using QueryList = std::tuple<Args...>;
        // kod triedy...
}

To isté platí aj pre hlavičku template funkcie (alebo metódy), kde by sa mi zase hodil alias na skrátenie názvov typov v pri argumentoch funkcie. Ako tento problém riešiť? Existuje nejaké čisté riešenie (na úrovni jazyka?) alebo to mám nejako ohackovať preprocessorom?

25

Vývoj / C++ constexpr funkcia (prípadne metóda) vs inline funkcia

« kdy: 10. 08. 2021, 19:12:29 »

Je nejaký rozdiel medzi constexpr funkciou a inline funkciou? Alebo je to to isté? A ak je tak aký?

26

Vývoj / C++ Appendovanie parameter packs

« kdy: 07. 08. 2021, 01:17:16 »

Kód: [Vybrat]

template <typename... Args>
class PackClass
{
private:
    std::tuple<Args...> values;
public:
    PackClass(Args&& ...args) :
        values(args...)
    {

    }

    template <typename T>
    PackClass<Args..., T> Append(T value)
    {
        return PackClass<Args..., T>(/* riešenie problému */...);
    }
};

Dobrý deň prajem, chcel by som mať šablónu triedy, kde do konštruktora chcem mať možnosť nainjektovať argumenty hociakého typu. Tie argumenty, by sa niekam uložili v (mojom prípade je to tuple, ale kludne sa môžu uložiť hocikam inam) a po zavolaní metódy Append by sa vytvorila rovnaká trieda, do ktorej by sa cez konštruktor pridali uložené hodnoty a zároveň by sa k nim na koniec pridala ďalšia hodnota a spolu s hodnotou by sa dosadil ďalší typ medzi template parametre. Robím si fluent interface do ktrého chcem vkladať lambdy (std::function) rôznych typov a na záver ich všetky aplikovať na nejakú hodnotu, ale žiaľ robím to na platforme kde nemám k dispozícii RTTI* ani C++ 20 (mám len 17ku) takže musím sa trochu uskromniť. V mojom prídklade je problém na treťom riadku od spodu kde sa snažím dosadiť tuple, ale neviem ako ho skonvertovať na parametre konštruktoru a pridať tam ďalší paramter

27

Hardware / Ako to vidíte z budúcnosťou processorových architektúr?

« kdy: 01. 08. 2021, 11:26:36 »

CISC tu bude IMHO ešte hodne dlho, minimálne tam kde sa vyžaduje výkon - na desktopoch, herných počítačoch, konzolách, práci s multimédiámi a pracovných staniciach. Síce Intel zaspal na vavrínoch, ale naštastie AMDčko ťahá architektúru ďalej. Škodaže na trhu X86/AMD64 neni toľko hráčov ako v 80tych a 90tych rokoch (popri Inteli a AMD aj Cyrix a NexGen a IBM a NEC) tam kde chýba konkurencia, je bohužiaľ menšia dynamika vývoja.

ARM - RISC Architektúra veľmi šetrná ka životnému prostrediu. Pôvodne vznikla ako CPU pre domáce počítače. v 90tych rokoch ARMy dominovali PDA (StrongARM v Psion Series 5), PocketPC a Handledom, ale najvačšiu slávu získali po roku 2007 vďaka dotykovým mobilným zariadeniam, veľkú reklamu jej urobili Apple svojim iPhonom a Samsung či NVIDIA. Má omnoho lepší pomer cena výkon spotreba. Veľkí hráči ako NVIDIA, Microsoft, Apple, Samsung, Google čím ďalej tým viac presadzujú ARM. Momentálne ARMy vládnu, nie len mobilom, tabletom, set top boxom, IoT zariadeniam (Raspbarry PI, NVidia Jetson, Rock Pi) ale presadzujú sa aj v Laptopoch a čím ďalej tým viac majú potenciál dostať sa aj trh aj plnohodnotných výkonných desktopov a herných konzol. Okrem iOS a Androidu je už na ARMe doma aj Desktopový Linux, Windows 10/11, MacOS. mimochodom ako to dopadlo s kúpou ARMu NVIDI-ou?

RISC V - otvorená RISC architektúra, vraj má byť ešte šetrnejšia a ekonomickejšia ako ARM. Žiaľ zatiaľ je ešte len v plienkach a je veľmi málo rozšírená. Na trhu je zatiaľ len pár developer boardov (SiFive HiFive Unmatched, BeagleV) a dosť veľa microcontrollerov - pre IoT (ESP32-C3, ESP32-C6, Sipeed Maixduino AI, Huawei Hi3861, LoFive RISC-V). Intel po tom ako stráca pozície na trhu X86/AMD64 hľadá nové trhy a dokonca kúpil startup vyvýjajúci RISC V. Huawei vďaka Americkým sankciám (paradoxne aj napriek tomu že ARM je Britská firma) tiež poškuľuje po RISC V a možno sa okrem microcontrollerov raz dočkáme aj telefónu od s RISC V a Harmony OS. Otázka je či má zmysel venovať čas a energiu tejto architektúre, lebo vôbec neni jasné či sa presadí. Žiaľ trh zložený s ľudí a človek nie je "homo economicus" ktorý by si vyberal vždy objektívne najvýhodnejšie riešenie, takže nad rozšírením tejto architektúry zatiaľ visí veľký otáznik. No ekonomický intervencionizmus, sankcie a rôzne obchodné vojny by jej paradoxne mohli pomôcť.

28

Software / Crypto peňaženka na sporenie s časovým spínačom

« kdy: 27. 07. 2021, 22:00:44 »

Viete o nejakej crypto peňaženke na sporenie, ktorá by sa zablokovala na nejaký čas (ktorý si nastavím) a počas toho času by som si nevedel previesť crypto na inú adresu a po ubehnutí času by sa odblokovala? Peňaženka by mala podporovať bežné kryptomeny ako Bitcoin, Ethereum, Cardano, Monero, ZCash Polkadot a Solana, Uniswap, mohla by podporovať aj nejaké stable Coiny a tokeny ako napr PAXG, USDT atď

29

Vývoj / Konverzia std::functiohn na function pointer

« kdy: 21. 06. 2021, 19:00:23 »

Ahojte dá sa nejako skonvertovať?

Kód: [Vybrat]

using HttpCallback = std::function<void(HTTPRequest*, HTTPResponse*)>

Kód: [Vybrat]

using HttpCallbackPtr = void(*)(HTTPRequest*, HTTPResponse*)

Potreboval by som použiť lambdu na mieste kde sa dá použiť len klasická funkcia. Objavil som síce spôsob ako to skonvertovať cez std::function.target<>, ale ten by mal fungovať len so zapnutým RTTI, lenže zo zapnutým RTTI, mi zaser linker hádže chybu ako som uviedol v predchádzajúcom diskusnom threade: https://forum.root.cz/index.php?topic=24918.0

Takže by som potreboval buď rozbehnúť kompiláciu s RTTI, alebo nájsť iný spôsob ako skonvertovať std::function

Tuná je úrivok kódu:

Kód: [Vybrat]

using HttpCallbackPtr = void(*)(HTTPRequest*, HTTPResponse*);
using HttpCallback = std::function<void(HTTPRequest*, HTTPResponse*)>;

void registerRoutes()
{
    HttpCallback httpCallback = [](HTTPRequest* request, HTTPResponse* response) -> void {

    };

    auto callbackPtr = httpCallback.target<HttpCallbackPtr>();
    server->registerNode(new ResourceNode("/", "GET", *callbackPtr));

30

Vývoj / Problém pri linkovaní pri so zapnutým RTTI

« kdy: 21. 06. 2021, 18:36:26 »

Ahojte snažím sa skompilovať jednu appku ale v libke esp32_https_server je problém s kompiláciou resp. linkovaním ako zapnem rtti. Pri vypnutom RTTI kompilácia funguje, ale keď ho zapnem, tak mi to na konci linkovania hádže takúto chybu viď obrázok:

http://pluton.cloud/attachment/568dec82-140e-41db-afd0-08bfb42f9fe9/chyba-1.png

Kód: [Vybrat]

Linking .pio\build\az-delivery-devkit-v4\firmware.elf
.pio\build\az-delivery-devkit-v4\libac6\libesp32_https_server.a(WebsocketInputStreambuf.cpp.o):(.rodata._ZTIN11httpsserver23WebsocketInputStreambufE[typeinfo for httpsserver::WebsocketInputStreambuf]+0x8): undefined reference to `typeinfo for std::basic_streambuf<char, std::char_traits<char> >'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\az-delivery-devkit-v4\firmware.elf] Error 1

Chyba je niekde v tomto *.cpp súbore:

https://github.com/fhessel/esp32_https_server/blob/master/src/WebsocketInputStreambuf.cpp

A tu je k nemu hpp header file:

https://github.com/fhessel/esp32_https_server/blob/master/src/WebsocketInputStreambuf.h

Neviete ma nejako naviesť ako tento problém fixnúť? Potreboval by som mať zapnuté RTTI.