profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/slimsag/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Stephen Gutekanst slimsag Sourcegraph Arizona https://slimsag.com Working on video games & developer tools in Zig; Developer @sourcegraph 6+ years

hexops/vecty 2086

Vecty lets you build responsive and dynamic web frontends in Go using WebAssembly, competing with modern web frameworks like React & VueJS.

slimsag/cgo-batching 20

CGO call batching benchmark

slimsag/cp 3

Chipmunk 2D physics wrapper for Go.

slimsag/appdash 2

Application tracing system for Go, based on Google's Dapper

slimsag/binpack 2

A Go implementation of Jake Gordon's 2D binpacking algorithm.

slimsag/9eyes 1

Raspberry Pi-based cat monitor for tracking feline inputs and outputs, weight

slimsag/darfree 1

Uses black magic to release memory on Darwin.

hexops/syndex 0

syndex performs language analysis via syntax-highlighting trees

rohanpai/shields 0

Shields badge specification, website and default API server

slimsag/archiver 0

Easily create and extract .zip, .tar.gz, .rar (extract-only), and .tar.bz2 files with Go

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha 00e2ae853c8e0bdd3e42a3f5c3895fbeb47e4b0d

325px -> 240px (required for email formatting) Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

view details

push time in 5 hours

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha 4078e25f6730ce3e2cff26a42c078c1235f1f6b9

centering Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

view details

push time in 5 hours

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha 68eec254c2c41ae51e8a3d1049dd456618916432

september: publish / fix date

view details

push time in 5 hours

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha f4ace850d3aec2a09c45e3e70275915ce934cb94

september: publish

view details

push time in 5 hours

delete branch hexops/zigmonthly.org

delete branch : september-21

delete time in 6 hours

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha db30f1b500e30609b9ccaad7f0156492d09fadca

