Win
grip: render Markdown as PDF
.. and other things, where you assumed it should be quite easy. ..
Wrote a short guide how to verify some information in Markdown. Local rendering works (most of the time via PyCharm or online at Github).
Now: how export it as PDF, because I realized that the receiver might not be able to display it properly.
* printing from PyCharm: failed
* VisualStudio-Plugin: no VS, no plugin
* any of the *nix-ways: not possible at that moment
* using a web-renderer: not allowed, because confidental data
UFF!
Python to the rescue!
|
1 2 |
pip install grip grip file.md |
Grip prepares a local flask server, where you receive a localhost:<randomport> url and just open it with the browser of your choice and then print as PDF.
žžžžžž
Two family members names sport a nice z with Caron: ž.
Win 10: ALT+0158 (number pad with numlock on)
Linux (unicode): CTRL+SHIFT+U+017E
Windows (10) doesn’t allow the same resource twice
So, the NAS* I use for years is separated into different partitions. Some for general access and things and one for music, which has a special user, which owns just read-only privileges.
Linux: no problem: mount as many shares with Gigolo and you are done.
Windows: use that 90s-style network-mount of the ‘explorer’ and add share by resource and credentials.
“\\ds213\musik” .. Works, but is awkward and not comfortable.
then you want to mount the second share with different credentials and you get “Can’t mount the same share** with different credentials”.
Workaround:
mount once by resource-name and once by ip: “\\192.168.178.178\musik”
Another approach via the hosts-file.
* DS213 from Synology: 2 bay; now running 24/7 for 5 (?) years; upgraded inbetween from 2 TByte drives to 4 TB with complete replication
** is actually “different shares at the same host”, but who am I with my limited knowledge?
Dell Precision 3351: performance spikes on GPU0 for dwm.exe/csrss.exe (win10)
Starting point: so, I have a brand-new laptop with a fresh Win10 and the apps lag while I move windows around the desktop. Great!
The first recommendations were already checked: Win is up to date; graphics driver for the integrated Intel GPU and for the Nvidia one as well. No, I won’t roll back the system and no, a “clean start” won’t fix this either.
Of course, I was also suspicious if the virusscanner or the dockingstation-three-monitor-setup is the issue. But come one: that are just 6 mio pixel and the hardware is top notch.
Mitigation:
0. open the “Dell Power Manager” and set the “Temperaturverwaltung” to “Optimiert” (before “Ruhig”)
1. configure via the Nvidia that their GPU shall be the preferred one for apps: “Grundprofil” = “Hochleistungs-GPU”; check as well if any app has preset the integrated GPU (change this!)
2. disable automatic scaling of applications: System > Display. Under the scaling drop-down, select the Advanced scaling settings link. Disable “fix blurry ..”
3. change the display settings to Performance: run “sysdm.cpl” and then “Advanced (Erweitert)” > “Performance (Leistung)” and then put everything to performance (radio button) and just enable “smooth font rendering”
4. change the graphic settings to “High Performance” for all “classic” and “universal” apps:
Problem is, that the dwm.exe and the csrss.exe use GPU0 no matter what you configure.
Note:
The idea to disable the integrated Intel GPU via UEFI/BIOS is not possible, because the Nvidia GPU is not a full replacement card, but relies on the iGPU ..
Windows: time measurement
StackOverflow has a ton of solutions with PowerShell and other external tools, but _I_ could no install something additional on that system. Nor had PS.
Works around the issue that the time is evaluated at start for each item, as well:
λ cmd /v:on /c "echo !time! & YOURCOMMAND & echo !time!"
Hint: also run cmake with just one core
λ cmd /v:on /c "echo !time! & cmake --build build\CMake\Debug\build -j1 --target all & echo !time!"
tutorial: include-what-you-use for a cmake/mingw-build on win
tl;dr:
0. Get the latest prebuilt version for Win: version 0.8 (3 years old :/)
1. Put this somewhere into you CMakeLists.txt
set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE "C:\\include-what-you-use\\bin\\include-what-you-use.exe")
2. Enjoy the overflowing build-output for your legacy-project.
Win 10: uptime with Powershell
(I don’t care about output from the taskmanager or whatever logs. I need a processable duration without much tinkering.)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Windows PowerShell Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. PS C:\WINDOWS\system32> (get-date) - (gcim Win32_OperatingSystem).LastBootUpTime Days : 15 Hours : 3 Minutes : 25 Seconds : 57 Milliseconds : 956 Ticks : 13083579564019 TotalDays : 15,1430319027998 TotalHours : 363,432765667194 TotalMinutes : 21805,9659400317 TotalSeconds : 1308357,9564019 TotalMilliseconds : 1308357956,4019 |
Localisations
The Qt framework offers a quite nice and convenient way to localize your application.
Not only how to mark inside the code translateable strings (tr(..)), but also that the translation-mappings are human-readable xml-format files (*.ts), but also their own tool to do the translation (Linguist). Linguist is quite helpful for translator who sometimes also have to have a look at the “what would you get with that translation of different size inside the widget”-result (more or less: WYSIWYG).
Noticed today some flaws in the localisation of MTuner (nice memory profiler) and offered some help.
This is what I love about OSS: you don’t just take, but can also lend a helping hand and improve the quality 🙂
QtCreator: add online-help if the SDK is not coming from an official package
challenge:
having some Qt-SDK without help files. Using help inside a browser is possible, but cumbersome. and local help would be nice for quick parameter-checks.
solution (edited):
Found also the official docu at: http://download.qt-project.org/online/qtsdkrepository/windows_x86/desktop/qt5_5121_src_doc_examples/qt.qt5.5121.doc/ as 7z-archive.
Then add it via QtCreator > Tools > Options > Help > Documentation > “add the QCH files”.
Three ways to find the location of a certain DLL at Windows
Common problem: just using the current working directory is not sufficient, because especially for unit-tests started from the Visual Studio-testrunner the opriginal, relative path is not fitting anymore. Fallback would be check an environment variable , which is set during installation or using the WinAPI (ugh).
versioned code can be found at: github/cppcCollection
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 |
// +++ ATTENTION! +++ // This is just a snippet to show how to get the path for a certain DLL on the Windows-platform. // First absed on the "current working directory", then the environment variable "PATH", then via WinAPI-call. // Of course, this does not work for any other OS. Nor is this epxected to survive any Windows-makeover (or patch set :X) // +++ ATTENTION! +++ #if defined(Q_OS_WIN) || defined(Q_OS_CYGWIN) // for the plugin-path #include <windows.h> #include <libloaderapi.h> #endif bool properSdkPath(QString const path) { #if defined(Q_OS_WIN) || defined(Q_OS_CYGWIN) // Check for the existance of a very, very, very important DLL. return QFileInfo(path + "/SDK.dll").exists(); #endif #ifdef Q_OS_MAC // macOS has SDK-support, so using the current application-path is sufficient return true; #endif } // Return the path to the hardware-plugins. // First check is based on the current working directory. // If this fails, check the contents of the environment-variable 'PATH' (set at install time). // If this fails, then check via Win-API. QString getPluginPath() { QString pathToSDK; // Try first the current working directory pathToSDK = QCoreApplication::applicationDirPath(); #if defined(Q_OS_WIN) || defined(Q_OS_CYGWIN) // If this failed (has no SDK.dll), indagnate the PATH environment variable. // Which is set during installation. if(!properSdkPath(pathToSDK)) { // Get the directory from the PATH (is set during APPLICATION SDK installation). auto const path = QString::fromLocal8Bit(qgetenv("PATH")); auto const splitPath = path.split(";", QString::SkipEmptyParts); for(auto const& item : splitPath) { if(item.contains("APPLICATION SDK")) { pathToSDK = QFileInfo(item).absoluteFilePath(); break; } } // If even this failed, then fall back to GetModuleFileName (happens with VS-testrunner). if(!properSdkPath(pathToSDK)) { // get the handle of the DLL HMODULE handleModule = GetModuleHandleA("SDK.dll"); LPWSTR modulePath = nullptr; DWORD bufLen = 4096; // reserve enough memory if(!(modulePath = (TCHAR*)malloc(sizeof(TCHAR) * (size_t)bufLen))) { TRACE_INFO("Could not allocate 4 KB memory. Please consider an hardware upgrade.") } // retrieve the path DWORD pathSize = 4096; pathSize = GetModuleFileName(handleModule, modulePath, pathSize); if(pathSize) { QString outputPath = QString::fromWCharArray(modulePath, static_cast<int>(pathSize)); pathToSDK = outputPath.replace("SDK.dll", ""); } else { TRACE_INFO("GetModuleFileName failed:" << GetLastError()); } } } #endif if(!properSdkPath(pathToSDK)) { TRACE_INFO("Could not determine proper plugin-path."); pathToSDK.clear(); // reset } // convert to proper separators and append the suffix for the plugin-location QString const hardwarePluginPath = QFileInfo(pathToSDK).filePath() + "/Plugins"; return hardwarePluginPath; } |