Command Pattern

Pattern Command refers to behavioral design patterns.

This is the pattern with which I sit longer than the rest, it is so simple that it is very complicated. But personally, I find the charm of self-learning in that you have all the time in the world to explore a specific issue from all angles.

So, in GoF, applicability is described rather concisely and clearly:
Encapsulates the request as an object, allowing you to configure (parameterize) clients with different requests, use queues, log requests and perform cancellation operations.

Now we implement a simple version of the command from the description:

 
string fakeTrumpsRequest = “SELECT * from Users where name beginsWith DonaldTrump”

We encapsulated the request in a string class object, it can configure clients, add commands to the queue, log, cancel (using the “Snapshot” pattern)

It seems to me that this is quite enough to implement SQL queries and the like, but then the implementation details begin, various applications, the code base of the pattern, the roles of the clients vary greatly, auxiliary classes are added.

The Math Part

The command pattern begins with the Command protocol, which contains a single execute() method. Next comes the Concrete Command and Receiver, QC implements the operation on the Receiver, describes the relationship between the Receiver and the action. Nothing is clear? Me too, but drove on. Client creates an instance of the Specific Command, associates it with the Receiver. Invoker – an object that implements the process of launching Command.

Now let’s try to figure out an example, let’s say we want to update myOS on myPhone, for this we launch the application myOS_Update!, in it we press the Update Now! Button, after 10 seconds the system will inform you of a successful update.

The Client in the example above is the application myOS_Update!, Invoker is the “Update Now!” button, it launches the Specific Command of the system update using the execute(), which refers to the Receiver – the daemon for updating the operating system.

Case Study

Let’s say the application UI is myOS_Update! so good that they decided to sell it as a separate product to provide an update interface for other operating systems. In this case, we will implement an application with support for extension through libraries, in the libraries there will be implementations of Specific Commands, Receivers, we will leave static/unchanged Invoker, Client, protocol Command.

Thus, there is no need to provide support for mutable code, since our code will remain unchanged, problems can arise only when implemented on the client side, due to errors in the code of their Concrete Commands and Receivers. Also, in such an implementation, there is no need to transfer the source code of the main application, that is, we encapsulated commands and UI interactions using the Command pattern.

References

https://refactoring.guru/design-patterns/command
https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Crosscompile for macOS on Ubuntu OSXCross CMake

In this note, I will describe the assembly of cross-platform C ++ applications for macOS on an Ubuntu build machine using CMake and osxcross.
First, install the osxcross toolchain:
https://github.com/tpoechtrager/osxcross
Installation takes place in 3 stages, loading dependencies: 

 
cd tools
./get_dependencies.sh

Download XCode.xip from the official Apple website, then download the SDK from Xcode: 

 
./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip

I hope you read the Xcode license agreement in the last step? Next, building the toolchain with the desired prefix: 

 
INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh

Now you can use osxcross from the prefix directory of the last step. Add a new build macro for CMake, write everything you need: 

 
if (OSXCROSS)
SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER o64-clang)
SET(CMAKE_CXX_COMPILER o64-clang++)
SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
SET(ENV{OSXCROSS_MP_INC} 1)
endif()

I did not succeed in dynamic linking, so we export the libraries statically: 

 
if (OSXCROSS)
add_library(FlameSteelCore STATIC ${SOURCE_FILES})
else()

Further, you may encounter the fact that you do not have the necessary libraries for osxcross, I encountered this when using SDL2. osxcross supports ready-made library packages – macports. For example, installing SDL2-mixer: 

 
osxcross-macports -v install libsdl2_mixer

After that, you can start assembling libraries / applications as usual in the cmake-make link, do not forget to register a static link of libraries if necessary.

Manual assembly of libraries

At the moment, I have encountered the problem of incorrect archiving of libraries during static linking, I get an error when building the final application: 

 
file was built for archive which is not the architecture being linked (x86_64)

Very similar to this ticket , I managed to implement workaround in as a result, the build completes correctly. Unzip the static library and build it again using the osxcross archiver: 

 
ar x ../libFlameSteelCore.a
rm ../libFlameSteelCore.a
x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o

Also, I personally consider one of the problems the lack of the ability to run macOS applications immediately on ubuntu (at least with a part of the functionality), of course there is a project darling , but support is poor for the time being.

References

https://github.com/tpoechtrager/osxcross

Crosscompile for Windows on Ubuntu MinGW CMake

In this article, I will describe the process of building libraries and applications for Windows using the MinGW32 toolchain on Ubuntu.
Install wine, mingw:


sudo apt-get install wine mingw-w64

After that, you can already build C / C ++ applications for Windows:


# C
i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
 
# C++
i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit

Collected exe can be checked with wine.

Next, consider the changes to the CMake assembly, the CMakeLists.txt file, add MinGW specific things to the assembly file:


if (MINGW32)
set(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
endif()

elseif (MINGW32)
add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
else()

// link with all dependencies
if (MINGW32)
target_link_libraries(
                        FlameSteelEngineGameToolkit.dll 
                        -static-libgcc
                        -static-libstdc++
                        SDL2 
                        SDL2_mixer 
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)

set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
        PREFIX ""
        SUFFIX ""
        LINK_FLAGS "-Wl,--add-stdcall-alias"
        POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
        # MinGW generates position-independent-code for DLL by default
)
else()

Build:


cmake -DMINGW32=1 .
make

The output will be dll or exe, depending on your build. You can look at the working example in the repository of the new Cube-Art-Project and its libraries:
https://gitlab.com/demensdeum/cube-art-project
https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL
https://gitlab.com/demensdeum/cube-art-project-bootstrap

