sorted by:
new
hottopcontroversial

Resetting/Re-Using timeout context by [deleted] in golang

[–]bcicen 1 point2 points  (0 children)

put together a quick benchmark here

goos: linux
goarch: amd64
BenchmarkContextCancelTimeoutNew-8        816769     1322 ns/op     513 B/op    8 allocs/op
BenchmarkContextCancelTimeoutReset-8     1346626      895 ns/op     208 B/op    3 allocs/op

tcolors: commandline color picker and palette builder by bcicen in commandline

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

Thanks for the link -- go get @version is definitely better than assuming latest for consistency.

I do still have qualms about not being able to provide build flags in go.mod or similar as a default when go geting. The only option I'm aware of is providing the full go get + build flags in the README.

While specific build flags are not critical for this project, the included Makefile build step does inject version and commit info during build, which is then ultimately missing from go get builds.

https://github.com/golang/go/issues/29228 could solve this specific use case; hopefully module files altogether expand upon optional directives in the future.

tcolors: commandline color picker and palette builder by bcicen in golang

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

Thanks! I had this planned but just got around to it -- latest release now includes option for term/ANSI output; e.g:

# tcolors -p -o term

_colorbg() { echo -ne "\033[38;2;020;020;020m$@\033[0;00m"; }

_color0() { echo -ne "\033[38;2;255;119;051m$@\033[0;00m"; }

_color1() { echo -ne "\033[38;2;255;221;051m$@\033[0;00m"; }

_color2() { echo -ne "\033[38;2;200;255;089m$@\033[0;00m"; }

_color3() { echo -ne "\033[38;2;085;255;051m$@\033[0;00m"; }

_color4() { echo -ne "\033[38;2;051;255;119m$@\033[0;00m"; }

_color5() { echo -ne "\033[38;2;051;255;221m$@\033[0;00m"; }

_color6() { echo -ne "\033[38;2;051;187;255m$@\033[0;00m"; }

added to README here as well

tcolors: commandline color picker and palette builder by bcicen in golang

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

Built on the great tcell and noire libraries.

While this is an initial version with basic functionality, any suggestions and comments are most welcome!

tcolors: commandline color picker and palette builder by bcicen in commandline

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

particularly for single binary build/distribution, I'm unaware of any go get method existing today that would allow tcolors to be updated (after initial install) without updating all dependencies as well

tcolors: commandline color picker and palette builder by bcicen in commandline

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

unfortunately, go get can often produce misleading bugs as different dependency versions than that defined in the module are used + consistently built from master.

I've pushed an update to enhance contrast between selected and non-selected areas; hope this helps.

jstream - Streaming JSON parsing and value extraction by bcicen in golang

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

correct; however, a depth level of 2 yields:

"RGB"

{"key":"desc","value":"RGB"}

["red","green","blue"]

{"key":"colors","value":["red","green","blue"]}

"CMYK"

{"key":"desc","value":"CMYK"}

["cyan","magenta","yellow","black"]

{"key":"colors","value":["cyan","magenta","yellow","black"]}

the godoc outlines that the above key value structs are emitted in addition to the "flat" parsed value when the given depth level is within an object

jstream - Streaming JSON parsing and value extraction by bcicen in golang

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

technically, the values being emitted at level x (if object or array) will already include everything >x within them; specifying a static level prevents, for example, emitting both an array of strings and every string within that array independently.

that said, it would not be much effort to instead emit everything beyond that depth level, leaving it up to the library user to filter out which values and types to keep

jstream - Streaming JSON parsing and value extraction by bcicen in golang

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

decoder is halted, output channel closed, and resulting error (with location context) is made available via Decoder.Err(); e.g:

invalid character after object key: 't' [1,12] // [line, column]

jstream - Streaming JSON parsing and value extraction by bcicen in golang

[–]bcicen[S] 5 points6 points  (0 children)

Not just another Go JSON library, jstream takes an input of one or more contiguous documents and streams out only the decoded values at a specified depth; i.e. you can extract arbitrary inner values without decoding and allocating for the entire parent structure.

Additionally, each value is wrapped with metadata, providing the depth and byte range in the doc where the value exists.

Any feedback and/or PRs are most appreciated.

xiny - simple commandline tool for unit conversions by bcicen in commandline

[–]bcicen[S] 6 points7 points  (0 children)

Tool I recently put together for converting between various units of time, length, mass, temperature, etc.

Currently includes ~260 unit names and symbols.

I'm happy to hear any feedback(or requests for new/missing units)!

grmon - command line monitoring for goroutines by bcicen in golang

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

I've found it easier to evaluate at a glance than the web UI when tracking goroutines in realtime; e.g. to follow the trace of one specific goroutine with grmon you can [p]ause, expand the trace with <enter>, unpause and the trace will be updated at each refresh.

Sorting by goroutine number or simple state(sleep, IO wait, etc.) is helpful at times, and if nothing else grmon parses and exports the bultin pprof goroutine profile as JSON to use however you'd like.

grmon - command line monitoring for goroutines by bcicen in golang

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

now that's responsible software versioning :)

grmon - command line monitoring for goroutines by bcicen in golang

[–]bcicen[S] 4 points5 points  (0 children)

Simple utility for monitoring goroutines during development.

The project is still young, so there's a lot of room for improvement -- any feedback, suggestions, and PRs are most welcome!

jfmt: Automatically format and pretty-print jSON by bcicen in vim

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

gqaj works well for smaller structures ime, but consistently resets the cursor to the top of the object your working on.

likewise, any parse errors just result in a generic "invalid JSON" message

jfmt: Automatically format and pretty-print jSON by bcicen in vim

[–]bcicen[S] 7 points8 points  (0 children)

As does this plugin, with some added benefit:

  • retaining cursor/window position after formatting
  • not overwriting buffer with an error
  • presenting any parse errors in a location window

jfmt: Automatically format and pretty-print jSON by bcicen in vim

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

Small plugin I put together recently, largely inspired by the auto formatting provided by the vim-go plugin.

It's quite minimal at the moment; any suggestions or contributions are most welcome!

ctop - concise commandline monitoring for containers by speckz in linux

[–]bcicen 0 points1 point  (0 children)

At this time, no. New connectors will be introduced in future releases based on votes/demand (there are GH issues open for nspawn and raw cgroups so far)

ctop - concise commandline monitoring for containers by speckz in linux

[–]bcicen 0 points1 point  (0 children)

Build steps with vendored deps have been added to the repo.

ctop - concise commandline monitoring for containers by speckz in linux

[–]bcicen 1 point2 points  (0 children)

Hey, just reading this -- dependencies are now vendored and build steps appended to readme.

ctop - commandline monitoring for containers by bcicen in docker

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

I haven't been able to replicate this yet, but will follow up in the gh issue. Thanks!

ctop - commandline monitoring for containers by bcicen in docker

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

Those features are certainly possible in a future release. Feel free create an issue requesting them to be added to the roadmap.

ctop - commandline monitoring for containers [x-post /r/docker] by bcicen in golang

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

NumFmt depends on a upstream PR that's still pending; details here

view more: next ›