September 2021: Unicode, Android, cross-platform GUIs, learning resources & more (#1) Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

view details

push time in 6 hours

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha 77a8593064526c125648d0e1276d01c9933026e8

add Slingworks/Underburrow, shuffle content, add media image Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

view details

push time in 6 hours

PullRequestReviewEvent

Pull request review commenthexops/zigmonthly.org

September 2021

+---+title: "Zig monthly, September 2021: Unicode, Android, cross-platform GUIs, learning resources & more"+date: 2021-10-25T00:00:00-07:00+draft: false+images: ["TODO"]+---++TODO: main article image, maybe "Ray tracing in a weekend" screenshot OR screenshot from Aetherwind++# Unicode++Zig has, thus far, taken a lighter weight stance on Unicode - there are no native unicode types in the language and the standard library is light weight in terms of Unicode support.++Unicode is a complex: even in languages such as Go (by the same creators as UTF-8 itself) there is still regular confusion and subtle bugs lurking behind [invalid assumptions about what runes/code-points and grapheme clusters actually are](https://www.reddit.com/r/golang/comments/o1o5hr/fyi_a_single_go_rune_is_not_the_same_as_a_single/). Most modern languages suffer from this foot-gun (with [Swift being perhaps the most notable _exception_](https://devlog.hexops.com/2021/unicode-sorting-why-browsers-added-special-emoji-matching#swifts-default-is-not-locale-aware-but-unicode-support-is-notable).)++People in the Zig community, myself included, care about Unicode support immensely, though. [@jecolon](https://github.com/jecolon) has been working tirelessly on two libraries:++* [Ziglyph](https://github.com/jecolon/ziglyph): Unicode text processing for the Zig Programming Language.+* [Zigstr](https://github.com/jecolon/zigstr): A UTF-8 string type - which exposes primarily Grapheme clusters to avoid the mentioned foot-gun.++As well as a series of articles:++* [Part 1: Unicode basics in Zig](https://zig.news/dude_the_builder/unicode-basics-in-zig-dj3)+* [Part 2: Ziglyph Unicode wrangling](https://zig.news/dude_the_builder/ziglyph-unicode-wrangling-llj)+* [Part 3: Unicode string operations](https://zig.news/dude_the_builder/unicode-string-operations-536e)++[@andrewrk](https://github.com/andrewrk) and [@jecolon](https://github.com/jecolon) are also [working together](https://github.com/ziglang/zig/issues/234#issuecomment-922065852) to ensure Zig's `std.unicode` library is a reasonable API in general before Zig 1.0.++# Android support++[@MasterQ32 has created a Zig android template repository](https://github.com/MasterQ32/ZigAndroidTemplate) - showing off how to create a minimal Android app in Zig.++Also see his earlier 2021 FOSDEM talk: [Create an Android Application with Zig](https://fosdem.org/2021/schedule/event/zig_android/) - I've included a short clip of the demo within for your enjoyment:++<video width="480px" src="https://user-images.githubusercontent.com/3173176/134788433-811ce689-ed38-40d3-8fda-09f5364e9734.mov" controls="controls" muted="muted">+    <a href="https://user-images.githubusercontent.com/3173176/134788433-811ce689-ed38-40d3-8fda-09f5364e9734.mov">+        <img width="480px" src="https://user-images.githubusercontent.com/3173176/134788463-ee505626-01d0-435c-9f74-05b0483aee74.png"></img>+    </a>+</video>++Felix also has aspirations to do Zig-on-iOS work, so please [consider sponsoring him](https://github.com/sponsors/MasterQ32) for some Apple hardware if his work appeals to you!++# Test your C code with Zig++[@Pixeli](https://twitter.com/TommiSinivuo) on Twitter has shared an extremely cool topic: [how to easily test your existing C code using Zig](https://twitter.com/TommiSinivuo/status/1432393016761856003).++# IUP (cross platform GUI) for Zig++Rafael Batiati has shared a very interesting article: [IUP for Zig](https://zig.news/batiati/iup-for-zig-4ah):++> It's a cross-platform GUI toolkit developed by PUC-RIO, the same university behind the excellent Lua language.++<a href="https://user-images.githubusercontent.com/3173176/134789187-8e3eddef-30e2-4fd7-b296-eb4de0f911f1.png"><img width="480px" src="https://user-images.githubusercontent.com/3173176/134789187-8e3eddef-30e2-4fd7-b296-eb4de0f911f1.png"></img></a>++<a href="https://user-images.githubusercontent.com/3173176/134789196-25ead67b-3939-49a1-b065-1ba77762ceb1.png"><img width="480px" src="https://user-images.githubusercontent.com/3173176/134789196-25ead67b-3939-49a1-b065-1ba77762ceb1.png"></img></a>++# Robinhood hash tables++[Kenta Iwasaki](https://github.com/lithdew) shared their robin hash table implementation:++> A robin hood hash table that keeps entries lexicographically sorted. Assumes that keys are 256-bit cryptographic hashes. Able to insert 25.8 million entries per second, query 30.83 million entries per second, and delete 24.21 million entries per second.+> +> Using it as one of the core main-memory data structures for a blockchain I'm writing in Zig called Rheia. Wrote and improved upon the data structure based on Twitter comments and articles made by Per Vognsen and Paul Khuong.+> +> Beats any other sorted data structure I've benchmarked so far in terms of insertion/query/deletion throughput by 3-4x order of magnitudes.+> +> https://github.com/lithdew/rheia/blob/master/hash_map.zig ++# Slingworks engine & Underburrow game++> _Underburrow is a speed running platformer game where you gather momentum with well timed button taps_++[@JonSnowbd shares _Slingworks 0.1_](https://github.com/JonSnowbd/slingworks): a simple and powerful Windows+Linux 'bring your content' engine built in Zig, as well as [Underburrow](https://github.com/JonSnowbd/underburrow): an all encompassing example for how Slingworks development works.++TODO: 1-2 screenshots/videos/gifs from Aetherwind on Discord

@JonSnowbd I threw this together - let me know if you want anything here reworded, etc. :)

slimsag

comment created time in a day

PR opened hexops/zigmonthly.org

September 2021
+157 -0

0 comment

1 changed file

pr created time in a day

push eventhexops/zigmonthly.org

Stephen Gutekanst

commit sha c7e53ed363f44588454feea96b46a7badd711002

WIP Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

view details

push time in a day

PullRequestReviewEvent

issue commentsourcegraph/lsif-go

Uncommitted API docs changes when running tests

Sorry for the delay on this.

Yes, these are golden tests: the test is, given all of our testdata code / Go packages, what API docs would be generated?

