diff options
8 files changed, 18 insertions, 18 deletions
diff --git a/source/00_content/articles/2013-10-06_notizen_zu_cpp_und_unicode.md b/source/00_content/articles/2013-10-06_notizen_zu_cpp_und_unicode.md index 0238df3..ef12969 100644 --- a/source/00_content/articles/2013-10-06_notizen_zu_cpp_und_unicode.md +++ b/source/00_content/articles/2013-10-06_notizen_zu_cpp_und_unicode.md @@ -20,7 +20,7 @@ Wir müssen in diesem Fall also auf externe Bibliotheken wie beispielweise [icon ## Ein UTF-8 Codepoint-Iterator in C++ -Um zumindest für rein lesende Zugriffe auf UTF-8 Strings nicht gleich eine Bibliothek wie Boost oder [easl](http://code.google.com/p/easl/) verwenden zu müssen habe ich einen einfachen UTF-8 Codepoint-Iterator anhand der Spezifikation in [RFC3629](http://tools.ietf.org/html/rfc3629) implementiert. Den Quellcode dieser Klasse stelle ich auf [Github](https://github.com/KnairdA/CodepointIterator) oder in [cgit](http://code.kummerlaender.eu/CodepointIterator/tree/) als Open Source unter der MIT-Lizenz zur freien Verfügung. +Um zumindest für rein lesende Zugriffe auf UTF-8 Strings nicht gleich eine Bibliothek wie Boost oder [easl](http://code.google.com/p/easl/) verwenden zu müssen habe ich einen einfachen UTF-8 Codepoint-Iterator anhand der Spezifikation in [RFC3629](http://tools.ietf.org/html/rfc3629) implementiert. Den Quellcode dieser Klasse stelle ich auf [Github](https://github.com/KnairdA/CodepointIterator) oder in [Gitea](http://code.kummerlaender.eu/adrian/CodepointIterator/) als Open Source unter der MIT-Lizenz zur freien Verfügung. UTF-8 enkodiert die aktuell maximal 21 Bit eines Unicode Code-Points in bis zu vier Code-Units mit einer Länge von je einem Byte. Die verbleibenden maximal 11 Bit werden dazu verwendet, Anfangs- und Fortsetzungs-Bytes eines Code-Points zu kennzeichnen und schon in der ersten Code-Unit zu definieren, in wie vielen Code-Units das aktuelle Symbol enkodiert ist. diff --git a/source/00_content/articles/2013-11-03_mapping_binary_structures_as_tuples_using_template_metaprogramming.md b/source/00_content/articles/2013-11-03_mapping_binary_structures_as_tuples_using_template_metaprogramming.md index e2b4784..f536e4b 100644 --- a/source/00_content/articles/2013-11-03_mapping_binary_structures_as_tuples_using_template_metaprogramming.md +++ b/source/00_content/articles/2013-11-03_mapping_binary_structures_as_tuples_using_template_metaprogramming.md @@ -251,4 +251,4 @@ which basically is _just_ a large library of templates. The next step in extending the templates explained in this article would probably be adapting the _BinaryMapping_ template to offer sliding window like iteration over larger buffers and extending the supported data types. -__Update:__ The current version of a small C++ template library extending the _BinaryMapping_ templates detailed in this article may be found on [Github](https://github.com/KnairdA/BinaryMapping/) or [cgit](http://code.kummerlaender.eu/BinaryMapping/). +__Update:__ The current version of a small C++ template library extending the _BinaryMapping_ templates detailed in this article may be found on [Github](https://github.com/KnairdA/BinaryMapping/). diff --git a/source/00_content/articles/2014-07-11_mapping_arrays_using_tuples_in_cpp11.md b/source/00_content/articles/2014-07-11_mapping_arrays_using_tuples_in_cpp11.md index 19bc030..c29de87 100644 --- a/source/00_content/articles/2014-07-11_mapping_arrays_using_tuples_in_cpp11.md +++ b/source/00_content/articles/2014-07-11_mapping_arrays_using_tuples_in_cpp11.md @@ -58,6 +58,6 @@ inline xalan::XalanDocument* callConstructDocument( As we can see a `IndexSequence` template specialization instance is passed to the variadic `callConstructDocument` method to expose the actual sequence values as `Index`. This method then resolves the `Index` parameter pack as both the array and `std::tuple` index inside the calls to the `valueGetter.get` template method which is called for every sequence element because of this. What this means is that we are now able to implement non-template `constructDocument` methods inside XSLT external function implementations such as [FunctionTransform](https://github.com/KnairdA/InputXSLT/blob/master/src/function/transform.h). The values passed to these methods are automatically extracted from the argument array and converted into their respective types as required. -While this article only provided a short overview of mapping arrays using tuples in C++11 one may view the full implementation on [Github](https://github.com/KnairdA/InputXSLT/blob/master/src/function/base.h) or [cgit](http://code.kummerlaender.eu/InputXSLT/tree/src/function/base.h). +While this article only provided a short overview of mapping arrays using tuples in C++11 one may view the full implementation on [Github](https://github.com/KnairdA/InputXSLT/blob/master/src/function/base.h) or [Gitea](http://code.kummerlaender.eu/XSLT/InputXSLT/src/branch/master/src/function/base.h). **Update:** The recently passed C++14 standard adds a [std::integer_sequence](http://en.cppreference.com/w/cpp/utility/integer_sequence) template to the standard library which covers the same use case as the custom `Sequence` and `IndexSequence` templates detailed in this article. `FunctionBase` was already [modified](https://github.com/KnairdA/InputXSLT/commit/b9d62d5ce1e3f92a8ab34239c6e4044ad57180df) accordingly as one should obviously rely on the standard's version of a integer sequence in the future. diff --git a/source/00_content/articles/2015-03-06_using_scheme_as_a_metaphor_for_template_metaprogramming.md b/source/00_content/articles/2015-03-06_using_scheme_as_a_metaphor_for_template_metaprogramming.md index cfc1673..6ab4f16 100644 --- a/source/00_content/articles/2015-03-06_using_scheme_as_a_metaphor_for_template_metaprogramming.md +++ b/source/00_content/articles/2015-03-06_using_scheme_as_a_metaphor_for_template_metaprogramming.md @@ -209,7 +209,7 @@ Both of these examples are certainly not what [TypeAsValue] might be used for in While the _Scheme_ metaphor for template metaprogramming in C++ certainly has its limits, especially in the area of anonymous functions, I think that this article as well as the actual implementation of [TypeAsValue] are proof that it holds up quite well in many circumstances. As stated in the introduction to this article I was very surprised how close template metaprogramming can feel to a _real_ functional programming language. -All listings in this article as well as the [TypeAsValue] library itself are freely available under the terms of the MIT license on [Github] and [cgit]. Feel free to check them out and contribute - I am especially interested in practical solutions to providing better partial function application support or even full compile time lambda expressions that do not require the whole library to be designed around this concept. +All listings in this article as well as the [TypeAsValue] library itself are freely available under the terms of the MIT license on [Github] and [Gitea]. Feel free to check them out and contribute - I am especially interested in practical solutions to providing better partial function application support or even full compile time lambda expressions that do not require the whole library to be designed around this concept. Finally I want to reference the [Boost MPL] library which supports everything and more than the solution described in this article without relying on any _modern_ language features such as variadic templates. All _non-experimental_ projects should probably use it instead of [TypeAsValue], not the least because of greater portability. @@ -226,7 +226,7 @@ Finally I want to reference the [Boost MPL] library which supports everything an [example applications]: https://github.com/KnairdA/TypeAsValue/tree/master/example [Boost MPL]: http://www.boost.org/doc/libs/1_57_0/libs/mpl/doc/index.html [Github]: https://github.com/KnairdA/TypeAsValue/ -[cgit]: http://code.kummerlaender.eu/TypeAsValue/ +[Gitea]: https://code.kummerlaender.eu/adrian/TypeAsValue/ [`std::integral_constant`]: http://en.cppreference.com/w/cpp/types/integral_constant [`std::bind`]: http://en.cppreference.com/w/cpp/utility/functional/bind diff --git a/source/00_content/articles/2016-02-21_notes_on_function_interposition_in_cpp.md b/source/00_content/articles/2016-02-21_notes_on_function_interposition_in_cpp.md index 7e8e040..9fb22df 100644 --- a/source/00_content/articles/2016-02-21_notes_on_function_interposition_in_cpp.md +++ b/source/00_content/articles/2016-02-21_notes_on_function_interposition_in_cpp.md @@ -14,7 +14,7 @@ This feature is what is commonly referred to as function interposition and is wh Function interposition is useful in various practical scenarios such as providing custom memory allocators as drop in replacements for the appropriate standard library functions as well as monitoring the function calls of a application as an additional debugging avenue. Furthermore `LD_PRELOAD`'s nature of replacing library functions with custom logic in a not necessarily obvious manner makes it a security risk which is why it is disabled for e.g. `setuid` applications. But even with this restriction it may be used as a foundation for userland rootkits - for instance one could hijack the library functions used to interface with the file system and change what certain applications see. Such shenanigans could then in turn be used to manipulate the source code of an application during compilation while continuing to display the unchanged source code to the user via her chosen text editor and file hashing tool. More information on this kind of attack can be obtained e.g. in the _31c3_ talk on [reproducible builds] which is where I was first confronted with this risk. -However the use case that led me to dive into this topic was to develop a tool to be dropped in front of any `LD_PRELOAD` supported program that would then monitor all relevant file system interactions and generate a nice summary of what was changed to be used for documentation purposes. The result of this undertaking is available on [Github] and [cgit]. +However the use case that led me to dive into this topic was to develop a tool to be dropped in front of any `LD_PRELOAD` supported program that would then monitor all relevant file system interactions and generate a nice summary of what was changed to be used for documentation purposes. The result of this undertaking is available on [Github] and [Gitea]. [reproducible builds]: https://media.ccc.de/v/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner @@ -147,8 +147,8 @@ Although this approach depends on interfacing with C code it can be reasonably a One should however expect to dive deeper into C library internals and debug lower level issues while actually wanting to implement higher level functionality. Furthermore we probably will not get away with just implementing an interposition of the function we are interested in but also other functions that depend on it in some fashion in some wrapped applications. Definitely exepect quite a few coredumps and deadlocks during development. -For a real world example of how function interposition using `LD_PRELOAD` and C++ may be used to build a small but hopefully useful application feel free to check out [_change_] on [Github] or [cgit]. +For a real world example of how function interposition using `LD_PRELOAD` and C++ may be used to build a small but hopefully useful application feel free to check out [_change_] on [Github] or [Gitea]. [_change_]: https://tree.kummerlaender.eu/projects/change/ [Github]: https://github.com/KnairdA/change/ -[cgit]: https://code.kummerlaender.eu/change/ +[Gitea]: https://code.kummerlaender.eu/adrian/change/ diff --git a/source/00_content/articles/2016-05-22_visualisierung_von_metriken_in_voronoi_diagrammen.md b/source/00_content/articles/2016-05-22_visualisierung_von_metriken_in_voronoi_diagrammen.md index accb083..10097ee 100644 --- a/source/00_content/articles/2016-05-22_visualisierung_von_metriken_in_voronoi_diagrammen.md +++ b/source/00_content/articles/2016-05-22_visualisierung_von_metriken_in_voronoi_diagrammen.md @@ -153,7 +153,7 @@ Die Punktmenge ist dabei die, welche in obigen Beispiel Diagrammen zu betrachten Zur Kennzeichnung der Referenzvektoren wird jeweils eine abgeschlossene Kugel unter der verwendeten Metrik mit Radius 5 gezogen. Dies hat den schönen Nebeneffekt, dass wir anhand der Form der Punktmarkierungen schon Rückschlüsse auf die zur Generierung verwendete Metrik ziehen können, da die Markierungen nur skalierte Versionen der Einheitskugel sind, welche wir im vorangehenden Abschnitt besprochen haben. -Der komplette Quellcode der aufgeführten Beispiele ist auf [Github] und [cgit] unter der MIT Lizenz frei verfügbar und kann so zur Generierung eigener Voronoi Diagramme herangezogen werden. +Der komplette Quellcode der aufgeführten Beispiele ist auf [Github] und [Gitea] unter der MIT Lizenz frei verfügbar und kann so zur Generierung eigener Voronoi Diagramme herangezogen werden. ## Minimalistische Generierung von Pixelgrafiken in C++ @@ -231,11 +231,11 @@ Hiermit sind wir am Ende meines ersten textuellen Ausflugs an die Schnittstelle Grundsätzlich finde ich Voronoi-Diagramme hilfreich, um eine visuelle Intuition für die Auswirkungen verschiedener Metriken zu gewinnen - gleichwohl diese in höheren Dimensionen schnell in ihrem Nutzen schwindet. Aber auch abgesehen vom praktischen Aspekten sind diese Diagramme eine schöne Möglichkeit in etwas anschaulicherem Kontext mit Mathematik zu spielen und schöne Bilder zu erzeugen. -Ansätze zum Ausbau der im Rahmen dieses Artikels entstandenen Programme - an dieser Stelle noch einmal der Hinweis auf die Quellen bei [Github] und [cgit] - sind verschiedene Metriken in einem Diagramm zu mischen oder zu gewichten sowie sich praktische Einsatzszenarien für Voronoi-Diagramme anzuschauen. Wenn die Grafiken beispielweise bei dem ein oder anderen meiner Leser die Erinnerung an Strukturen in der Natur wie Bienenwaben oder aufeinandertreffende Seifenblasen geweckt haben, dann liegt das daran, dass sich Prozesse dieser Art tatsächlich über Voronoi-Diagramme betrachten lassen. Der entsprechende [Wikipedia-Artikel] liefert hier als Abschluss eine Auflistung zahlreicher Anwendungsbeispiele. +Ansätze zum Ausbau der im Rahmen dieses Artikels entstandenen Programme - an dieser Stelle noch einmal der Hinweis auf die Quellen bei [Github] und [Gitea] - sind verschiedene Metriken in einem Diagramm zu mischen oder zu gewichten sowie sich praktische Einsatzszenarien für Voronoi-Diagramme anzuschauen. Wenn die Grafiken beispielweise bei dem ein oder anderen meiner Leser die Erinnerung an Strukturen in der Natur wie Bienenwaben oder aufeinandertreffende Seifenblasen geweckt haben, dann liegt das daran, dass sich Prozesse dieser Art tatsächlich über Voronoi-Diagramme betrachten lassen. Der entsprechende [Wikipedia-Artikel] liefert hier als Abschluss eine Auflistung zahlreicher Anwendungsbeispiele. [Github]: https://github.com/KnairdA/voronoi/ -[cgit]: https://code.kummerlaender.eu/voronoi/ +[Gitea]: https://code.kummerlaender.eu/adrian/voronoi/ [Cairo]: https://www.cairographics.org/ [Imagemagick]: http://www.imagemagick.org/ -[voronoi.sh]: https://code.kummerlaender.eu/voronoi/tree/voronoi.sh +[voronoi.sh]: http://code.kummerlaender.eu/adrian/voronoi/src/branch/master/voronoi.sh [Wikipedia-Artikel]: https://en.wikipedia.org/wiki/Voronoi_diagram diff --git a/source/00_content/articles/2017-01-20_tinkering_with_meta_tools.md b/source/00_content/articles/2017-01-20_tinkering_with_meta_tools.md index 4611a66..2347d48 100644 --- a/source/00_content/articles/2017-01-20_tinkering_with_meta_tools.md +++ b/source/00_content/articles/2017-01-20_tinkering_with_meta_tools.md @@ -13,7 +13,7 @@ When I stood before this decision nearly _half a lifetime ago_[^4] my choice fel  -Altough the 122 lines including comments that currently make up most of my _Vim_ [configuration](https://code.kummerlaender.eu/dotfiles/tree/vim/.vimrc) are not much by most standards I have invested quite some time in setting the editor up to my taste - not the least by writing my very [own color scheme](https://code.kummerlaender.eu/dotfiles/tree/vim/.vim/colors/akr.vim) to match the rest of my primary desktop environment. +Altough the 122 lines including comments that currently make up most of my _Vim_ [configuration](https://github.com/KnairdA/dotfiles/blob/master/vim/.vimrc) are not much by most standards I have invested quite some time in setting the editor up to my taste - not the least by writing my very [own color scheme](https://github.com/KnairdA/dotfiles/blob/master/vim/.vim/colors/akr.vim) to match the rest of my primary desktop environment. Over time I have [grown so accustomed](https://www.norfolkwinters.com/vim-creep/) to _Vim's_ keybindings that I now use them wherever possible including but not restricted to: my web browser, [PDF reader](https://pwmt.org/projects/zathura/), various IDEs, [image viewer](https://github.com/muennich/sxiv) and window manager of choice. @@ -36,7 +36,7 @@ I find it very useful to have a certain set of information available at all time [NixOS]: https://nixos.org/ [GuixSD]: https://www.gnu.org/software/guix/ [etckeeper]: https://github.com/joeyh/etckeeper -[dotfiles]: https://code.kummerlaender.eu/dotfiles/ +[dotfiles]: https://github.com/KnairdA/dotfiles/ [GNU stow]: https://www.gnu.org/software/stow/ [dict]: http://www.dict.org/links.html [passman]: https://github.com/dkellner/passman @@ -61,7 +61,7 @@ As one can see in the screeshot above the current browser setup I use to deal wi For now it is good enough and fullfills my primary use cases: Having access to most of my sources independent of network availability[^7], preventing the unpleasant situation of wanting to consult a vaguely remembered source only to find that it is not available anymore as well as full text search over all interesting pages I visited. Archiving the web ties into the last section of this article: note taking. While I write all my lecture notes and excercise sheet solutions using pen input on one of Microsoft's _Surface_[^8] devices I like to capture project and _research_ notes as well as general thoughts using a keyboard on my normal computer. -When taking notes as plain text I preferably want to do so using _Vim_ which rules out most of the already relatively [limited](http://tiddlywiki.com/) [selection](http://www.zim-wiki.org/) [of](http://strlen.com/treesheets/) open source desktop wiki software. After quite some time using [VimWiki] I currently use markdown files stored in a flat directory structure. Desktop integration is solved using a background Vim instance running in a _i3_ scratchpad as well as a _Rofi_ based [note selection dialog](https://code.kummerlaender.eu/dotfiles/tree/bin/rofi_wiki) that communicates with _Vim_ using remote commands. Advanced markdown features, syntax highlighting and conversion is based on [pandoc] integration plugins. +When taking notes as plain text I preferably want to do so using _Vim_ which rules out most of the already relatively [limited](http://tiddlywiki.com/) [selection](http://www.zim-wiki.org/) [of](http://strlen.com/treesheets/) open source desktop wiki software. After quite some time using [VimWiki] I currently use markdown files stored in a flat directory structure. Desktop integration is solved using a background Vim instance running in a _i3_ scratchpad as well as a _Rofi_ based [note selection dialog](https://github.com/KnairdA/dotfiles/blob/master/bin/rofi_wiki) that communicates with _Vim_ using remote commands. Advanced markdown features, syntax highlighting and conversion is based on [pandoc] integration plugins. In addition to that I also now and then play around with _Emacs'_ [Org-mode] which can probably fulfill most of my requirements but requires considerable upfront configuration efforts to make it work consistently with _Evil_ for _Vim-style_ usage. [Gopher]: https://en.wikipedia.org/wiki/Gopher_(protocol) @@ -69,7 +69,7 @@ In addition to that I also now and then play around with _Emacs'_ [Org-mode] whi [Pentadactyl]: http://5digits.org/pentadactyl/ [TreeStyleTabs]: https://github.com/piroor/treestyletab [ScrapBook X]: https://github.com/danny0838/firefox-scrapbook -[`.pentadactylrc`]: https://code.kummerlaender.eu/dotfiles/tree/pentadactyl/.pentadactylrc +[`.pentadactylrc`]: https://github.com/KnairdA/dotfiles/blob/master/pentadactyl/.pentadactylrc [WARC]: https://en.wikipedia.org/wiki/Web_ARChive [VimWiki]: http://vimwiki.github.io/ [pandoc]: http://pandoc.org diff --git a/source/00_content/articles/2018-06-23_nixos_gpu_assorted_topics.md b/source/00_content/articles/2018-06-23_nixos_gpu_assorted_topics.md index b7b2606..1b37465 100644 --- a/source/00_content/articles/2018-06-23_nixos_gpu_assorted_topics.md +++ b/source/00_content/articles/2018-06-23_nixos_gpu_assorted_topics.md @@ -64,7 +64,7 @@ Of course I was not satisfied merely porting my workflows onto a new superior di After getting settled in this new working environment I finally was out of distractions and moved on to my original wish of familiarizing myself with delegating non-graphical work to the GPU. The first presentable result of this undertaking is my minimalistic [fieldplay](https://anvaka.github.io/fieldplay/) clone [computicle](https://github.com/KnairdA/computicle). - + What computicle does is simulate many particles moving according to a vector field described by a function $f : \mathbb{R}^2 \to \mathbb{R}^2$ that is interpreted as a ordinary differential equation to be solved using classical Runge-Kutta methods. As this problem translates into many similiar calculations performed per particle without any communication to other particles it is an ideal candidate for massive parallelization using GLSL compute shaders on the GPU. @@ -148,7 +148,7 @@ window.render([&]() { One idea that I am currently toying with in respect to my future GPU-based projects is to abandon C++ as the host language and instead use a more flexible[^8] language such as Scheme or Haskell for generating the shader code and communicating with the GPU. This could work out well as the performance of CPU code doesn't matter as much when the bulk of the work is performed by shaders. At least this is the impression I got from my field visualization experiment - the CPU load was minimal independent of how many kiloparticles were simulated. - + [^0]: See [nixos_system](https://github.com/KnairdA/nixos_system) and [nixos_home](https://github.com/KnairdA/nixos_home) [^1]: See the [summary node](http://tree.kummerlaender.eu/projects/xslt/) or [Expanding XSLT using Xalan and C++](/article/expanding_xslt_using_xalan_and_cpp/) |