| LIBRARY WRITING REFERENCE LIST | |
| =============================== | |
| 1.) Designing and Evaluating Reusable Components (Casey Muratori: http://mollyrocket.com/casey/stream_0028.html) | |
| ---------------------------------------------------------------------------------------------------------------- | |
| _THE_ reference on API design up to this day on the internet. Nobody should write a library without having seen this. | |
| I come back to this talk every N number of weeks it is that good. | |
| 2.) stb_howto (Sean Barrett: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt) | |
| -------------------------------------------------------------------------------------------- | |
| Sean Barretts single header libraries (https://github.com/nothings/stb) was the first time for me that I came across |
| syntax enable | |
| colorscheme xcode-dark | |
| " attempt to fix issue | |
| " :95;0c is already typed on starting vim (not nvim) | |
| set t_u7= | |
| set t_SH= | |
| " no need to press shift to enter command mode | |
| noremap ; : |
| #!/bin/bash | |
| interfaces=( $(netstat -in | egrep 'utun\d .*\d+\.\d+\.\d+\.\d+' | cut -d ' ' -f 1) ) | |
| rulefile="rules.tmp" | |
| echo "" > $rulefile | |
| sudo pfctl -a com.apple/tun -F nat | |
| for i in "${interfaces[@]}" | |
| do | |
| RULE="nat on ${i} proto {tcp, udp, icmp} from 192.168.64.0/24 to any -> ${i}" | |
| echo $RULE >> $rulefile | |
| done |
I am currently dealing with a lot of libraries at work. Both third party as well as libraries written or being currently in process of being written by me. I absolutely love writing and working with libraries. Especially if they present or bring me to either a new or different approach to solve a problem. Or at least provide a different view.
Over time I noticed however that quite regulary we had to decide that we cannot use a third party library. Often it is the usual reason.
Before you continue, if you don't know what IMGUI is don't bother reading this post, just ignore it, don't write anything in comments section, etc. If you're curious about IMGUI see bottom of this post, otherwise continue whatever you were doing, this post it's not for you. Thanks!
If you know what IMGUI is, for context read following presentations and blog posts:
For the last few weeks I spend some time coding, writing and cleaning up my notes from almost a year since I published nuklear.
Basically this is a possible implementation for a graphical user interface builder backend with support for an immediate mode style API. So it provides a way to define non-mutating UI state, an immediate mode style API for dynamic UI components (lists,trees,...) and a combination of both.
The core implementation is ~800 LOC without any kind of default widgets or extensions. At first this seems quite counter intuitive. However since the inherent design allows for lots of different ways to define any widget like buttons it does not make sense to provide a specific default implementation. The way this code was architectured furthermore removes the need for style/skinning configurations used in Nuklear since widget painting is just calling a small
Where you able to produce a binary directly from the Rust build tools that you could submit to the app/play store?
Not quite, but I tried to get as close to that as was reasonably possible. Alas, things ended up a little convoluted.
For iOS, I have a nearly empty Xcode project with a build script that copies my cargo produced executable into the .app that Xcode generates (before Xcode signs it). The build script also uses lipo to merge the executables for each architecture I’m targeting (e.g. armv7 and aarch64 for non-simulator devices) into a single, universal binary.
On top of that, there are various iOS-y things that need to happen before my application’s main method is called. SDL2 provides the Objective-C code that does all of that. In a C or C++ game, SDL2 renames main to SDL_main, and then [inserts its own mai
This is the second entry in my series about API design. While I wrote about granularity and request based APIs in my last post I want to write about API design and code architecture for modular data-oriented process this time. This is basically the write up of my findings while writing and finishing the core of my current GUI research quarks.
Actually sparking my interest for writing up my findings however was rasmusbarr@github (rasmusbarr@twitter) releasing his small data-oriented and SIMD-optimized 3D rigid body physics library. I noticed a lot of overlap in design between his physics and my GUI library and wanted to write up some general thoughts about what seems
| To invoke the generator from the cmake target you should define a helper macro in you project root's "fips-include.cmake" file: | |
| macro(copy_files yml_file) | |
| fips_generate(FROM ${yml_file} | |
| TYPE filecopy | |
| OUT_OF_SOURCE | |
| ARGS "{ deploy_dir: \"${FIPS_PROJECT_DEPLOY_DIR}\" }") | |
| endmacro() | |
| In your cmake target definition you would then use this like: |
| SPC | |
| SPC: find file | |
| , switch buffer | |
| . browse files | |
| : MX | |
| ; EX | |
| < switch buffer | |
| ` eval | |
| u universal arg | |
| x pop up scratch |