If there is a diff, the tests should fail (but there may be a bug here where they don't). Regardless, if there are changes - either because we've introduced new code into the testdata Go packages, or because we've made changes, they are real changes to API docs too and should either be committed (if they look good) or reviewed by me (if you're unsure)

It's important that this runs over all code in the testdata directory, too, because we're constantly finding new edge cases that we haven't considered before and it's important we test API docs generation on those edge cases too.

chrismwendt

comment created time in a day

push eventsourcegraph/sourcegraph

Stephen Gutekanst

commit sha d321bcb18d7b4d7abb75341e3bb875d2b9e4932e

search: do not panic / use Zoekt code path if indexed search is disabled (#25321) * search: do not panic / use Zoekt code path if indexed search is disabled where disabling indexed search via the site config would result in a nil pointer panic reported in #25269 This was released in 3.32.0, but disabling indexed search is very rare and generally advised against. We suggest turning indexed search on via `"search.index.enabled": true,` in your site configuration (or removing the existing line which disables it) to fix the issue. Fixes #25269 Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com> * internal/conf: correct default search.index.enabled value Prior to this change, the default for `search.index.enabled` was incorrect iff the deploy type was a single-container AND `search.index.enabled` was not present in the site configuration. * New Docker instances would receive `"search.index.enabled": true,` by default in their site config, according to `confdefaults.go`. * Older Docker instances that did not receive this default site config, would have NO configured `search.index.enabled` key in their site config, which would then default to `false`(!) - obviously incorrect. The expectation has long been that indexed search is on by default for all instances (I know, because I made this change a few years back.) Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>

view details

push time in 3 days

delete branch sourcegraph/sourcegraph

delete branch : sg/search-regression

delete time in 3 days

PR merged sourcegraph/sourcegraph

Reviewers
search: do not panic / use Zoekt code path if indexed search is disabled team/search

This PR fixes an issue where disabling indexed search via the site config would result in a nil pointer panic reported in #25269

This PR also fixes an issue where the default value of search.index.enabled was incorrectly computed as false on some Docker instances (older ones), while newer ones would always start with "search.index.enabled": true,.

This regression was released in 3.32.0, but having indexed search disabled is rare, this would generally only affect single-container Docker instances, and anyone can easily workaround the issue by adding "search.index.enabled": true, to their site configuration.

Fixes #25269

Signed-off-by: Stephen Gutekanst stephen@sourcegraph.com

+7 -23

3 comments

4 changed files

slimsag

pr closed time in 3 days

issue closedsourcegraph/sourcegraph

Runtime panic when performing any search in version 3.32.0

I just updated to v3.32.0 and it keeps crashing and restarting any time a try to do a search.

Sourcegraph version: 3.32.0

Platform information: Debian Linux Kernel 5.13.4-x86_64-linode146 Linode docker-ce 5:20.10.8~3-0~debian-buster Single Sourcegraph container + lang-typescript container

Steps to reproduce:

  1. Start Sourcegraph v3.32.0
  2. Perform a search or type in the search box

Expected behavior:

The search should complete.

Actual behavior:

When performing a search I see this stack trace in the logs:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x1b11221]
goroutine 995 [running]:
github.com/sourcegraph/sourcegraph/internal/search/zoekt.doZoektSearchGlobal({0x66f7e00, 0xc001422d80}, {0x6691c40, 0xc00212d560}, {0x293eaad, 0x4}, {0x0, 0x0}, 0x1f4, {0x812c6f8, ...}, ...)
   github.com/sourcegraph/sourcegraph/internal/search/zoekt/indexed_search.go:485 +0x401
github.com/sourcegraph/sourcegraph/internal/search/zoekt.(*IndexedUniverseSearchRequest).Search(0xc000ee94a0, {0x66f7e00, 0xc001422d80}, {0x6694120, 0xc00220ac80})
   github.com/sourcegraph/sourcegraph/internal/search/zoekt/indexed_search.go:173 +0x177
github.com/sourcegraph/sourcegraph/internal/search/unindexed.SearchFilesInRepos.func2()
   github.com/sourcegraph/sourcegraph/internal/search/unindexed/unindexed.go:72 +0x32