References
https://arrayfire.com/cross-compile-to-windows-from-linux/

Simple Emscripten auto test with ChromeDriver

In this article, I will describe the implementation of running autotest for ChromeDriver of the Chrome browser, which runs the module autotest translated from C ++ using Emscripten, reads the console output and returns the result of the check.
First you need to install selenium, for python3-ubuntu this is done like this:


pip3 install selenium

Next, download ChromeDriver from the official site, put the chromedriver in / usr / local / bin for example, after which you can start implementing the autotest.
Below I will give the autotest code that launches the Chrome browser with the autotest page open on Emscripten, checks for the presence of the text “Window test succeded”:


import time
from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

capabilities = DesiredCapabilities.CHROME
capabilities['goog:loggingPrefs'] = { 'browser':'ALL' }
driver = webdriver.Chrome()
driver.get("http://localhost/windowInitializeTest/indexFullscreen.html")

time.sleep(2)

exitCode = 1

for entry in driver.get_log('browser'):
    if entry["source"] == "console-api":
        message = entry["message"]
        if "Window test succeded" in message:
            print("Test succeded")
            exitCode = 0

driver.close()
exit(exitCode)

Save the test as main.py and run python3 main.py

Building project with libraries Emscripten

In this article, I will describe the assembly of a project consisting of several libraries using Emscripten.
Emscripten does not currently support building shared libraries, so the first thing we do is translate all the libraries from Shared to Static. Emscripten works with its include files, so you need to solve the issue with the visibility of header files, I solved it by forwarding the symlink from the system directory to the Emscripten toolchain:


ln -s /usr/local/include/FlameSteelFramework $EMSDK/fastcomp/emscripten/system/include/FlameSteelFramework

If you use CMake, then you need to change SHARED-> STATIC in the CMakeLists.txt file of the add_library method. To build a library / application for further static linking, use the commands:


emcmake cmake .
emmake make

Next, you will need to build the main application indicating * .a library files at the linking stage. I could not indicate the relative path, the assembly completed correctly only after specifying the full paths in the CMakeLists.txt file:


elseif(EMSCRIPTEN)
target_link_libraries(${FSEGT_PROJECT_NAME} GL GLEW 
/home/demensdeum/Sources/cube-art-project-bootstrap/cube-art-project/sharedLib/libCubeArtProject.a 
/home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelEngineGameToolkitFSGL/libFlameSteelEngineGameToolkitFSGL.a 
/home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelEngineGameToolkit/libFlameSteelEngineGameToolkit.a 
/home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/libFlameSteelCore.a 
/home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/libFlameSteelBattleHorn.a 
/home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FSGL/libFSGL.a 
/home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/libFlameSteelCommonTraits.a)
else()

References

https://emscripten.org/docs/compiling/Building-Projects.html#using-libraries

Shared Library CMake C++

Recently I decided to make all parts of FlameSteelFramework separate shared libraries, then I will show an example of a CMakeLists.txt file for FlameSteelCore:


cmake_minimum_required(VERSION 3.5)

project (FlameSteelCore)
set(CMAKE_BUILD_TYPE Release)

include_directories(${CMAKE_CURRENT_SOURCE_DIR}/src)

file(GLOB_RECURSE SOURCE_FILES
    "src/FlameSteelCore/*.cpp"
)

add_library(FlameSteelCore SHARED ${SOURCE_FILES})

install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/FlameSteelCore"
        DESTINATION include/FlameSteelFramework
        FILES_MATCHING
        PATTERN "*.h"
)

install(TARGETS FlameSteelCore DESTINATION lib)

The commands that CMake executes are: it collects all files with the * .cpp extension from the src / FlameSteelCore / directory in the shared library, copies all readers with the * .h extension from src / FlameSteelCore to include / FlameSteelFramework (in my case it is / usr / local / include / FlameSteelFramework), copy shared lib to the lib directory (/ usr / local / lib)
After installation, it may be necessary to update the LD cache – sudo ldconfig.
To build and install on Ubuntu (if you have the correct build toolchain), just run the following commands:


cmake . && make && sudo make install

To check the installation process, I pass make prefix to the local makeInstallTestPlayground folder:


cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/demensdeum/makeInstallTestPlayground . && make && make install

References

https://stackoverflow.com/questions/17511496/how-to-create-a-shared-library-with-cmake
https://stackoverflow.com/questions/6003374/what-is-cmake-equivalent-of-configure-prefix-dir-make-all-install

Cling – C++ interpreter

Not so long ago I came across an interesting project called Cling , a C ++ language interpreter that can work interactively from the console as well. You can check project here: https://github.com/root-project/cling
The installation for Ubuntu is the simplest – download the archive for the version you need, unzip it, go to the bin folder and run cling in the terminal.
The following is an example of loading the FlameSteelCore library, initializing the object, listing id:

Webassembly lost exceptions and regex troubles

Lost exceptions

An interesting feature of Emscripten, when starting a game loop through emscripten_set_main_loop, remember that exception handling must be re-added via try catch directly in the loop method, as runtime loses the try catch block from the outside.
The easiest way is to display the error text using the browser using javascript alert:


            catch (const std::exception &exc)
            {
                const char *errorText = exc.what();
                cout << "Exception: " << errorText << "; Stop execution" << endl;

                EM_ASM_(
                {
                    var errorText = UTF8ToString($0);
                    alert(errorText);

                }, errorText);

                abort();

Too complicated regexp

The regex implementation in std may throw an error_complexity exception if it finds the regex too complex. This happens in the current emscripten implementation, so I suggest you implement tests for parsing through regular intervals, or use third-party regex implementations.