rliebz
Repos
50
Followers
31

The modern task runner

218
18

Name comparison in python

51
3

A highly opinionated CLI library in Go

1
1

Events

issue comment
proposal: log/slog: structured, leveled logging

As a third-party package author, I would like guidance on the where to get my logger from.

Speaking for myself, I generally use the context if one is passed down, HTTP request handlers being the prime example. It's also fine to add it to a struct that the package exports. For packages that have both, I would think about whether I want common attributes to be part of the dynamic call chain, or associated with the struct value.

For application authors who leverage contexts, I think the difference in quality of life between third-party packages that do vs. don't leverage contexts is significant enough to warrant an endorsement in the documentation.

The obvious example is for tracing—any third-party library that uses a context to log will become part of the trace, and any log without the context will not. And even if folks remember to call .WithContext, it's not necessarily clear at this point what context-scoped modifications will be occurring for context-stored loggers.

It also seems application authors should as a precaution always use slog.SetDefault even if they plan on exclusively passing the logger through the context, because if it's unclear how third-party package authors will be logging, a prudent application author has to support the global default logger. Because while it's almost certainly more correct to use a context-passed logger or a struct-scoped logger than the global one as a third party, that may not be universally understood to be true if the slog docs don't suggest it.

If there's an explicit recommendation for third-party packages in the docs on supporting contexts and where to pull the logger from, then those concerns go away. Third party packages can be understood to implement that contract by default, and deviations from that become bugs worth fixing.

Created at 1 week ago

Use sane colors for CSV highlighting

Bump treesitter highlights

Don't check for lua third parties

Created at 1 week ago
rliebz create tag v0.4.0
Created at 2 weeks ago
pull request closed
Prune the deprecated/discouraged parts of the API

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

Also swap golangci-lint to a YAML config, because the TOML config doesn't seem to be parsing anymore.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Created at 2 weeks ago
delete branch
rliebz delete branch shrink-interface
Created at 2 weeks ago

Prune the deprecated/discouraged parts of the API (#10)

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

Also swap golangci-lint to a YAML config, because the TOML config doesn't seem to be parsing anymore.

Signed-off-by: Rob Liebowitz rliebowitz@morningconsult.com

Signed-off-by: Rob Liebowitz rliebowitz@morningconsult.com

Created at 2 weeks ago
opened issue
sprintf deprecation warning

I recently encountered the issue described in #66 after updating Xcode, and updating this library has restored the original functionality. After the update to pg_query_go v2.2.0, the original functionality has been restored, but I continue to get warnings:

# github.com/pganalyze/pg_query_go/v2/parser
src_port_snprintf.c:1030:11: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use
 snprintf(3) instead. [-Wdeprecated-declarations]
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
src_port_snprintf.c:1212:13: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use
 snprintf(3) instead. [-Wdeprecated-declarations]
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
src_port_snprintf.c:1219:13: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use
 snprintf(3) instead. [-Wdeprecated-declarations]
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'

Seems to point to a few calls to sprintf that presumably should be replaced with snprintf, for example: https://github.com/pganalyze/pg_query_go/blob/920eb98a2b57c0631edecda018671be92fec63fb/parser/src_port_snprintf.c#L1030

For context, this is when running https://github.com/kyleconroy/sqlc, but looks like the warnings are stemming from here.

Created at 3 weeks ago

Prune the deprecated/discouraged parts of the API

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

Also swap golangci-lint to a YAML config, because the TOML config doesn't seem to be parsing anymore.

Signed-off-by: Rob Liebowitz rliebowitz@morningconsult.com

Created at 1 month ago

Prune the deprecated/discouraged parts of the API

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

Also swap golangci-lint to a YAML config, because the TOML config doesn't seem to be parsing anymore.

Signed-off-by: Rob Liebowitz rliebowitz@morningconsult.com

Created at 1 month ago

Prune the deprecated/discouraged parts of the API

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

Also swap golangci-lint to a YAML config, because the TOML config doesn't seem to be parsing anymore.

Signed-off-by: Rob Liebowitz rliebowitz@morningconsult.com

Created at 1 month ago

Prune the deprecated/discouraged parts of the API

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

Also swap golangci-lint to a YAML config, because the TOML config doesn't seem to be parsing anymore.

Signed-off-by: Rob Liebowitz rliebowitz@morningconsult.com

Created at 1 month ago
pull request opened
Prune the deprecated/discouraged parts of the API

The old StatusError and related types were formally deprecated a while back. There should be roughly zero actively maintained code still using it, so now is as good a time as any to rip off that bandage.

While StackErr was not formally deprecated, the documented best practices suggest that the type itself should never be directly referenced. Since that's the case, we shift to a unexported type and remove that as well.

Finally, and this is something that could surely be up for debate, I found the default stack trace format to be incredible dense and hard to read, so I added one that resembles the output format of panic and matches zap's default stack tracing format.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Created at 1 month ago

Disable smartindent

Created at 1 month ago

Improve window swapping behavior

This corrects two major issues:

  1. The "current" file was determined in the job's on_exit callback. This can be incorrect if the window has changed, so instead we record it when coverage is launched.
  2. Line length was determined using the current buffer, rather than the original window.

This does't fix things if the buffer changes in the window, which is still awkwardly handled, but it should handle callbacks correctly regardless of window.

Clean up function signatures

Created at 1 month ago

Update treesitter highlight groups

Remove deprecated cmp function call

Created at 1 month ago

Fix gitsigns navigation

Created at 1 month ago

Always highlight current window

Created at 1 month ago

Fix extra enter keypress in keymap

Update nvim config for 0.8.0

The two primary changes are indexing on commands and swapping off vim.opt for non-lists and non-maps. Also simplifies cursor restore logic and colorscheme declaration based on other things I figured out while putting this together.

Created at 1 month ago
issue comment
readOnly and writeOnly required properties incorrectly validated in examples

Looks like a known issue: https://github.com/stoplightio/spectral/issues/1274

Created at 2 months ago

Officially endorse installation with Go

Created at 2 months ago

Brew formula update for tusk version v0.6.4

Created at 2 months ago
create tag
rliebz create tag v0.6.4
Created at 2 months ago

Bump changelog for release

Created at 2 months ago

Improve bash colon handling

Fix linter errors

Created at 2 months ago

Rework plugin/tool installation

Add lsp signature

Created at 2 months ago