noder.LoadPackage Parsing noder.LoadPackage will call syntax.Parse to generate the syntax tree of all package files. Initialize a compile/internal/syntax.scanner Advance scanner to the next token. Start parsing. Check the package declaration first, and take the package name from the parsed pragma. Note that the parser is expecting a ; token, but this is automatically generated at the scanner, so users don’t have to write the ;. And parsing errors will not always abort the parser loop....

BuildToolchain BuildToolchain is initialized as noToolchain{} by default, then it’s set dynamically to gccgo or gc. Both implementations are wrappers around the binary toolchains installed on the machine. For gc, the delegations are as follows: BuildToolchain.gc - base.Tool("compile") BuildToolchain.cc - base.Tool("cgo"). Actually cgo has been executed before the compile and cfiles has been cleared, so BuildToolchain.cc should never be called and it always returns an error. BuildToolchain.asm - base.Tool("asm") BuildToolchain.pack - base....

Builder.build Builder.build generate an archive for a single package. Builder.build gets building information from two sources: internal/cfg package. It contains some global variables saving build flags. load.Package. It contains information for the current building package. Builder.build will build a need flag, finish the step and uncheck the finished bits one by one. Set up caching information by action, its package, and package’s target. Set up objects output directory. Setup cgo cache & vet cache....

Set Up the Environment vim-go doesn’t support travesal through the go source code, so I switch to vscode and it works out of box (with Go plugin && gopls installed). Start Point (go run) File: src/cmd/go/main.go Declaration: run.CmdRun Function: run.runRun Key data structures: build.Context work.Builder load.Package work.Action The runRun function will go through several stages: Check shouldUseOutsideModuleMode. This procedure is used by go run cmd@version work.BuildInit. This will setup the build context: Initialize modload module....

Sessions are important Security is an important factor of a reliable system, and from a user’s perspective, sessions are where the secure process starts. Sessions are no longer a volatile string saved in Redis/memcached, but a key to everything owned by users. Expiration time, login IP, login device, and many other properties of sessions should be tracked and managed properly. The importance of sessions makes the cache an improper choice: the nature of caching means you shouldn’t put anything important in it....

The design of Jetpack Compose makes an important assumption on the rendering process: the developer should not assume whether or not a composable will render, and how it will render. So any code inside a composable can be called by [0-N] times. That’s why Compose introduced several helpers to control the code execution of composable (instead of controlling the rendering process): remember makes a state persisted among recomposition. The state will be destroyed if the composable is removed from Composition....

Why Tailwind CSS is good? Recently, I picked up the frontend project at the current company. Compared with traditional MVC-style native development, the web development feels more natural to me: declarative, MVVM, state flow, etc. But if we compare the react/vue with SwiftUI/Jetpack Compose, there’s a key pain point: styling. With SwiftUI/Jetpack Compose, the styling is part of view declaration, which makes it easy to read and maintain. Traditionally, CSS & HTML are separated from each other, and there’re several practices to organize them....

Encountered this issue trying to compile a simple “Hello World” program with gcc-11 from homebrew. The compiler complained about fatal error: _stdio.h: No such file or directory. After some investigation, this was caused by wrong building configuration for gcc: $ gcc -v Using built-in specs. COLLECT_GCC=gcc-11 COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.2.0_3/libexec/gcc/aarch64-apple-darwin21/11/lto-wrapper Target: aarch64-apple-darwin21 Configured with: ../configure --prefix=/opt/homebrew/Cellar/gcc/11.2.0_3 --libdir=/opt/homebrew/Cellar/gcc/11.2.0_3/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin21 --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12....

Why use create-react-app Originally I was using a manually written webpack script to build my react project. The reason was to reduce the length of package-lock.json. But as I’m diving deeper into the frontend ecosystem, it doesn’t look like a good choice to wait for frontend guys fixing the dependency hell. So instead of waiting for a neat solution, I need to find a quick solution. As part of the lessons I learned from handwriting webpack scripts, it’s hard to build a complete and reusable scaffold to build a React....

The story of bash and my taste on command line I’ve been using bash as the development environment for a long time. The reason for choosing bash is its ubiquity. Most desktop & server Linux distributions and Docker images will ship with bash, which makes it a great fit for a configure-once-use-everywhere development environment. So you write it once and copy it to every host you’ll write code on. But since ~2014 my bash configuration has degraded several times, for two major reasons:...