golang.org/x/sync/errgroup.(*Group).Go.func1()
   golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57 +0x67
created by golang.org/x/sync/errgroup.(*Group).Go
   golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:54 +0x92

If I type in the search box I get the following error:

goroutine panic: runtime error: invalid memory address or nil pointer dereference
goroutine 886 [running]:
runtime/debug.Stack()
   runtime/debug/stack.go:24 +0x65
github.com/sourcegraph/sourcegraph/internal/goroutine.Go.func1.1()
   github.com/sourcegraph/sourcegraph/internal/goroutine/goroutine.go:19 +0x39
panic({0x25398c0, 0x80b5e60})
   runtime/panic.go:1038 +0x215
github.com/sourcegraph/sourcegraph/internal/search/zoekt.doZoektSearchGlobal({0x66f8df8, 0xc002037340}, {0x6691c40, 0xc001d16c90}, {0x295797c, 0x6}, {0x0, 0x0}, 0x1e, {0x812c6f8, ...}, ...)
   github.com/sourcegraph/sourcegraph/internal/search/zoekt/indexed_search.go:485 +0x401
github.com/sourcegraph/sourcegraph/internal/search/zoekt.(*IndexedUniverseSearchRequest).Search(0xc0011943c0, {0x66f8df8, 0xc002037340}, {0x6694120, 0xc002037360})
   github.com/sourcegraph/sourcegraph/internal/search/zoekt/indexed_search.go:173 +0x177
github.com/sourcegraph/sourcegraph/internal/search/symbol.Search.func2()
   github.com/sourcegraph/sourcegraph/internal/search/symbol/symbol.go:71 +0xa7
github.com/sourcegraph/sourcegraph/internal/goroutine.Go.func1()
   github.com/sourcegraph/sourcegraph/internal/goroutine/goroutine.go:24 +0x3f
created by github.com/sourcegraph/sourcegraph/internal/goroutine.Go
   github.com/sourcegraph/sourcegraph/internal/goroutine/goroutine.go:16 +0x5b
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x1b11221]
goroutine 863 [running]:
github.com/sourcegraph/sourcegraph/internal/search/zoekt.doZoektSearchGlobal({0x66f7e00, 0xc001e1b300}, {0x6691c40, 0xc001c7ab88}, {0x293eaad, 0x4}, {0x0, 0x0}, 0x1e, {0x812c6f8, ...}, ...)
   github.com/sourcegraph/sourcegraph/internal/search/zoekt/indexed_search.go:485 +0x401
github.com/sourcegraph/sourcegraph/internal/search/zoekt.(*IndexedUniverseSearchRequest).Search(0xc000191b30, {0x66f7e00, 0xc001e1b300}, {0x6694120, 0xc002008f20})
   github.com/sourcegraph/sourcegraph/internal/search/zoekt/indexed_search.go:173 +0x177
github.com/sourcegraph/sourcegraph/internal/search/unindexed.SearchFilesInRepos.func2()
   github.com/sourcegraph/sourcegraph/internal/search/unindexed/unindexed.go:72 +0x32
golang.org/x/sync/errgroup.(*Group).Go.func1()
   golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57 +0x67
created by golang.org/x/sync/errgroup.(*Group).Go
   golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:54 +0x92

closed time in 3 days

DavidZidar

push eventsourcegraph/sourcegraph

Stephen Gutekanst

commit sha fccbf08597603b2cef4f58c0381b95aeb2b76d64

remove now useless tests Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>

view details

push time in 3 days

pull request commentsourcegraph/sourcegraph

search: do not panic / use Zoekt code path if indexed search is disabled

@rvantonder Oh, I absolutely agree. @tsenart can you take a look at how we can test the search specific logic here?

In broader terms, I would actually rephrase this, though. Search indexing (Zoekt) is enabled in ALL deployments by default and has been for a very long time, and anybody who turns it off is going to have a Really Bad Time™. Given these two facts, I would actually encourage the search team to just completely eliminate the search.index.enabled option (unless you see a useful reason to have this around for debugging, but then maybe just use an env var that users cannot easily find/configure.)

Of course, eliminating the potential for search.index.enabled may not change the potential reasons we have to pass through a flag as we are indicating "should the indexed search or non-indexed search code path be used?" here, but it would've prevented this regression. Less complexity / smaller configuration matrix size == better.

