Customizing Hide-Show for CMake Mode in Emacs
customizing HideShow mode on Emacs is done by hs-special-modes-alist. There are 4 parts (actually 5, but we care mostly about the 3) of the equation. You can customize it for your mode with a list like this
(MODE START END COMMENT-START FORWARD-SEXP-FUNC ADJUST-BEG-FUNC)
For example, the default definition of the hs-special-modes-alist
looks like this:
(defvar hs-special-modes-alist
(mapcar #'purecopy
'((c-mode "{" "}" "/[*/]" nil nil)
(c-ts-mode "{" "}" "/[*/]" nil nil)
(c++-mode "{" "}" "/[*/]" nil nil)
(c++-ts-mode "{" "}" "/[*/]" nil nil)
(bibtex-mode ("@\\S(*\\(\\s(\\)" 1))
(java-mode "{" "}" "/[*/]" nil nil)
(java-ts-mode "{" "}" "/[*/]" nil nil)
(js-mode "{" "}" "/[*/]" nil)
(js-ts-mode "{" "}" "/[*/]" nil)
(mhtml-mode "{\\|<[^/>]*?" "}\\|</[^/>]*[^/]>" "<!--" mhtml-forward nil)
;; Add more support here.
))
The ingredients
START
and END
regular expression
This regular expression matches the beginning/end of the folding code. For C/C++ alike languages, this is as brackets "{", "}", etc. For some language lacks of any brackets/parenthesis like python, it is more difficult. Emacs' built-in python mode provided patch to support it:
Event bus implementation
Recently I open sourced a small C++ library called eBus(Event Bus), it came along separated from another project I was working on. The idea, or should I say the interface was not very original, I took the inspiration from a much more complicated Event Buses In O3DE. The goal is simple, providing an easy to use Observer pattern so your can decouple the code from the callers to its callees.
Instead of doing this:
Modular Vulkan feature and extension manager
Recently I've been trying to squeeze a few hours at a time from my weekends to work on my Vulkan renderer projects. Because the extremely limited time I have, any feature I want need to planned well and get implemented in a few hours or I need to break it down to do so. One of such feature I've want to implement is a modular Vulkan Feature management.
Root Issue: hard-coding enabled features
When creating an Vulkan device, you have a lot of options which extensions you want to enable, which feature you want to enable. This is done by inserting features
into the pNext
chain and extensions into ppEnabledExtenionNames
.
Moving to literate Emacs configuration.
For a long time, I have been maintaining my emacs configuration through a folder of elisp files. I am quite happy about it and even have it working pretty well on Windows (unfortunately it's my work environment) with help my 3rdparty binaries repository. Finally I decided to move to literate configuration. It's a thing I wanted to do for a long time. Not because it's THE COOL things to do. I do think there is some advantages over my previous approach.
Comparing Vulkan and D3D12
Recently I wrote the PetitD3D12 to extend my graphics API knowledge to the land of DirectX, well I am surprised to see how similar those modern graphics APIs are. More precisely I think Vulkan is trying to stay close to D3D12 these days for be able to easily translate it. However there are also some noticeable differences, surprisingly I did not find too much “real” API comparison info, the Alain Galvan’s blog post are more just about grouping those API data structures together, not much you will know the difference in using them. With that being said, I am going to talk mostly in the shoes of a Vulkan developer who grabs the hand of D3D12 code to take a close look. Mainly I will cover about pipeline creation, descriptor binding and command execution.
Wayland client side window decorations through libdecor
I have been away from wayland system for a while because of work, but I still remember back in the day the pain to manage the window frame (as known as decorations) in wayland system. Surprisingly quite a lot of server work shifted to client side to manage, eg, you need to implement key repeat event in the client applications.
There are two ways right now to do the client decorations.
Moving towards GPU driven
We were using a traditional for_each
style drawing G-buffer and shadow in Vulkan, with over 2.5 million triangles, and 25,000+ objects, I started to see my GTX 1650 having hard time following it up. Although you can pre-record command buffers in Vulkan to reduce the CPU time but we will also end up with a very large command buffer to submit and potentially miss the driver optimizations with indirect draws. These days, GPUs are getting more and more powerful and complex, including tons of new features. It’s promising to draw millions or billions more triangles compared to before. The cost is that it changed the programming paradigm completely. If you want embark on new hardware, chances are you need to rewrite the rendering code.
Comparing Vulkan Frameworks
There are indeed many people tried to implement a rendering framework on top of Vulkan to reduce the amount of code to write. But so many of them merely just create a wrapper around existing Vulkan objects, like wrapping the command buffer with a vk::CommandBuffer::Ptr
and you still have to fill all the VkObjCreateInfos
.
The rendering framework focus on the render passes should provide a compact yet descriptive API to create render pass. Leaving the user out of the mess of managing/binding descriptors, uniform buffers. Have them focus on the shaders.
Moving to Hugo, Aftermath
My blog is now back online, with brand new render engine Hugo. The URLs are totally different though. Not sure how web crawlers handling it right now.
After the migration, I did a few extra work for patching the hiccups. Fix the build warnings and adding new features.
The about page
In every blog you always have some pages that you do not want it be inside the
blog list. By default Hugo will simply place everything on the “navigation
list”. Even if I place it outside the blog folder. This is the list your
template is calling .NextPage
and .PrevPage
. So initially I just give it a
very old date, or simply removed the date, so it will appear as the last on the
list. Obviously I will have to fix that.