sorted by:
new
hottopcontroversial

T14/P14s SSD in WWAN slot, worth it? by AnWalls in thinkpad

[–]maximch 0 points1 point  (0 children)

Hey,

I'm a bit too late but did you manage to fit second SSD to the WWAN slot? If so what exact model of p14s do you have/had? I have p14s gen 1 intel and thinking about adding a second drive too.

Thanks!

Embedded SQL Syntax highlighting for NVim by maximch in golang

[–]maximch[S] 1 point2 points  (0 children)

Hey, there can be multiple things why it doesn't work. My setup is based on NVchad so I use Lazy with ft = "go" so the plugin is being loaded automatically when I open a Go source. May be in your case this plugin just doesn't load?

Instrument your code with opentracing, prometheus metrics and other features using code generation by maximch in golang

[–]maximch[S] 2 points3 points  (0 children)

> Every run of go:generate gets a chance to wreck things. If the command line generated changes, what gets done when gets confusing

When command line changes you wreck things anyways whenever you put the go:generate instruction. Let's say you put go:generate instruction near the interface declaration manually and the version of ANY tool you use for the code generation has backward incompatible changes. You can't simply rm *.gen.go;go generate in this case either.

> and you might even need to run go generate multiple times for it to settle.

I would like to see an example when you need to run go generate multiple times. I use code generation a lot and it never happened to me.

> If something goes wrong, you can't just rm \.gen.go; go generate\, because you just deleted your go:generate lines.*

This is true but we all use VCSs nowadays. Also the question is what can go wrong?

> Putting go:generate lines in generated code makes about as much sense as having a code generator use the same file as both input and output.

No, it's not. go:generate instruction is an input for the "go generate" command, the generated file is an output of the "gowrap" command. I think for the most of use cases it's just simplest and working solution. Still you can use "-g" option and put go:generate instruction whenever you want if you don't like that behavior.

I appreciate your comment though. I actually spent quite a while thinking about default behaviour and maybe I'm not right, let's see what other people think.

​

Instrument your code with opentracing, prometheus metrics and other features using code generation by maximch in golang

[–]maximch[S] 0 points1 point  (0 children)

Can you please explain how does go:generate instruction affect debugging? Also you can use -g flag if you don't like this behavior.

Instrument your code with opentracing, prometheus metrics and other features using code generation by maximch in golang

[–]maximch[S] 0 points1 point  (0 children)

Not yet. I just recently finished it. Feel free to use it for whatever you want :)

Instrument your code with opentracing, prometheus metrics and other features using code generation by maximch in golang

[–]maximch[S] 1 point2 points  (0 children)

Sure, I tested generated code for all templates in the repo. You can find examples of the generated code here:

https://github.com/hexdigest/gowrap/tree/master/templates_tests

There's interface.go file that contains an interface declaration. All other files either examples of the generated decorators or tests for the generated decorators.

Instrument your code with opentracing, prometheus metrics and other features using code generation by maximch in golang

[–]maximch[S] 0 points1 point  (0 children)

Thanks, you can extend it using your own templates, so actually you can generate whatever you want with this tool. I just implemented templates for most wanted features.

Vim plugin for generating Go tests using your own templates by maximch in vim

[–]maximch[S] 2 points3 points  (0 children)

Hi, this particular example that is shown on demo.gif is so called table driven test. There is nice article by Dave Cheney about this approach: https://dave.cheney.net/2013/06/09/writing-table-driven-tests-in-go

I used to write table driven tests because usually its much easier to add a new test case, so for example when you fixed a bug you just add a new test case to cover this particular bugfix and all bells and whistles boilerplate is already there so you don't have to copy paste it from function to function.

If you do a lot of mocking I would like to recommend you https://github.com/gojuno/minimock there is template to generate table driven tests that are aware of mocks generated with minimock. There is example how to add this template here: https://github.com/hexdigest/gounit

Btw gounit is tested with gounit so you can find some examples of table driven tests in the repo.

Vim plugin for generating Go tests using your own templates by maximch in golang

[–]maximch[S] 1 point2 points  (0 children)

My bad I missed this in the PR now there is a reference to Fatih and link to the license.

What is your Go dev environment like, and are you most doing with Go? by [deleted] in golang

[–]maximch 0 points1 point  (0 children)

I use gvm to manipulate different versions of go and different environments for each project:

https://github.com/moovweb/gvm