I'll defer this to you @sourcegraph/search-core - my aim here was just to fix the immediate regression and determine scope among the much wider release incident issues we're seeing.

slimsag

comment created time in 3 days

push eventsourcegraph/sourcegraph

Stephen Gutekanst

commit sha 14fba543a21985d955044c5d6dcca38547c2c12c

fix test Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>

view details

push time in 3 days

pull request commentsourcegraph/sourcegraph

search: do not panic / use Zoekt code path if indexed search is disabled

Verified I was able to reproduce #25269 and this fixed it after.

slimsag

comment created time in 3 days

push eventsourcegraph/sourcegraph

Stephen Gutekanst

commit sha c6f6be1cf6fd5870a86cfa3c927f0b28185a8e87

CHANGELOG Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>

view details

push time in 3 days

push eventsourcegraph/sourcegraph

Stephen Gutekanst

commit sha 8a840aa2a8467221546945f055aa797610dd3e80

internal/conf: correct default search.index.enabled value Prior to this change, the default for `search.index.enabled` was incorrect iff the deploy type was a single-container AND `search.index.enabled` was not present in the site configuration. * New Docker instances would receive `"search.index.enabled": true,` by default in their site config, according to `confdefaults.go`. * Older Docker instances that did not receive this default site config, would have NO configured `search.index.enabled` key in their site config, which would then default to `false`(!) - obviously incorrect. The expectation has long been that indexed search is on by default for all instances (I know, because I made this change a few years back.) Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>

view details

Stephen Gutekanst

commit sha bc71cf46b9758f5ade12c10c72d10c6a8e84792c

CHANGELOG Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>

view details

push time in 3 days

PR opened sourcegraph/sourcegraph

Reviewers
search: do not panic / use Zoekt code path if indexed search is disabled team/search

This PR fixes an issue where disabling indexed search via the site config would result in a nil pointer panic reported in #25269

This PR also fixes an issue where the default value of search.index.enabled was incorrectly computed as false on some Docker instances (older ones), while newer ones would always start with "search.index.enabled": true,.

This regression was released in 3.32.0, but having indexed search disabled is rare, this would generally only affect single-container Docker instances, and anyone can easily workaround the issue by adding "search.index.enabled": true, to their site configuration.

Fixes #25269

Signed-off-by: Stephen Gutekanst stephen@sourcegraph.com

+1 -1

0 comment

1 changed file

pr created time in 3 days

Pull request review commentsourcegraph/sourcegraph

search: optimize memory usage

 func (s *IndexedUniverseSearchRequest) Search(ctx context.Context, c streaming.S 	}  	q := zoektGlobalQuery(s.Args.Query, s.RepoOptions, s.UserPrivateRepos)-	return doZoektSearchGlobal(ctx, q, s.Args.Typ, s.Args.Zoekt.Client, s.Args.FileMatchLimit, s.Args.Select, c)+	return doZoektSearchGlobal(ctx, q, s.Args.Typ, s.Args.Zoekt, s.Args.FileMatchLimit, s.Args.Select, c)

Followed up in https://github.com/sourcegraph/sourcegraph/issues/25269#issuecomment-926238079

tsenart

comment created time in 3 days

PullRequestReviewEvent

issue commentsourcegraph/sourcegraph

Runtime panic when performing any search in version 3.32.0

OK, I know what is happening:

  1. We do default all new Sourcegraph instances' configurations to "search.index.enabled": true, by default, including all OSS and enterprise versions of the standalone Docker image: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/conf/confdefaults/confdefaults.go?L49
  2. However.. if your instance came from before we had done this, it would not have "search.index.enabled": true, explicitly set in the site configuration - which means it would default to off, which is incorrect.

Additionally, as you pointed out in this PR you've found the right root cause of the panic: https://github.com/sourcegraph/sourcegraph/pull/24998#discussion_r715147076

I will send a PR for both of these which will land in the next 3.33.0 release.

Workaround for anybody facing this: set "search.index.enabled": true, in your site configuration.

DavidZidar

comment created time in 3 days

create barnchsourcegraph/sourcegraph

branch : sg/search-regression

created branch time in 3 days

PullRequestReviewEvent