Skip to content

Blog

  • in Rust

Insert Code to Leetcode Generated Code

When I wrote leetcode in vscode with the plugin, I named generated leetcode file with format as[0-9]+(e.g, as123.rs) and put them under src. However, I have encountered some painpoints:

  1. The generated file isn't used by main.rs so the rust analyzer will ignore it, so I need to add mod as123; in main.rs every time.
  2. The generated code doesn't contain struct Soltuion definition so I need to add it every time.
  3. When I want to debug locally, I need to write the test function from scratch. It doesn't cost much but it's verbose.

These painpoints are trivial, but they're quite verbose. By using build script build.rs, I'm succeeded solving my painpoints!

Domain gopkg.in has a different V2 convention

Typically, a v2 go module path looks like github.com/xieyuschen/yaml/v3, however the gopkg.in has its own convention which is gopkg.in/yaml.v3.

Since gopkg.in shares the same version suffix methodology as Go modules, the Go command accepts the .v2 in gopkg.in/yaml.v2 as a valid major version suffix. This is a special case for compatibility with gopkg.in: modules hosted at other domains need a slash suffix like /v2.

Mapping Values by a Combination of Two Keys

The topic was found during optimization. When the combination of 2 string type keys maps to a value, how do you maintain the mapping from keys to the value? Generally we can come up with 3 approaches listed below, which one is better?

type Result string

// 1d map, you need to concatenate 2 strings
var d1M map[string]Result

// 1d map and use struct as key
type Key struct {
    S1, S2 string
}
var d1MS map[Key]Result

// 2d map
var d2M map[string]map[string]Result

How Go Finds Std Libs

Usually, the go standard library is located under $GOROOT and it's go compiler's scope to find the std libs, so most of the users needn't care about how the standard library is found by compiler.

When we want to combine 2 services into a single process, we need to solve the collision of global states between 2 services in the standard library. By duplicating it with another name(and all underlying dependent packages) under GOROOT, we can segregate the global states well even though they refer to the same package before combining. However, this requires to investigate how go compiler finds the std lib to ensure the approach won't break.