text:
Continue improving GDNative

I should have submitted this last week this before going in vacation :sleeping:

Rename paramters in Array/Pool/Dictionary to keep consistency with the rest of the API
Add missing properties in rect3, quat and transform
Remove deprecated GODOT_VARIANT_TYPE_INPUT_EVENT
Replace godot_*_new_copy by godot_*_copy function (simpler API, and imo more logical to consider this function as an object "method" than a standalone constructor)
Replace Dictionary/Pool/Array item access by pointer by set/get functions.

@karroffel Considering the last point, I saw you changed godot_array_get to return a pointer. I don't get the need for this (I would say it allow to be a bit faster because we can call the function once and only work on the pointer then, but it's also less user friendly than a get/set).
I've reverted to the get/set solution right now because it's what use Pythonscript right now. However I'm willing to change this PR and Pythonscript if you think your solution is better ;-)

Very cool, thanks!
All the changes look okay so far!
The get/set thing is very unfortunate if you're using C++. In general it is nice to have separate set and get functions, but in C++, operator[] doesn't have separate set and get version, it's just one version that returns a reference to which you can write. So it would be nice to have such a version of the method. The set/get can stay, but a pointer version would be nice too.

The copy constructors require uninitialized memory (they'll cause a memory leak if called on an existing godot_array/_dictionary/etc). That's why I called them ..._new_copy rather than just ..._copy. They work differently from godot_variant_copy, which just calls the assignment operator on an existing Variant.
I don't mind the shorter name, it's just less obvious without looking at the source code that they're constructors, not methods.

@karroffel I've added the index operator in array&dictionary

@touilleMan awesome, thanks!
And what @sheepandshepherd said, copy constructors aren't methods and can cause memory leaks, so I prefer to have new in that name too and make it work on uninitialized object. aka revert that change

@touilleMan looks good to me, squash and ready to go!

@karroffel I think you can do the squash directly when merging by choosing the Squash and merge option

I think you can do the squash directly when merging by choosing the Squash and merge option

Yes, but that option has various flaws (the "merged" PR no longer matches the actual PR commits, and the commit log generated by GitHub is badly formatted (lacks a \n at the end)). I use it only in times of dire need, i.e. when I get a PR from a complete git noob that made 15 commits by uploading files via the GitHub web editor...

Fair enough, I've done the squash then

authors: akien-mga karroffel sheepandshepherd touilleMan


text:
Replace default deadzone magic number with named constant and fix InputEventJoypadMotion::set_axis_value unresponsiveness

Closes #98982.
In #97281, the default deadzone for input actions was changed from 0.5 to 0.2. Apparently this instance of 0.5 slipped through the cracks, so controller sticks were often not surpassing the threshold for their action to be considered "pressed".
The PR now replaces all instances of the 0.2 default deadzone magic number (that I know of) with a constant, InputMap::DEFAULT_DEADZONE. This way, if something necessitates changing the value again, it only has to be changed in one spot, and additionally we know what the value means when looking through the code.
Currently, the PR fixes this instance of the deadzone value. In the long run, I think it might be best to replace this magic number and all of the instances of 0.2 with a deadzone constant, but I'm not sure where exactly in the Godot code such a constant would go, so that it can be accessed from everywhere it needs to be. If that sounds like a good idea, I would appreciate advice on where to put it 😄

Thanks!

source: gharchive/pull-request

authors: Meorge Repiteo

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
Touch Screen Compatability?

Rotatable is completely awesome thank you for your efforts. I'm trying to use the plugin for a web app that's destined for an iPad. Testing on desktop browsers works perfectly. Unfortunately, i'm not able to get rotation to work on the iPad. When I tap and drag on the rotation handle, nothing happens. I tried the obvious replacement of mouse triggers with touch triggers (touchstart, touchmove and touchend)...this did not do the trick. Any insight you can provide is very much appreciated.
Thanks again

I'm not able to reproduce this any longer. Please re-open if this is still a problem.

Hi godswearhats,
I still can reproduce this by simply adding jquery.ui.touch-punch.js to your demo and open the file on my smartphone. The examples with draggable activated work, the standalone rotatables don't. Resizable doesn't seem to have an impact, it has to be draggable.
Seems like you can work around this issue by simply making the element draggable anyway and set the handle to .ui-rotatable-handle. This will "activate" the handle for touch-input. The element itself won't be draggable since rotatable will overwrite the handle events, I guess.
$('#rotate').draggable({handle: ".ui-rotatable-handle"}).rotatable(params);

I hope this will help someone.
Nice plugin by the way!

Thanks for the workaround. I think the real fix is likely there somewhere, but it seems to be beyond my skills :-)

Hi,
maybe I have found something on this topic. I tried to make the rotating button work with a similar setup as described here, and have the same issue on iPad: The button is not working.
So I created a 'stand alone' button which simulates the mouse event by translating the event.touches[0].clientX into event.clientX, and then I call the corresponding 'startRotate', 'rotateElement' and 'stopRotate'. It works.
This code snippet expect a div with id "rotatableProt", and a previous call to setup rotatable.

Rotate

I made this in order to understand why rotatable is not working on iPad. Now when I see mgmbh's comment above, I will give his idea a try.

Hi,
Because the plugin don't handle the touchstart, touchmove and touchend events, is not working correctly, not even with plugins like touch punch. At least not for me.
I have added those events to the plugin, with some minor amends and for me is working perfectly now.
Will suggest a pull request when I get a sec.
Until then you can take it and try it from dropbox link - https://www.dropbox.com/s/uwpkrb6uu7asx62/jquery.ui.rotatable.js?dl=0
Best

Great, I got it working with the code I uploaded, having my own rotate handle. I have had some problems with creating the ontouch events the javascript way, but putting them inside the html as above seem to work..

source: gharchive/issue

authors: Snorvarg emgbeeker godswearhats mgmbh twinkleminds

repo: godswearhats/jquery-ui-rotatable

license: mit

license_source: bigquery


text:
Improper logs  in sqlite db

When connecting to sqlite db - logs are coming incorrectly.
Port and host are coming in spite of no port and host required.
To Reproduce: Connect with the following configs -
DB_DIALECT=sqlite
DB_NAME=test

Hi @aryanmehrotra I would like to work on this. Could your please Assign this issue to me?

@aryanmehrotra are you referring to this line in log
,"message":"connected to 'test_db' database at 'localhost:3306'"
here ip:port should not be logged for sqlite

Yes and if you can set log level to DEBUG you would be seeing more of these

ok so for sqlite only changing it to connected to 'test_db' database

@SkMishra77 yups you can raise a PR for these changes

@aryanmehrotra @Umang01-hash
Code Climate fails because Cognitive Complexity exceeds so should i refactor this fuction ?

@Umang01-hash , I see the linked PR has no latest progress. I would like to work on this. Please assign this to me.

repo: gofr-dev/gofr


text:
Fix: Missing Connection Successful Logs

Pull Request Template
Description:

Closes #1204

Checklist:

[ ] I have formatted my code using  goimport  and  golangci-lint.
[ ] All new code is covered by unit tests.
[ ] This PR does not decrease the overall code coverage.
[ ] I have reviewed the code comments and documentation for clarity.

Thank you for your contribution!

Why closing?

Is it because this one superseded it?
https://github.com/gofr-dev/gofr/pull/1205

Why closing?

There are continuous build fails. I will address that and then reopen, this PR.

If we have introduced debugf, we should check if we still need debug there. If not, we should probably remove it. @coolwednesday

authors: ccoVeille coolwednesday vikash


text:
How to friendly query field of date type in mysql

How to friendly query field of date type in mysql

ENV
go version ：go 1.18rc1 windows/amd64
GoFrame Version: v2.0.0-rc3
Mysql : 5.7

Can this issue be re-produced with the latest release?

yes

What did you do?
I want to query field in Mysql, using the date  type ( yyyy-m-d). And gf-cli  generate the entity struct like this:

type Sample struct{
    Date *gtime.time
}

I try to do that to get data:
func Get(ctx context.Context, gDate *gtime.Time) (err error) {
    var (
    d = dao.User
    m = d.Ctx(ctx)
    c = d.Columns()
    )

    one, _ := m.Where(c.Date, gDate).One()
    one.IsEmpty() // always true
    ...
}

one always is empty, because gDate will be parsed as datetime( yyyy-m-d HH:mm:ss) not date type.
If do that, I can get.
	// convert to yyyy-m-d
	one, _ := m.Where(c.Date, gDate.String()[:10]).One()

I check log, the mysql code like this :
[default] [rows:0  ] SELECT * FORM table_sample WHERE (`date` = '2006-01-02 15:04:05') LIMIT 1

I want
[default] [rows:1  ] SELECT * FORM table_sample WHERE (`date` = '2006-01-02') LIMIT 1

I think use gDate.Format("Y-m-d") is better than gDate.String()[:10]

I think use gDate.Format("Y-m-d") is better than gDate.String()[:10]

@niluan304 Yep, @sanrentai is right.

authors: gqcn niluan304 sanrentai

repo: gogf/gf


text:
documentation for docker Domain setting incorrect

The docs say to set the Domain to the container's IP address.  Actually, you want to set it to the docker hosts IP address.  As the docker container is running in non-host networking mode, the IP address of the container is unreachable from the outside.  That's why you need to port map 22 and 3000 though to the host ports 10022 and 10080.

Hmm... thanks!
I didn't thought about access from outside network, the original purpose was only to access Docker-based Gogs locally.

Please help check again: https://github.com/gogits/gogs/tree/master/docker#settings

Thanks!  Why would one run gogs in docker and then try to access it only from within the docker engine, tho?  Also, I think the text might be more clear as
"But if you want to access your Gogs instance from a different physical machine, please fill in with the hostname or IP address of the docker host machine".

Thanks! Why would one run gogs in docker and then try to access it only from within the docker engine, tho? Also, I think the text might be more clear as

If you're running in some embedded system, it could happen that Docker has a IP address can be accessed from all local computers.

Updated docs again.

Close as fixed.

authors: Unknwon llamahunter

repo: gogits/gogs


text:
Allow file and directory names to contain percent character

This is a quick fix for #1137
EscapePound could be expanded to full blown url_encode probably using URL from net/url but I'm not sure how this will affect performance as it's a fairly frequently used function in templates.
Speaking of templates, every href attribute has to use EscapePound on user generated content i.e. various names (repo, user, directory, file) or risk invalid links.

Thanks!

authors: Unknwon wqweto


text:
CLI PANICS when config is a file instead of directory

To Reproduce this issue

Remove the old config file
create a directory in place of config file. with same name of config file
this causes the cli to panic

Expected Behaviour
Instead of panicking CLI should return error there is a directory in the place of config file.

Error output
(PANIC)
> harbor-dev artifacts list
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0xa2ca07]

goroutine 1 [running]:
github.com/goharbor/harbor-cli/cmd/harbor/root.InitConfig()
        /src/cmd/harbor/root/cmd.go:34 +0x147
github.com/spf13/cobra.(*Command).preRun(...)
        /go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1019
github.com/spf13/cobra.(*Command).execute(0xc00036ec08, {0x1245340, 0x0, 0x0})
        /go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:929 +0x5a2
github.com/spf13/cobra.(*Command).ExecuteC(0xc000216608)
        /go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1117 +0x3ff
github.com/spf13/cobra.(*Command).Execute(0xc0000061c0?)
        /go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1041 +0x13
main.main()
        /src/cmd/harbor/main.go:10 +0x18

@bupd is this in the default home directory? Does it also happen after commit 0d1f474 to main?
I can have a look and try to reproduce this issue

@Standing-Man
To Reproduce this issue
Remove the old config file
create a directory in place of config file. with same name of config file
this causes the cli to panic
Expected Behaviour
Instead of panicking CLI should return error there is a directory in the place of config file.

Thank you for providing more details on how to reproduce this issue. I will try to figure out what is going wrong.

authors: Standing-Man bupd qcserestipy

repo: goharbor/harbor-cli


text:
--help returns all available config options

--help returns all available config options instead of just displaying important ones as defined here:
https://github.com/gohornet/hornet/blob/bcc6fc754ccad0538af9ff7bc532f3da9558edc4/pkg/config/config.go#L37-L47

Fixed with #557

authors: IoTMOD muXxer

repo: gohornet/hornet


text:
Hugo is unable to find layout

Since v0.42 hugo fails to build html files
Steps to reproduce
$ git clone https://github.com/vickylai/hugo-theme-introduction.git
$ cd hugo-theme-introduction/exampleSite/
$ wget https://github.com/gohugoio/hugo/releases/download/v0.42.2/hugo_0.42.2_Linux-64bit.tar.gz
$ ./hugo  --themesDir .. -t . -v
WARN 2018/06/28 19:23:35 No translation bundle found for default language "en"
WARN 2018/06/28 19:23:35 Translation func for language en not found, use default.
WARN 2018/06/28 19:23:35 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.
INFO 2018/06/28 19:23:35 Using config file: /tmp/hugo-theme-introduction/exampleSite/config.toml
Building sites … INFO 2018/06/28 19:23:35 syncing static files to /tmp/hugo-theme-introduction/exampleSite/public/
INFO 2018/06/28 19:23:35 found taxonomies: map[string]string{"tag":"tags", "category":"categories"}
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "page": [projects/single.en.html.html projects/single.html.html projects/single.en.html projects/single.html _default/single.en.html.html _default/single.html.html _default/single.en.html _default/single.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "page": [blog/single.en.html.html blog/single.html.html blog/single.en.html blog/single.html _default/single.en.html.html _default/single.html.html _default/single.en.html _default/single.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "page": [page/single.en.html.html page/single.html.html page/single.en.html page/single.html _default/single.en.html.html _default/single.html.html _default/single.en.html _default/single.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "section": [blog/blog.en.html.html blog/section.en.html.html blog/list.en.html.html blog/blog.html.html blog/section.html.html blog/list.html.html blog/blog.en.html blog/section.en.html blog/list.en.html blog/blog.html blog/section.html blog/list.html section/blog.en.html.html section/section.en.html.html section/list.en.html.html section/blog.html.html section/section.html.html section/list.html.html section/blog.en.html section/section.en.html section/list.en.html section/blog.html section/section.html section/list.html _default/blog.en.html.html _default/section.en.html.html _default/list.en.html.html _default/blog.html.html _default/section.html.html _default/list.html.html _default/blog.en.html _default/section.en.html _default/list.en.html _default/blog.html _default/section.html _default/list.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "taxonomyTerm": [categories/category.terms.en.html.html categories/terms.en.html.html categories/list.en.html.html categories/category.terms.html.html categories/terms.html.html categories/list.html.html categories/category.terms.en.html categories/terms.en.html categories/list.en.html categories/category.terms.html categories/terms.html categories/list.html taxonomy/category.terms.en.html.html taxonomy/terms.en.html.html taxonomy/list.en.html.html taxonomy/category.terms.html.html taxonomy/terms.html.html taxonomy/list.html.html taxonomy/category.terms.en.html taxonomy/terms.en.html taxonomy/list.en.html taxonomy/category.terms.html taxonomy/terms.html taxonomy/list.html category/category.terms.en.html.html category/terms.en.html.html category/list.en.html.html category/category.terms.html.html category/terms.html.html category/list.html.html category/category.terms.en.html category/terms.en.html category/list.en.html category/category.terms.html category/terms.html category/list.html _default/category.terms.en.html.html _default/terms.en.html.html _default/list.en.html.html _default/category.terms.html.html _default/terms.html.html _default/list.html.html _default/category.terms.en.html _default/terms.en.html _default/list.en.html _default/category.terms.html _default/terms.html _default/list.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "taxonomy": [tags/tag.en.html.html tags/taxonomy.en.html.html tags/list.en.html.html tags/tag.html.html tags/taxonomy.html.html tags/list.html.html tags/tag.en.html tags/taxonomy.en.html tags/list.en.html tags/tag.html tags/taxonomy.html tags/list.html taxonomy/tag.en.html.html taxonomy/taxonomy.en.html.html taxonomy/list.en.html.html taxonomy/tag.html.html taxonomy/taxonomy.html.html taxonomy/list.html.html taxonomy/tag.en.html taxonomy/taxonomy.en.html taxonomy/list.en.html taxonomy/tag.html taxonomy/taxonomy.html taxonomy/list.html tag/tag.en.html.html tag/taxonomy.en.html.html tag/list.en.html.html tag/tag.html.html tag/taxonomy.html.html tag/list.html.html tag/tag.en.html tag/taxonomy.en.html tag/list.en.html tag/tag.html tag/taxonomy.html tag/list.html _default/tag.en.html.html _default/taxonomy.en.html.html _default/list.en.html.html _default/tag.html.html _default/taxonomy.html.html _default/list.html.html _default/tag.en.html _default/taxonomy.en.html _default/list.en.html _default/tag.html _default/taxonomy.html _default/list.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "home": [page/index.en.html.html page/home.en.html.html page/list.en.html.html page/index.html.html page/home.html.html page/list.html.html page/index.en.html page/home.en.html page/list.en.html page/index.html page/home.html page/list.html index.en.html.html home.en.html.html list.en.html.html index.html.html home.html.html list.html.html index.en.html home.en.html list.en.html index.html home.html list.html _default/index.en.html.html _default/home.en.html.html _default/list.en.html.html _default/index.html.html _default/home.html.html _default/list.html.html _default/index.en.html _default/home.en.html _default/list.en.html _default/index.html _default/home.html _default/list.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "section": [projects/projects.en.html.html projects/section.en.html.html projects/list.en.html.html projects/projects.html.html projects/section.html.html projects/list.html.html projects/projects.en.html projects/section.en.html projects/list.en.html projects/projects.html projects/section.html projects/list.html section/projects.en.html.html section/section.en.html.html section/list.en.html.html section/projects.html.html section/section.html.html section/list.html.html section/projects.en.html section/section.en.html section/list.en.html section/projects.html section/section.html section/list.html _default/projects.en.html.html _default/section.en.html.html _default/list.en.html.html _default/projects.html.html _default/section.html.html _default/list.html.html _default/projects.en.html _default/section.en.html _default/list.en.html _default/projects.html _default/section.html _default/list.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "taxonomyTerm": [tags/tag.terms.en.html.html tags/terms.en.html.html tags/list.en.html.html tags/tag.terms.html.html tags/terms.html.html tags/list.html.html tags/tag.terms.en.html tags/terms.en.html tags/list.en.html tags/tag.terms.html tags/terms.html tags/list.html taxonomy/tag.terms.en.html.html taxonomy/terms.en.html.html taxonomy/list.en.html.html taxonomy/tag.terms.html.html taxonomy/terms.html.html taxonomy/list.html.html taxonomy/tag.terms.en.html taxonomy/terms.en.html taxonomy/list.en.html taxonomy/tag.terms.html taxonomy/terms.html taxonomy/list.html tag/tag.terms.en.html.html tag/terms.en.html.html tag/list.en.html.html tag/tag.terms.html.html tag/terms.html.html tag/list.html.html tag/tag.terms.en.html tag/terms.en.html tag/list.en.html tag/tag.terms.html tag/terms.html tag/list.html _default/tag.terms.en.html.html _default/terms.en.html.html _default/list.en.html.html _default/tag.terms.html.html _default/terms.html.html _default/list.html.html _default/tag.terms.en.html _default/terms.en.html _default/list.en.html _default/tag.terms.html _default/terms.html _default/list.html]
WARN 2018/06/28 19:23:35 [en] Unable to locate layout for "404": [404.html theme/404.html]

                   | EN
+------------------+----+
  Pages            | 10
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  5
  Processed images |  0
  Aliases          |  0
  Sitemaps         |  1
  Cleaned          |  0

Total in 12 ms

Hugo v0.41
./hugo  --themesDir .. -t . -v
INFO 2018/06/28 19:24:48 Using config file: /tmp/hugo-theme-introduction/exampleSite/config.toml
Building sites … INFO 2018/06/28 19:24:48 syncing static files to /tmp/hugo-theme-introduction/exampleSite/public/
WARN 2018/06/28 19:24:48 No translation bundle found for default language "en"
WARN 2018/06/28 19:24:48 Translation func for language en not found, use default.
WARN 2018/06/28 19:24:48 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.
INFO 2018/06/28 19:24:48 found taxonomies: map[string]string{"tag":"tags", "category":"categories"}

                   | EN
+------------------+----+
  Pages            | 29
  Paginator pages  |  0
  Non-page files   |  0
  Static files     | 35
  Processed images |  0
  Aliases          |  0
  Sitemaps         |  1
  Cleaned          |  0

Total in 51 ms

What does "-t ." mean? I assume this is a path issue vs the --themesDir setting. Does it work if you either

Put the theme inside /themes
Set themesDir in config.xml

-t sets the theme to use. ( -t, --theme string               theme to use (located in /themes/THEMENAME/))
Neither 1. nor 2. works.

-t sets the theme to use.

That I understand. But is your theme really named "."?

No. But this way I can use the current directory as theme.
I don't think this is the root of the problem. It also happens if I put the theme the "normal way" into themes.

No. But this way I can use the current directory as theme.
I don't think this is the root of the problem. It also happens if I put the theme the "normal way" into themes.

I updated the Steps to reproduce to make the problem more clear.

If you comment out theme in config.toml hugo will panic:
$ hugo -v -t hugo-theme-introduction
panic: AllThemes not set

goroutine 1 [running]:
github.com/gohugoio/hugo/hugolib/filesystems.createThemesOverlayFs(0xc42010ca00, 0x0, 0xc42045d0f8, 0x412378, 0x30, 0xdf1360, 0x1, 0xc4202faf90)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/hugolib/filesystems/basefs.go:572 +0x315
github.com/gohugoio/hugo/hugolib/filesystems.(*sourceFilesystemsBuilder).Build(0xc4204b28c0, 0xc4202faf90, 0xc4200281e4, 0x25)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/hugolib/filesystems/basefs.go:258 +0x2ee
github.com/gohugoio/hugo/hugolib/filesystems.NewBase(0xc42010ca00, 0x0, 0x0, 0x0, 0x0, 0x0, 0xdd0000000000000e)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/hugolib/filesystems/basefs.go:232 +0x7e5
github.com/gohugoio/hugo/helpers.NewPathSpecWithBaseBaseFsProvided(0xc4204b2500, 0x101f300, 0xc4201bbdc0, 0x0, 0xc420440420, 0x20, 0x20)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/helpers/pathspec.go:59 +0x9f
github.com/gohugoio/hugo/helpers.NewPathSpec(0xc4204b2500, 0x101f300, 0xc4201bbdc0, 0xc420440420, 0x0, 0x1519180)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/helpers/pathspec.go:41 +0x48
github.com/gohugoio/hugo/deps.New(0xc4204b4200, 0xc4204b2500, 0xc4201bbdc0, 0x101f420, 0xc4200cd680, 0x100e5c0, 0x0, 0xc420440420, 0x100e540, 0xc420440400, ...)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/deps/deps.go:126 +0xb0
github.com/gohugoio/hugo/hugolib.applyDepsIfNeeded(0xc4204b4200, 0xc4204b2500, 0xc4201bbdc0, 0x101f420, 0xc4200cd680, 0x100e5c0, 0x0, 0xc420440420, 0x100e540, 0xc420440400, ...)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/hugolib/hugo_sites.go:190 +0x321
github.com/gohugoio/hugo/hugolib.newHugoSites(0xc4204b4200, 0xc4204b2500, 0x0, 0x101f420, 0xc4200cd680, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/hugolib/hugo_sites.go:134 +0x24d
github.com/gohugoio/hugo/hugolib.NewHugoSites(0xc4204b4200, 0xc4204b2500, 0x0, 0x101f420, 0xc4200cd680, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/hugolib/hugo_sites.go:227 +0xf5
github.com/gohugoio/hugo/commands.(*commandeer).loadConfig.func3()
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/commands/commandeer.go:212 +0x15f
sync.(*Once).Do(0xc4204968b0, 0xc420453a98)
	/build/hugo/parts/go/build/src/sync/once.go:44 +0xbe
github.com/gohugoio/hugo/commands.(*commandeer).loadConfig(0xc4204d08c0, 0xc420490001, 0x4, 0x10)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/commands/commandeer.go:194 +0x570
github.com/gohugoio/hugo/commands.newCommandeer(0x1, 0xc42007c1e0, 0x100b080, 0xc420498690, 0xc4204987b0, 0x0, 0x0, 0x0, 0xd84980, 0xc42001e001, ...)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/commands/commandeer.go:105 +0x141
github.com/gohugoio/hugo/commands.initializeConfig(0xd80001, 0xc42007c1e0, 0x100b080, 0xc420498690, 0xc4204987b0, 0xc420453c08, 0xc420453bd8, 0x0)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/commands/hugo.go:111 +0x76
github.com/gohugoio/hugo/commands.(*commandsBuilder).newHugoCmd.func1(0xc420368a00, 0xc42049df20, 0x0, 0x3, 0x0, 0x0)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/commands/commands.go:151 +0x97
github.com/gohugoio/hugo/vendor/github.com/spf13/cobra.(*Command).execute(0xc420368a00, 0xc42001e0d0, 0x3, 0x3, 0xc420368a00, 0xc42001e0d0)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/vendor/github.com/spf13/cobra/command.go:756 +0x468
github.com/gohugoio/hugo/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420368a00, 0xc420498690, 0xc420174640, 0xc420453ee8)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/vendor/github.com/spf13/cobra/command.go:846 +0x30a
github.com/gohugoio/hugo/commands.Execute(0xc42001e0d0, 0x3, 0x3, 0xc420453f78, 0x40597c, 0xc42002a1d8, 0x0)
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/commands/hugo.go:77 +0xbe
main.main()
	/build/hugo/parts/hugo/go/src/github.com/gohugoio/hugo/main.go:27 +0x7b

I can confirm that this issue affects me as well.
The -t flag for hugo serve is suppose to be passed the name of a theme you want to serve the site with, which will override the set theme name in the Hugo config file. This is no longer working.
I did some testing and this flag broke with the Hugo v0.42 release. Using Hugo v0.41 and below (I tried down to v0.30.1) has the -t flag working.

I also confirm that issue with -t flag

That issue look like a duplicate of #4851

Closing as duplicate of #4851

authors: Hanzei bep felicianotech jygastaud moorereason

repo: gohugoio/hugo


text:
Hugo deploy slow when s3 storing large multipart files

Note this appears to be a somewhat known issue according to the source code comments. Would love to figure out a direction for improving this
What version of Hugo are you using (hugo version)?
I believe this issue exists with any hugo version containing the deploy functionality.
For reference I am using hugo v0.89.4-AB01BA6E+extended
Does this issue reproduce with the latest release?
Yes
What is Hugo Deploy doing?
Hugo deploy does some MD5 compare of remote files and local files to determine differences and whether to upload.
If you have multipart uploads in s3 this results in them not having an MD5 that can be used for comparison. Hugos current solution is for reliability and is to download the file and generate a MD5 of the contents and then compare like usual.
Source Code Example of this Here
What is the problem?
If you have an s3 bucket with many large multipart files then the time to deploy can be very slow. This is because its downloading each of these to create MD5s for comparison.
Include/exclude filters may work to a point but isn't ideal
Solutions
Some suggestions from vangent in an similar issue here  https://github.com/google/go-cloud/issues/1898

One option is to fallback to Size comparison when no MD5 instead of generating.
This might not be as reliable but 99% of the time should work. perhaps this could be an optional flag?

Consider saving an MD5 hash (or any other hash) explicitly in Metadata.
Perhaps a Hugo-Hash attribute is stored on objects and replaces the current obj.MD5 and is used for compare?

@davidejones Was this issue resolved by #9742? The commit message states "improves" but it is not clear to me what remains to be fixed.

@jmooring Yes this issue is resolved by 9742!

authors: davidejones jmooring


text:
tpl/urls: Add JoinPath template function

See https://pkg.go.dev/net/url#JoinPath
Closes #9694

Won't this panic if it gets no arguments? Would it be better to have an error here?

authors: carlmjohnson jmooring


text:
New theme YAMT, but there is a problem

I have made a hugo theme: https://github.com/stkevintan/hugo-YAMT-theme
however,  I have not idea about how to integrated it into these repo, because I'm using gulp to auto control the build progress. gulp can do a lot of things like minify images, add random suffix to static resource paths, create lunr index file for search and so on.

Hello @stkevintan,
first of all thanks for sharing your beautiful theme. The build script for the theme site isn't able to execute gulp scripts, on which your theme depends heavily, during the build process.
This repo adds themes as Git submodules which allow us to specify a different branch than master as source. You could create a dedicated branch, e.g. theme-site-demo, which is solely used for the demo of your theme.
On this branch you can create a folder named exampleSite. If provided, it is used by the build script for the theme site. It mirrors the folder structure of a typical Hugo site and allows you to add custom content, assets etc. to the demo. Hence you can run the gulp command and put all minified and generated files into the corresponding subfoldes of exampleSite.
This allows us to build a theme demo with pre-generated files. gulp would only be executed again, if you change the demo content (causing the lunr index being outdated) or modify your theme heavily.
If you face any problems please let us know.

hi, I finally figure it out , the new theme is renamed to canoe, and the repo url is : https://github.com/stkevintan/canoe
thx for your work!

Thanks for the update Kevin. The demo with the exampleSite folder still builds fine. What's the status of the Lunr-based search?
Btw, I noticed that your theme is linked under it's old name in the footer.

I write a specific lunr index generation script in buildtools\lunr.js , maybe I should make it into a nodejs tools like hugo-lunr
thx ~

@digitalcraftsman  Hi, I finally published the package: https://www.npmjs.com/package/hugo-lunr-zh
Hope this small tool can be helpfull~

@stkevintan any updates here?

@jhabdas Nothing at all. I'm tired to using others tools and I'm trying to code a new blog system on my own.

@stkevintan Currently I am helping out with theme submissions. What is the status of your theme YAMT?
Do you still want it included on the Hugo Themes site?
If no, feel free to close this issue.
If yes, have you looked into the Hugo Themes maintainer's last comment

Everything looks fine. Just the index file for the searching ins't generated. But I let you decide whether you want to include an index for the demo's search.

Please let me know. Thanks!

@onedrawingperday thanks！I'll close this issuse

authors: digitalcraftsman jhabdas onedrawingperday stkevintan

repo: gohugoio/hugoThemes


text:
error in feast_batch-serving and feast_online-serving container when built using docker-compose

I am installing feast using docker-compose and following the step by step guide (batch and online serving), but feast_batch-serving and feast_online-serving container always restarting all the time. I have checked the logs of both containers, and the last logs are here:

Caused by: java.lang.RuntimeException: Unable to read store config at /etc/feast/store.yml
at feast.serving.service.CachedSpecService.readConfig(CachedSpecService.java:181)
at feast.serving.service.CachedSpecService.(CachedSpecService.java:74)
at feast.serving.configuration.SpecServiceConfig.specService(SpecServiceConfig.java:65)
at feast.serving.configuration.SpecServiceConfig$$EnhancerBySpringCGLIB$$ac250397.CGLIB$specService$1()
at feast.serving.configuration.SpecServiceConfig$$EnhancerBySpringCGLIB$$ac250397$$FastClassBySpringCGLIB$$5efcdb08.invoke()
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:365)
at feast.serving.configuration.SpecServiceConfig$$EnhancerBySpringCGLIB$$ac250397.specService()
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
... 54 more
Caused by: com.google.protobuf.InvalidProtocolBufferException: Cannot find field: project in message feast.core.Store.Subscription
at com.google.protobuf.util.JsonFormat$ParserImpl.mergeMessage(JsonFormat.java:1500)
at com.google.protobuf.util.JsonFormat$ParserImpl.merge(JsonFormat.java:1460)
at com.google.protobuf.util.JsonFormat$ParserImpl.parseFieldValue(JsonFormat.java:1993)
at com.google.protobuf.util.JsonFormat$ParserImpl.mergeRepeatedField(JsonFormat.java:1728)
at com.google.protobuf.util.JsonFormat$ParserImpl.mergeField(JsonFormat.java:1661)
at com.google.protobuf.util.JsonFormat$ParserImpl.mergeMessage(JsonFormat.java:1502)
at com.google.protobuf.util.JsonFormat$ParserImpl.merge(JsonFormat.java:1460)
at com.google.protobuf.util.JsonFormat$ParserImpl.merge(JsonFormat.java:1342)
at com.google.protobuf.util.JsonFormat$Parser.merge(JsonFormat.java:477)
at feast.serving.util.mappers.YamlToProtoMapper.yamlToStoreProto(YamlToProtoMapper.java:34)
at feast.serving.service.CachedSpecService.readConfig(CachedSpecService.java:178)
... 66 more

The error said that problem is when reading store config at /etc/feast/store.yml.
I hypothesize that error is in yaml format of redis-store.yml file, i have modified that but i doesn't work. Please help me :)

@frankynapit We will look into this. For the time being, can you use version 0.3.4 instead of latest? (modifiable from .env file)

@frankynapit Found the issue. In redis-store.yml and bq-store.yml, could you change the subscription field to:
`subscriptions:

name: "*"
version: ">0"`

Let us know if you still face difficulty. This should work with the latest image version as well.

hi @khorshuheng, i have tried replacing the subscription as this. but when i run this sample code i got error in applying feature set, it said that:

ValueError: No project found in feature set customer_transactions. Please set the project within the feature set or within your Feast Client.

i have set the project id in bigquery_config bq-store.yml. And when i tried to set project name in feature set, i got this error:

Traceback (most recent call last):
File "main.py", line 43, in
client.apply(customer_fs)
File "/Users/mapan/Documents/franky/gojek_feast/feast/sdk/python/feast/client.py", line 311, in apply
self._apply_feature_set(feature_set)
File "/Users/mapan/Documents/franky/gojek_feast/feast/sdk/python/feast/client.py", line 345, in _apply_feature_set
raise grpc.RpcError(e.details())
grpc.RpcError

The container is stopped restarting,
but when i looking for logging of feast_core_1 container i got this:

08:09:36 [grpc-default-executor-9] ERROR io.grpc.internal.SerializingExecutor - Exception while executing runnable io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1MessagesAvailable@423b774d
io.grpc.StatusRuntimeException: INTERNAL: Invalid protobuf byte sequence
at io.grpc.Status.asRuntimeException(Status.java:521)
at io.grpc.protobuf.lite.ProtoLiteUtils$MessageMarshaller.parse(ProtoLiteUtils.java:218)
at io.grpc.protobuf.lite.ProtoLiteUtils$MessageMarshaller.parse(ProtoLiteUtils.java:118)
at io.grpc.MethodDescriptor.parseRequest(MethodDescriptor.java:289)
at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.messagesAvailable(ServerCallImpl.java:263)
at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1MessagesAvailable.runInContext(ServerImpl.java:686)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.google.protobuf.InvalidProtocolBufferException: Protocol message had invalid UTF-8.
at com.google.protobuf.InvalidProtocolBufferException.invalidUtf8(InvalidProtocolBufferException.java:141)
at com.google.protobuf.Utf8$DecodeUtil.handleTwoBytes(Utf8.java:1909)
at com.google.protobuf.Utf8$DecodeUtil.access$700(Utf8.java:1883)
at com.google.protobuf.Utf8$UnsafeProcessor.decodeUtf8(Utf8.java:1411)
at com.google.protobuf.Utf8.decodeUtf8(Utf8.java:340)
at com.google.protobuf.CodedInputStream$ArrayDecoder.readStringRequireUtf8(CodedInputStream.java:809)
at feast.core.FeatureSetProto$FeatureSetSpec.(FeatureSetProto.java:267)
at feast.core.FeatureSetProto$FeatureSetSpec.(FeatureSetProto.java:220)
at feast.core.FeatureSetProto$FeatureSetSpec$1.parsePartialFrom(FeatureSetProto.java:2297)
at feast.core.FeatureSetProto$FeatureSetSpec$1.parsePartialFrom(FeatureSetProto.java:2291)
at com.google.protobuf.CodedInputStream$ArrayDecoder.readMessage(CodedInputStream.java:888)
at feast.core.CoreServiceProto$ApplyFeatureSetRequest.(CoreServiceProto.java:5693)
at feast.core.CoreServiceProto$ApplyFeatureSetRequest.(CoreServiceProto.java:5646)
at feast.core.CoreServiceProto$ApplyFeatureSetRequest$1.parsePartialFrom(CoreServiceProto.java:6270)
at feast.core.CoreServiceProto$ApplyFeatureSetRequest$1.parsePartialFrom(CoreServiceProto.java:6264)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:86)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:48)
at io.grpc.protobuf.lite.ProtoLiteUtils$MessageMarshaller.parseFrom(ProtoLiteUtils.java:223)
at io.grpc.protobuf.lite.ProtoLiteUtils$MessageMarshaller.parse(ProtoLiteUtils.java:215)
... 9 common frames omitted

I even used the version 0.3.4 of feast, but it gives the same results.
hope you can help me for this :)

Project name is still in active development, and hence, it's only on the master branch but not on any of the stable released branch. This is why the sample code doesn't work when you use the official release images, as the release images is not based on the latest master branch code, but the latest released version (0.3.x in this case). On the other hand, the sample code is meant for master branch only. We planned to release version 0.4.0 soon, which will include project name.
If you don't care about project name functionality, then instead of the sample code, you can use the Jupyter notebook included in the docker compose file to explore Feast's functionality instead: http://localhost:8888/notebooks/feast-notebooks
Alternatively, you can also build the feast images based on the master branch, and use the local image instead of latest official release image. This might be time consuming if you are not familiar with Feast, so we will update the documentation in near future to include steps to build images based on the master branch.

authors: frankynapit khorshuheng

repo: gojek/feast


text:
Update documentation

Add documentation to the repository

lgtm

authors: pradithya tiopramayudi

repo: gojekfarm/jsonpath


text:
Series endpoint with tag filters

We need to have a series endpoint that can filter series based on lists of tags to include & exclude.

https://github.com/gokhanmeteerturk/chatficdb/pull/27

repo: gokhanmeteerturk/chatficdb


text:
Error message for dep init -gopath is misleading

What version of dep are you using (dep version)?
$ cd $GOPATH/src/github.com/golang/dep && git describe --tags
v0.3.2-107-gef6a28f7
What dep command did you run?
dep init -gopath
Full script to replicate the case:
mkdir -p /tmp/gopath/src
export GOPATH=/tmp/gopath
cd /tmp/gopath

mkdir -p src/github.com/user/{foo,bar}
echo "package foo; const Foo = 42" > src/github.com/user/foo/foo.go
echo 'package bar; import "github.com/user/foo"; var Bar = foo.Foo' > src/github.com/user/bar/bar.go

So the GOPATH looks like:
$ tree $GOPATH
/tmp/gopath
└── src
    └── github.com
        └── user
            ├── bar
            │   └── bar.go
            └── foo
                └── foo.go

5 directories, 2 files

Then:
cd src/github.com/user/bar
dep init -gopath -v

What did you expect to see?
My initial expectation was that it should just work and foo version should be just copied from GOPATH as is.
It took me a while to realize that the message Following dependencies were not found in GOPATH actually means could not find the version of package (due to the lack of .git folder). Even after correcting my assumptions, I expected to see error message saying "we found the dependency, but could not figure out its version" or something similar.
I also expected not to see verbose error messages related to the fact that package doesn't exist on github (yet).
What did you see instead?

Misleading error saying "Following dependencies were not found in GOPATH"
Panic stacktrace
verbose errors of unsuccessful attempt to fetch package from network

Output is:
Getting direct dependencies...
Checked 1 directories for packages.
Found 1 direct dependencies.
Searching GOPATH for projects...
no valid source could be created:
	failed to set up "https://github.com/user/foo", error remote repository at https://github.com/user/foo does not exist, or is inaccessible
	failed to set up "ssh://git@github.com/user/foo", error remote repository at ssh://git@github.com/user/foo does not exist, or is inaccessible
	failed to set up "git://github.com/user/foo", error remote repository at git://github.com/user/foo does not exist, or is inaccessible
	failed to set up "http://github.com/user/foo", error remote repository at http://github.com/user/foo does not exist, or is inaccessible
Unable to cache github.com/user/foo
main.(*gopathScanner).scanGopathForDependencies.func1
	/Users/divan/src/github.com/golang/dep/cmd/dep/gopath_scanner.go:197
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:2197
Following dependencies were not found in GOPATH. Dep will use the most recent versions of these projects.
  github.com/user/foo
Root project is "github.com/user/bar"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)	  ← no more versions of github.com/user/foo to try; begin backtrack
  ✗ solving failed

Solver wall times by segment:
     b-source-exists: 4.93581s
         select-root:    241µs
            new-atom:     66µs
               other:      7µs
  b-deduce-proj-root:      1µs

  TOTAL: 4.936125s

no valid source could be created:
	failed to set up "https://github.com/user/foo", error remote repository at https://github.com/user/foo does not exist, or is inaccessible
	failed to set up "ssh://git@github.com/user/foo", error remote repository at ssh://git@github.com/user/foo does not exist, or is inaccessible
	failed to set up "git://github.com/user/foo", error remote repository at git://github.com/user/foo does not exist, or is inaccessible
	failed to set up "http://github.com/user/foo", error remote repository at http://github.com/user/foo does not exist, or is inaccessible

PS.
This issue might be related: https://github.com/golang/dep/issues/1339

Agreed, we should provide a more explicit error message instead of hiding the underlying error. Thanks for the repro steps and detailed output! 💖

For me, the most confusing part was were not found in GOPATH, as I was 100% sure that directory with code is definitely in the GOPATH. So if there is a way to avoid this part of the message for this case, that would be much clearer.

So maybe something like would make more sense:
Following dependencies were not found in GOPATH:
  github.com/doesnt/exist
  github.com/alsodoesnt/exist

Following dependencies found in GOPATH were missing VCS information:
  github.com/user/foo
  github.com/user/bar

Dep will use the most recent versions of these projects.

authors: carolynvs divan zkry

repo: golang/dep


text:
tour: No "Foo"s in the code, little confusing

Context: https://tour.golang.org/basics/3
The left side talks about Foo, FOO and foo but there is none of them in the code in the right side!
Thanks

I'll tackle this one, @adg

I finally looked at this, and this is page 3. We haven't talked about variables or constants or functions yet, so I don't see where it would make sense to add any foos as constants or variables.
I thought about using other constants in the math package to supplement the math.pi -> math.Pi thing, but there are no useful acronyms that would give us an all caps one (math.E almost qualifies, but the lack of subsequent letters is ambiguous).
The time package has some, but they're a bit cryptic if you're not familiar with the whole standards thing (e.g. time.RFC822).
The only other acronym I can think of is io.EOF.
What do you think--abandon the foo, Foo, and FOO for some real constants, adding (somewhat spurious) lines to the code example and change the text to match?

Maybe just pi, Pi, and PI ?

Hah. Yeah, or that :) Damn, you're good!

authors: adg iHani kytrinyx

repo: golang/go


text:
cmd/go: TestGoBuildUmask fails when source tree has a POSIX ACL set

summary
when using POSIX ACL in go source dir, test fail
--- FAIL: TestGoBuildUmask (0.06s)
    go_test.go:252: running testgo [build /tmp/gotest237673041/x.go]
    go_unix_test.go:29: wrote x with mode=-rwxrwxr-x, wanted no 0077 bits

I think the test confuses the differences between the original and the extra permissions
detail
system is Ubuntu 16.04.1 x64
my /usr/local/src dir had been set POSIX ACL sudo group write
sudo setfacl -d -R -m g:sudo:rwx /usr/local/src
sudo setfacl    -R -m g:sudo:rwX /usr/local/src

and my account in sudo group
 » id
uid=1000(zhengkai) gid=1000(zhengkai) groups=1000(zhengkai),4(adm),27(sudo)

getfacl shows:
 » getfacl /usr/local/src
getfacl: Removing leading '/' from absolute path names
# file: usr/local/src
# owner: root
# group: root
user::rwx
group::r-x
group:sudo:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:sudo:rwx
default:mask::rwx
default:other::r-x

I download the newest binary https://storage.googleapis.com/golang/go1.7.3.linux-amd64.tar.gz for build, extract files to /usr/local/src/gobin1.7.3
and clone source
git clone https://go.googlesource.com/go /usr/local/src/go

goto src dir and build ( commit: 2f76c198 )
GOROOT_BOOTSTRAP=/usr/local/src/gobin1.7.3 ./all.bash

fail:
ok      cmd/doc 0.036s
ok      cmd/fix 0.021s
--- FAIL: TestGoBuildUmask (0.06s)
    go_test.go:252: running testgo [build /tmp/gotest237673041/x.go]
    go_unix_test.go:29: wrote x with mode=-rwxrwxr-x, wanted no 0077 bits
FAIL
FAIL    cmd/go  28.873s
ok      cmd/gofmt   0.018s
ok      cmd/internal/goobj  0.014s
ok      cmd/internal/obj    0.002s
ok      cmd/internal/obj/x86    0.002s
ok      cmd/link    0.016s
ok      cmd/nm  0.507s
ok      cmd/objdump 0.813s
ok      cmd/pack    1.016s
ok      cmd/trace   0.004s
ok      cmd/vendor/golang.org/x/arch/arm/armasm 0.004s
ok      cmd/vendor/golang.org/x/arch/ppc64/ppc64asm 0.016s
ok      cmd/vendor/golang.org/x/arch/x86/x86asm 0.110s
ok      cmd/vet 1.246s
ok      cmd/vet/internal/cfg    0.016s
2016/11/14 14:39:38 Failed: exit status 1

if I remove the POSIX ACL settings, everything will be ok
sudo setfacl -b -R /usr/local/src/go

I think the test confuses the differences between the original and the extra permissions

@jessfraz, this seems up your alley?

Sweeet on it

authors: bradfitz jessfraz zhengkai


text:
proposal: context.WithSignal

A common design pattern when building applications is to trap signals, such as CTRL-C, and gracefully close down the application.
One might think this pattern is fairly straightforward and easy to implement. To illustrate the difficulties in getting this pattern correct, let's look at the following example.
In June, @matryer, wrote a blog post demonstrating how to capture signals in your application and use them to gracefully shutdown an application. This post resulted in a fantastic thread on Twitter with @Sajmani and @quentinmit pointing out the mistakes in Mat's code that demonstrate the subtleties in getting the implementation correct .
I propose that this type of cancellation, by signals, should be a part of the context package, as it follows the same idea as cancellation after a certain time, or by a deadline. Not only does this solve the problems with capturing signals that most people make, but, I believe, is another great use case for cancellation via contexts.
An example of this addition to the context package would work is as follows:
func main() {
	ctx, cancel := context.WithSignal(context.Background(), os.Interrupt)
	defer cancel()
	select {
	case <-ctx.Done():
		fmt.Println("thanks for stopping me")
	}
}

And a proposed implementation of the WithSignal function.
func WithSignal(ctx Context, s ...os.Signal) (Context, CancelFunc) {
	ctx, cancel := WithCancel(ctx)
	c := make(chan os.Signal, 1)
	signal.Notify(c, s...)
	go func() {
		select {
		case <-c:
			cancel()
		case <-ctx.Done():
			cancel()
		}
		signal.Stop(c)
	}()
	return ctx, cancel
}

I'd rather have that in the signal package.

What happens when many calls to WithSignal occur in the same context tree?
This feels weird. Context is request scoped but signals are process scoped.
On Sat, 19 Aug 2017, 01:54 Ahmed W. notifications@github.com wrote:

I'd rather have that in the signal package.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21521#issuecomment-323391462, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-G5Nep4WNHIqkNaHaldEaLJwGWBks5sZbOcgaJpZM4O7pnV
.

I use context for commands too, and more and more packages use it for graceful shutdown, even outside of request scope - so it makes sense to me.

On 19 Aug 2017, at 02:57, Dave Cheney notifications@github.com wrote:
What happens when many calls to WithSignal occur in the same context tree?
This feels weird. Context is request scoped but signals are process scoped.
On Sat, 19 Aug 2017, 01:54 Ahmed W. notifications@github.com wrote:

I'd rather have that in the signal package.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21521#issuecomment-323391462, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-G5Nep4WNHIqkNaHaldEaLJwGWBks5sZbOcgaJpZM4O7pnV
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

...but it does feel weird too, I know what you mean.

On 19 Aug 2017, at 02:57, Dave Cheney notifications@github.com wrote:
What happens when many calls to WithSignal occur in the same context tree?
This feels weird. Context is request scoped but signals are process scoped.
On Sat, 19 Aug 2017, 01:54 Ahmed W. notifications@github.com wrote:

I'd rather have that in the signal package.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21521#issuecomment-323391462, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-G5Nep4WNHIqkNaHaldEaLJwGWBks5sZbOcgaJpZM4O7pnV
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I agree that signal.NotifyContext makes more sense than context.WithSignal.
On Sat, Aug 19, 2017 at 1:36 PM Mat Ryer notifications@github.com wrote:

...but it does feel weird too, I know what you mean.

On 19 Aug 2017, at 02:57, Dave Cheney notifications@github.com wrote:
What happens when many calls to WithSignal occur in the same context
tree?
This feels weird. Context is request scoped but signals are process
scoped.
On Sat, 19 Aug 2017, 01:54 Ahmed W. notifications@github.com wrote:

I'd rather have that in the signal package.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21521#issuecomment-323391462,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAAcA-G5Nep4WNHIqkNaHaldEaLJwGWBks5sZbOcgaJpZM4O7pnV

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21521#issuecomment-323537038, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJSK3X0Li_Sy9y2ttGyBLFLxUk1bPIX0ks5sZx0GgaJpZM4O7pnV
.

To echo Dave Cheney's point: Context is request scoped but signals are process scoped.. I'm not sure this makes sense at all.

I'm not sure this proposal makes sense at all.

My use case, and I assume others, is that I have a program that starts a series of goroutines that need cancellation, it also calls functions which accept contexts that allow me to terminate them.
All of these operations are passed a context in order to cancel them, having the context derived from a single context created at application start with a cancel function similar^ to what's described by the OP.
When my program needs to exit, the process manager sends a signal, which is caught by the main package and the top level context is cancelled, propogating this to the goroutines and stopping any long running functions (http requests or commands). WaitGroups then wait until everything has finished successfully and then the program terminates.
This is why I don't understand the comment Context is request scoped but signals are process scoped. My application started a series of routines, is using context as I've described and implemented it like the OP has proposed an incorrect way to safely shutdown?
^ The OP's proposal is correct, my implementation is not, so I'm in favour of adding this to signal package or having a copy/paste example documented.

Is there any reason why context cannot be used at a process level? Obviously the values aren't useful (as far as I can tell), but the cancellation mechanism let's you gracefully shut things down when a program is terminated early, which is very nice.
There are a growing number of packages that use context for cancellation in non-request contexts (anecdotal). It does seem to be becoming the de facto way to gracefully stop things. Has anyone else noticed that?
If context should only be request scoped, then we should start to communicate that. If not, then cancelling with a signal is going to become very common practice.

If several packages handle signals for each packages, and using them, it won't work expectedly. This proposal may provide wrong usages to the developers of third-packages.

Yeah, this would only ever be used in one place, in a command. Probably in func main.
I don't think packages themselves should be trapping signals.

Context is request scoped but signals are process scoped.

The process is a request from the user to the OS.
For example, if I have a cronjob that makes network requests that result in DB transactions, I want to be able to kill it gracefully (and, perhaps more importantly in this example, to set a process-wide deadline if it cannot finish in a reasonable time so it doesn't spin all night).
Having the process be the root of the context tree makes a lot of sense in that situation. It may not always make sense, certainly, but there's nothing unreasonable about this.
I am not convinced that it belongs in stdlib. An example in the docs, a wiki page, a blog post explaining the subtleties involved, or a third-party library all seem reasonable, though.

I think having this in the signal package or in an x package would probably make more sense than having it in the context package.
If anything, I think this issue shines a light on the messaging problem around "context". Should it be used for cancellation? Should it be used for value passing? What is a "request"?
If the pattern of capturing signals and canceling a context from within the main function is a Go anti-pattern, then that needs to be communicated, because that is what is happening in the wild.

All of these operations are passed a context in order to cancel them, having the context derived from a single context created at application start with a cancel function similar^ to what's described by the OP.

I'm not convinced we want to encourage tying contexts to signals in this way, as described above. I appreciate that the code was difficult to get right but all of it was about interacting with the os/signal package, not context. It sounds like maybe we haven't gotten the os/signal API right, or at least easy enough to use. (And that's entirely believable because signals are asynchronous events and those are just hard in general.)
In Mat's post:
func main() {
	ctx := context.Background()

	// trap Ctrl+C and call cancel on the context
	ctx, cancel := context.WithCancel(ctx)
	c := make(chan os.Signal, 1)
	signal.Notify(c, os.Interrupt)
	defer func() {
		signal.Stop(c)
		cancel()
	}()
	go func() {
		select {
		case <-c:
			cancel()
		case <-ctx.Done():
		}
	}()

	doSomethingAwesome(ctx)
}

The part using context is really just one line: ctx, cancel := context.WithCancel(ctx). The hard part is hooking up that cancel function to os/signal. I would focus on what we can do to make that wiring easier - because probably it's too hard to wire to things other than context as well - instead of just solving this problem once inside context but not more generally.
It seems like there is a general problem here that we should solve instead of solving the very specific (and arguably not too useful) one of triggering a context cancellation when an incoming signal arrives.

Also, in func main the code in https://twitter.com/matryer/status/869096368039710720 is completely fine and maybe should have been left as it was. :-)

I would prefer to have an example of correct usage in documentation instead of a new method.

What happens when many calls to WithSignal occur in the same context tree?
This feels weird. Context is request scoped but signals are process scoped.

Good point for me.
Maybe is it better to hang the logic outside the context package? I think it is a more flexible way.
As an example what I use:
https://github.com/kamilsk/semaphore/blob/5c82a8b62d3b3009be756f8f9afaea94b3a89961/context.go#L8-L15
https://github.com/kamilsk/semaphore/blob/5c82a8b62d3b3009be756f8f9afaea94b3a89961/channel.go#L35-L49
it is just 23 lines (7 lines are valuable :)) of code which can be reused and extended as a programmer wants
For instance:
middleware := func(handler http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		ctx := WithInterrupter(r.Context(), Combine(
			WithSignal(os.Interrupt),
			WithEvent(event.UserDeleted, event.UserBanned),
			WithTimeout(service.SLA),
			WithDeadline(startup.Ruin),
		))
		handler.ServeHTTP(w, r.WithContext(ctx))
	})
}

Call the WithTimeout (or WithDeadline) several times does not look strange:
global := func(critical time.Duration, handler http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		ctx, cancel := context.WithTimeout(r.Context(), critical)
		defer cancel()

		handler.ServeHTTP(w, r.WithContext(ctx))
	})
}

search := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
	// config.SearchTimeout < critical, maybe config.SearchTimeout << critical
	ctx, cancel := context.WithTimeout(r.Context(), config.SearchTimeout)
	defer cancel()

	result := doSearch(ctx)
	// write response
})

http.Handle("/search", global(config.SLA, search))

But what about WithSignal?

This is technically a duplicate of #16472, isn't it?

I recently built something on app engine using manual scaling, and semi-infinite running requests that do background tasks. This is another example where, while technically request scoped, it behaves much more like a command.

On 5 Sep 2017, at 21:35, DeedleFake notifications@github.com wrote:
This is technically a duplicate of #16472, isn't it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

It seems like there is a general problem here that we should solve instead of solving the very specific (and arguably not too useful) one of triggering a context cancellation when an incoming signal arrives.

I believe that the general problem here is closely related to the one in https://github.com/golang/go/issues/16620: function calls and channel operations are closely related, but it is often difficult, tedious, or inefficient to convert between the two.
You could imagine a generic (#15292) API for converting channel operations to function calls.
package chanfunc

func Receive(c <-T, f func(T)) {
	for v := range c {
		f(v)
	}
}

Then the boilerplate here would look like:
func main() {
	ctx := context.Background()

	// trap Ctrl+C and call cancel on the context
	ctx, cancel := context.WithCancel(ctx)
	c := make(chan os.Signal, 1)
	signal.Notify(c, os.Interrupt)
	chanfunc.Receive(c, func(os.Signal) { cancel() })

	doSomethingAwesome(ctx)
}

A non-generic version of that would be to build Receive into the Signal package:
package signal

func NotifyFunc(func(os.Signal), os.Signal...)

package main

func main() {
	ctx := context.Background()

	// trap Ctrl+C and call cancel on the context
	ctx, cancel := context.WithCancel(ctx)
	signal.NotifyFunc(func(os.Signal) { cancel() }, os.Interrupt)

	doSomethingAwesome(ctx)
}

This may not be the best solution, but this is definitely a pain point, and is definitely worth further discussion.

I wrote above:

The part using context is really just one line: ctx, cancel := context.WithCancel(ctx). The hard part is hooking up that cancel function to os/signal. I would focus on what we can do to make that wiring easier - because probably it's too hard to wire to things other than context as well - instead of just solving this problem once inside context but not more generally.
It seems like there is a general problem here that we should solve instead of solving the very specific (and arguably not too useful) one of triggering a context cancellation when an incoming signal arrives.

I think we should decline this proposal and leave open the question of addressing os/signal more generally. If anyone wants to make specific concrete proposals about the latter in new issues, please do.

authors: AlekSi DeedleFake OneOfOne Sajmani bcmills bradleyfalzon davecheney jimmyfrasche kamilsk markbates matryer mattn rsc rv-jhester


text:
Not able to install revel on raspberry pi

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.9 linux/arm
What operating system and processor architecture are you using (go env)?
GOARCH="arm"
GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/pi/gocode"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm"
GCCGO="gccgo"
GOARM="6"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build101436108=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
What did you do?
I tried installing revel by go get -u github.com/revel/cmd/revel.
What did you expect to see?
revel installed
What did you see instead?
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5190b8]
goroutine 1 [running]:
cmd/compile/internal/gc.dumpasmhdr()
/usr/local/go/src/cmd/compile/internal/gc/export.go:389 +0x20c
cmd/compile/internal/gc.Main(0x6c5f88)
/usr/local/go/src/cmd/compile/internal/gc/main.go:633 +0x2660
main.main()
/usr/local/go/src/cmd/compile/main.go:49 +0x7c

If this is a first gen rpi, set GOARM=5.

No its not first gen rpi

I can't reproduce any crash on linux/amd64 on neither tip nor 1.10.2. Not even after setting GOARCH=arm.
@sujeet03 have you tried Go 1.10?

authors: kardianos mvdan sujeet03


text:
proposal: x/mod: new repo for module mechanics

For the initial development of module support, we've kept everything in internal directories to make it easier to make changes as our understanding of what the pieces should look like becomes clearer. But now I think the basic pieces have become pretty clear, and we should think about exporting some packages to help other people who want to write tools working directly with module mechanics.
Note that I said "module mechanics". This is about supporting direct manipulation of modules themselves. It is not about supporting general development tools that need to do things like load packages in module mode. That use case, where modules are incidental rather than the focus, should remain in x/tools, specifically x/tools/go/packages. And the specific case of loading packages should still be done by invoking the go command, which will remain the single point of truth for those algorithms.
I propose to create a new repo golang.org/x/mod that will initially contain:

[x] golang.org/x/mod/module

defines type module.Version (struct {Path, Version string}) and !-encoding of paths and versions (from cmd/go/internal/module)

[x] golang.org/x/mod/modfile

go.mod file reader, editor (from cmd/go/internal/modfile)

[x] golang.org/x/mod/semver

semantic version parser (from cmd/go/internal/semver)

[x] golang.org/x/mod/sumdb

go checksum database client and server protocol (from golang.org/x/exp/sumdb/internal/sumweb)

[x] golang.org/x/mod/sumdb/storage

go checksum database storage layer (from golang.org/x/exp/sumdb/internal/tkv, database)

[x] golang.org/x/mod/sumdb/tlog

transparent log (from golang.org/x/exp/sumdb/internal/tlog)

[x] golang.org/x/mod/sumdb/note

signed note formats (from [golang.org/x/exp/sumdb/internal/note] (https://godoc.org/golang.org/x/exp/sumdb/internal/note))

[x] golang.org/x/mod/sumdb/dirhash

definition of h1: directory tree hash used in go.sum file (from cmd/go/internal/dirhash)

[ ] golang.org/x/mod/sumdb/googlecloud...

sub-module with basic google cloud server bindings (from golang.org/x/exp/sumdb/internal/googlecloud...)

[ ] golang.org/x/mod/proxy

go module proxy client and server protocol (like x/mod/sumdb; not written yet)

[ ] golang.org/x/mod/index

go module index client and server protocol (like x/mod/sumdb; not written yet)

[x] golang.org/x/mod/gosumcheck

command: go.sum checker (from golang.org/x/exp/sumdb/gosumcheck)

[ ] golang.org/x/mod/gomodproxy

command: trivial go module proxy for reference and trivial uses (not published yet; maybe also “go mod proxy”)

There's an open issue that this proposal addresses (about exposing some of this stuff) but once again I cannot find it.
/cc @bcmills @jayconrod @ianthehat @myitcv @rogpeppe

There's an open issue that this proposal addresses (about exposing some of this stuff) but once again I cannot find it.

That's #28101.

I propose to create a new repo golang.org/x/mod

Does this proposal include a plan for how the new module, modfile, semver, etc., packages will be kept in sync with the ones in cmd/go/internal/...?

I would assume that they'll be vendored in using go mod vendor.
That does imply that we'll have to have a clean (and perhaps smaller) API boundary between golang.org/x/mod and cmd/go/internal, but that's arguably a good thing anyway.

@dmitshur, yes they would be vendored into cmd/vendor using "go mod vendor".
All the ones I've chosen should already have clean API boundaries, and if not, we'd work on that.

I need quite a few of these in order to support mod files in editors. I have an experiment I have been working on that has them copied to an internal directory of x/tools, but it would be much nicer if I could go straight to using this repository instead.

Consider pseudo-version related logic as well
e.g. https://go.googlesource.com/go/+/refs/heads/master/src/cmd/go/internal/modfetch/pseudo.go

The list of packages above looks good. I expect this will be useful for developing gorelease and a lot of other tools.
I notice that none of internal/modload, internal/modfetch, internal/modfetch/coderepo, internal/mvs are in the list. I think that's the right decision for now -- these are all pretty tightly coupled with cmd/go. It might be worth moving these to x/mod after some refactoring though. I think the proxy and discovery projects have run into use cases where query and download functionality would be useful, and the Go command doesn't do quite what they need.

Sentiment here seems overwhelmingly in favor. Accepting proposal.

Obviously x/mod itself is "unreleased" but it will have effects in the main repo, so milestoned to Go 1.13.

@andybons, I created this repo. Can you take care of adding it to gopherbot, builders, etc.? Thanks.

Everything is set up for x/mod (mirroring, gerritbot, golang.org/x/mod, etc.)

I'm looking for a published library with the types / structures listed in the output of go mod help edit - namely Module, GoMod, Require, and Replace, ideally with the String() methods attached?  Would they be in the new library (x/mod)?

@dmitris Yes, that will be the golang.org/x/mod/modfile package. It hasn’t been added to x/mod just yet.

Do we know when that might happen? This would be very useful for some CI tooling.

Oops! I missed that this was added to the Go1.13 milestone back in May!

This is done.

authors: andybons bcmills dmitris dmitshur hyangah ianthehat jayconrod rsc tsal


text:
runtime: memclrNoHeapPointers: unexpected fault address

Just encountered this crash using go version go1.12.1 openbsd/amd64 on a pure-Go program:

unexpected fault address 0xc02e6ba528
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x2 addr=0xc02e6ba528 pc=0x45a07c]

goroutine 65350 [running]:
runtime.throw(0xccb747, 0x5)
  /usr/local/go/src/runtime/panic.go:617 +0x72 fp=0xc01afe1860 sp=0xc01afe1830 pc=0x42d7b2
runtime.sigpanic()
  /usr/local/go/src/runtime/signal_unix.go:397 +0x401 fp=0xc01afe1890 sp=0xc01afe1860 pc=0x441ff1
runtime.memclrNoHeapPointers(0xc02e6ba528, 0x18)
  /usr/local/go/src/runtime/memclr_amd64.s:142 +0x1dc fp=0xc01afe1898 sp=0xc01afe1890 pc=0x45a07c
runtime.growslice(0xb9fc80, 0x0, 0x0, 0x0, 0x1a8, 0x0, 0x0, 0x3e5398e)
  /usr/local/go/src/runtime/slice.go:178 +0x17b fp=0xc01afe1900 sp=0xc01afe1898 pc=0x44311b
upspin.io/upspin.(*DirEntry).Unmarshal(0xc01afe1ca0, 0xc013798623, 0x267, 0xffd, 0x2, 0x1000, 0x0, 0x0, 0xc01afe1ba0)
  /home/x/src/upspin.io/upspin/code.go:371 +0x706 fp=0xc01afe1a20 sp=0xc01afe1900 pc=0x70b4a6
upspin.io/dir/server/serverlog.(*Entry).unmarshal(0xc01afe1c98, 0xe5c840, 0xc0172620d8, 0xc013798620, 0x1000, 0x1000, 0x3e5398e, 0xc01
  /home/x/src/upspin.io/dir/server/serverlog/log.go:1271 +0x4c6 fp=0xc01afe1c00 sp=0xc01afe1a20 pc=0xaacbb6
upspin.io/dir/server/serverlog.(*Reader).ReadAt(0xc013798600, 0x1ce54185, 0x0, 0xc037579380, 0x2d, 0x0, 0x0, 0x1400, 0x5d23977e, 0xc02
  /home/x/src/upspin.io/dir/server/serverlog/log.go:812 +0x2f4 fp=0xc01afe1c88 sp=0xc01afe1c00 pc=0xaa93a4
upspin.io/dir/server/tree.(*watcher).sendEventFromLog(0xc0038d0a40, 0xe6d320, 0xc01abbd920, 0x1ce2b4e3, 0x527f2b, 0xc00ac3eb01, 0xc000
  /home/x/src/upspin.io/dir/server/tree/watch.go:333 +0x195 fp=0xc01afe1ec8 sp=0xc01afe1c88 pc=0xab86b5
upspin.io/dir/server/tree.(*watcher).watch(0xc0038d0a40, 0xe6d320, 0xc01abbd920, 0x1ce2b4e3, 0x0, 0x0)
  /home/x/src/upspin.io/dir/server/tree/watch.go:371 +0xaf fp=0xc01afe1fb0 sp=0xc01afe1ec8 pc=0xab8baf
runtime.goexit()
  /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc01afe1fb8 sp=0xc01afe1fb0 pc=0x459051
created by upspin.io/dir/server/tree.(*Tree).Watch
  /home/x/src/upspin.io/dir/server/tree/watch.go:171 +0x42b

OpenBSD version is 6.5.  I will try to repro using the latest version of the compiler.

Thanks for the report.
Does it happen reproducibly, or is it hard to reproduce?
Please let us know if it happens with Go 1.12.7 and/or 1.13 beta 1.

authors: dmitshur masiulaniec


text:
x/website: footer text is cut off on smaller viewports

What did you do?

go to https://golang.org/ on mobile

What did you expect to see?

everything well laid out

What did you see instead?

the letter 'R' in 'Report a website issue' is missing
there's no space before the google logo

my phone is iphone SE
browser; chrome

Added NeedsFix but it's unclear what fixed means (perhaps changing the text to be "Report issue" is enough).

authors: andybons komuw


text:
x/tools/gopls: fails on $GOROOT/src/cmd/compile/main.go

Forked from https://github.com/golang/go/issues/32173, which did not have the correct description of the issue.
It seems the gopls works on the other files in the $GOROOT/src/cmd/compile directory, but it does not work on main.go.

Now I can use gopls in vim with ale, but when I run from command line, still got error here
2019/08/14 15:53:56 Info:27.540757ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "builtin", stderr: <<>>
2019/08/14 15:53:56 Info:27.569122ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "list" "-m" "-json" "all", stderr: <<go list -m: not using modules
>>
2019/08/14 15:53:56 Info:20.01199ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "env" "GOPATH", stderr: <<>>
2019/08/14 15:53:56 Info:Build info
----------
version v0.1.3, built in $GOPATH mode

Go info
-------
go version go1.12.7 darwin/amd64

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/arthur/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/arthur/golang"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nh/71f5qs9n3dz3v02z77nc86640000gn/T/go-build059041550=/tmp/go-build -gno-record-gcc-switches -fno-common"
2019/08/14 15:53:56 Info:18.628173ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "list" "-m" "-json" "all", stderr: <<go list -m: not using modules
>>
2019/08/14 15:53:56 Info:22.620565ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "env" "GOPATH", stderr: <<>>
2019/08/14 15:53:57 Info:422.385325ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool", stderr: <<# runtime/cgo
_cgo_export.c:3:10: fatal error: 'stdlib.h' file not found
>>
2019/08/14 15:53:57 Info:394.960683ms for GOROOT= GOPATH=/Users/arthur/golang GO111MODULE= PWD=/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool/main.go", stderr: <<# runtime/cgo
_cgo_export.c:3:10: fatal error: 'stdlib.h' file not found
>>
2019/08/14 15:53:57 Info:go/packages.Load
	package = command-line-arguments
	files = [/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool/main.go]
2019/08/14 15:53:57 Info:go/packages.Load
	packages = 1
/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool/main.go:1003:18-25: undeclared name: GetInfo
/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool/main.go:1003:26-33: undeclared name: id2name
/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool/main.go:1008:20-32: undeclared name: getShardInfo
/Users/arthur/golang/src/icode.baidu.com/baidu/personal-code/bdrp-deploy-tool/main.go:220:3-16: undeclared name: InitDatabases

And the error is not correct, gopls can't find the name in package

@stamblerre do you need more evidence?

after add env CGO_ENABLED=0 env GO111MODULE=on everything gose well.

@arthurkiller: This issue is being tracked here: https://github.com/golang/go/issues/33462. Please file a new issue if you encounter one.

Duplicate of https://github.com/golang/go/issues/35520

authors: arthurkiller stamblerre


text:
x/tools/goimports:unexpected group

What version of Go are you using (go version)?

$ go version
go1.13.4

Does this issue reproduce with the latest release?
yes
What did you do?
I use IDE(goland) to write code，it can auto add import packge to the import section at the last group。
this is the demo code:
package demo

import (
	"fmt"

	"golang.org/x/tools/go/ast/astutil"

	"abc.com/a/d/dao"
	"abc.com/a/d/model"
	"strings"   // IDE auto add it
)

type aliasA  = astutil.ApplyFunc
var aliasB   = dao.Table
var aliasC   = model.Redis

func main(){
	fmt.Println("hello")

	fmt.Println(strings.Join([]string{"hello","golang"}," "))
}

What did you expect to see?

$ goimports -local abc.com/a/d demo.go

package demo

import (
	"fmt"
	"strings"

	"golang.org/x/tools/go/ast/astutil"

	"abc.com/a/d/dao"
	"abc.com/a/d/model"
)

type aliasA = astutil.ApplyFunc

var aliasB = dao.Table
var aliasC = model.Redis

func main() {
	fmt.Println("hello")
	fmt.Println(strings.Join([]string{"hello", "golang"}, " "))
}

What did you see instead?
the strings  is at the wrong group:
package demo

import (
	"fmt"

	"golang.org/x/tools/go/ast/astutil"

	"strings"

	"abc.com/a/d/dao"
	"abc.com/a/d/model"
)

type aliasA = astutil.ApplyFunc

var aliasB = dao.Table
var aliasC = model.Redis

func main() {
	fmt.Println("hello")
	fmt.Println(strings.Join([]string{"hello", "golang"}, " "))
}

if the raw file's import section is like this, goimports can got the right code:
import (
	"fmt"
	"golang.org/x/tools/go/ast/astutil"
	"abc.com/a/d/dao"
	"abc.com/a/d/model"
	"strings"
)

I think this is intended. If your import crosses a newline boundary, it is considered in a separate group. @bradfitz @heschik can confirm.

From what I know, the GoLand IDE does not use goimports directly; it implements its own internal version. If that's the case, in order to change the behavior of GoLand, this issue should be reported to their issue tracker or equivalent.

For some reason，I have disabled the  sorting imports function on the GoLand IDE。
I don't think we need to worry about whether we use ide or not。
We use this tool to fix the wrong group， don't we？

I have updated the issue，deleted description of IDE。
I just have some go files with wrong import group need fix。

Duplicate of #20818.

authors: agnivade dmitshur heschik hidu


text:
net/url: panic in QueryEscape

What version of Go are you using (go version)?

$ go version
go version go1.13.10 linux/amd64

Does this issue reproduce with the latest release?
Unknown. I wish I knew a reproducible test case to try.
What operating system and processor architecture are you using (go env)?
Binary built with:
go env Output
$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build206971722=/tmp/go-build -gno-record-gcc-switches"

Deployed in Docker container running busybox-1.31.1-r9
What did you do?
Our application code called the url.QueryEscape function with some (unfortunately unknown) input string.
What did you expect to see?
Encoded string returned to application code.
What did you see instead?
Panic with the following stack:
	/usr/local/go/src/runtime/panic.go:679 +0x1b2
net/url.escape(0xc000318300, 0x1519bc0, 0x6, 0x0, 0x5)
	/usr/local/go/src/net/url/url.go:328 +0x42a
net/url.QueryEscape(...)
	/usr/local/go/src/net/url/url.go:273
net/url.Values.Encode(0xc000d30db0, 0x4, 0x6)
	/usr/local/go/src/net/url/url.go:930 +0x507
	... application code

Can you show us the output starting from the very beginning?  There is some information missing, and it matters.  You can omit the application code from the stack trace, that is probably not useful.  Thanks.

Fuzzing QueryEscape might surface a reproducer, if that hasn't been tried...

@tomdeering-wf please take a look at Ian's request in https://github.com/golang/go/issues/38643#issuecomment-619270299, the whole trace helps us out and currently we can't act on this issue.
@networkimprov great idea, indeed that seems like the sensible way to find out, would you like to handle that?

Tried this with 1.13.3 on linux/amd64, saw no panic. Maybe memory corruption?
package main

import (
   "net/url"
   "fmt"
)

func main() {
   fmt.Println("4 byte")
   for a := 0; a <= 255; a++ {
      if (a+1) % 8 == 0 { fmt.Println(a) }
      for b := 0; b <= 255; b++ {
      for c := 0; c <= 255; c++ {
      for d := 0; d <= 255; d++ {
         _ = url.QueryEscape(string([]byte{byte(a),byte(b),byte(c),byte(d)}))
      }}}
   }
}

Hi folks, sorry for the delay. Unfortunately I've lost the context beyond what is captured in this issue. We saw this happen once as part of a build in our CI process, and I also am unable to repro locally.
I thought I'd captured all the pertinent info from the stack, sorry Ian. If I'm able to relocate that build, I'll post back with more info.

@ianlancetaylor found it. So, the stack above that was application code catching the panic and re-panicking. The subject of the panic was runtime error: index out of range [59802754] with length 59802754, which seems to have come out of the line t[j+2] = "0123456789ABCDEF"[c&15]. You're right, that does seem very relevant, sorry for the omission :man_facepalming:

Thanks.  Are you parsing URL values that are 59802754 bytes long?
From looking at the code I don't see how this panic could happen other than memory corruption, but I may be missing something.

authors: ianlancetaylor networkimprov odeke-em tomdeering-wf


text:
debug/dwarf: infinite loop in dwarf.New

What version of Go are you using (go version)?

$ go version
go version go1.17.6 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/catena/Library/Caches/go-build"
GOENV="/Users/catena/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/catena/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/catena/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/catena/go/src/github.com/catenacyber/go/src/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/dc1dtf9x2js3v0jx_m010nqr0000gn/T/go-build4237848497=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.17.6 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.6
uname -v: Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
ProductName:	macOS
ProductVersion:	12.2.1
BuildVersion:	21D62
lldb --version: lldb-1316.0.9.41
Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
gdb --version: GNU gdb (GDB) 9.1

What did you do?
Run https://go.dev/play/p/zQRoO7qmvKO
What did you expect to see?
The program finishing and printing somme dummy data
What did you see instead?
timeout running program

Possible fix is
diff --git a/src/debug/dwarf/unit.go b/src/debug/dwarf/unit.go
index 9b3d6e902d..ebd7fe837a 100644
--- a/src/debug/dwarf/unit.go
+++ b/src/debug/dwarf/unit.go
@@ -63,7 +63,7 @@ func (d *Data) parseUnits() ([]unit, error) {
                u := &units[i]
                u.base = b.off
                var n Offset
-               for n == 0 {
+               for n == 0 && b.err == nil {
                        n, u.is64 = b.unitLength()
                }
                dataOff := b.off

cc @neild as we have already been talking about this
Found by https://github.com/catenacyber/ngolo-fuzzing

cc @aclements @thanm

Seems like a variant of #47653.

authors: catenacyber heschi ianlancetaylor


text:
x/crypto/ssh: please provide unified parameter types for ed25519.PrivateKey

Hi,
When I want to use go to do some format cleaning for PEM file found that ssh.ParseRawPrivateKey and x509.MarshalPKCS8PrivateKey have different data type for ed25519.PrivateKey.
ssh.ParseRawPrivateKey actually output a Pointer, x509.MarshalPKCS8PrivateKey only receiver Value.
But other algorithms are both pointers. So I had to do type assertion for ed25519.PrivateKey.
example code:
package main

import (
	"crypto/ed25519"
	"crypto/x509"
	"encoding/base64"
	"encoding/pem"
	"fmt"

	"golang.org/x/crypto/ssh"
)

var pemfile []byte

func main() {
	prikey, err := ssh.ParseRawPrivateKey(pemfile)
	if err != nil {
		panic(err)
	}

	// workaround for golang.org/x/crypto/ssh/ed25519
	ed25519key, ok := prikey.(*ed25519.PrivateKey)
	if ok {
		prikey = *ed25519key
	}

	prikeycontent, err := x509.MarshalPKCS8PrivateKey(prikey)
	if err != nil {
		panic(err)
	}
	block := &pem.Block{
		Type:  "PRIVATE KEY",
		Bytes: prikeycontent,
	}
	prikeypem := pem.EncodeToMemory(block)
	fmt.Printf("prikey: \n%s\n", prikeypem)
}

func init() {
	var err error
	pemfile, err = base64.StdEncoding.DecodeString(samplePem)
	if err != nil {
		panic(err)
	}
}

var samplePem = `LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQkc1dmJtVUFBQUFFYm05dVpRQUFBQUFBQUFBQkFBQUFNd0FBQUF0emMyZ3RaVwpReU5UVXhPUUFBQUNDc1pUcEpXZ0ljajFqcFR0OVJHQ2ovUktCTlJZSTFiWmZDZFJXNCtmNmJ2UUFBQUlqWExVaTYxeTFJCnVnQUFBQXR6YzJndFpXUXlOVFV4T1FBQUFDQ3NaVHBKV2dJY2oxanBUdDlSR0NqL1JLQk5SWUkxYlpmQ2RSVzQrZjZidlEKQUFBRUNPUm12SUdjaDVWMzRqSUpWSGFiU3FQbGl3RGJsL3diamNtNVpmeWZhRjdxeGxPa2xhQWh5UFdPbE8zMUVZS1A5RQpvRTFGZ2pWdGw4SjFGYmo1L3B1OUFBQUFBbmg0QVFJRAotLS0tLUVORCBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0K`

I think it's not necessary. Perhaps we can make x509.MarshalPKCS8PrivateKey receiver ed25519.PrivateKey Pointer and Value at same time or make ssh.ParseRawPrivateKey output Value because ed25519.PrivateKey underlying type is []byte.

Chido

Va

cc @golang/security

It's even a little worse than this: ParseRawPrivateKey returns a value for PKCS8 encodings (because it calls x509.ParsePKCS8PrivateKey) and a pointer for the OpenSSH encoding.
The correct type is definitely the value type, which is what everything else expects, but it might be too late to change ParseRawPrivateKey, since most if not all Ed25519 keys are encoded in the OpenSSH encoding, so applications are probably expecting pointers there.

It goes all the way back to 2016, so applications have surely come to rely on it: https://go-review.googlesource.com/22512
See also https://github.com/golang/crypto/pull/119.

authors: FiloSottile crazysouthern dacapoday seankhliao


text:
cmd/internal/obj: rework stack unwind metadata on LR machines

On LR machines, our function prologue generally looks like (stack bounds check and frame pointer handling omitted): store the LR at -frame_size(SP), then decrement SP to SP-frame_size (if they cannot be done on the same instruction, either due to the lack of the instruction on the architecture or the stack frame too large).
If we decrement the SP first, if a signal arrives immediately after the instruction before saving the LR, the runtime will see the junk value at the LR slot and will fail to unwind the stack. So we store the LR first then decrement the SP.
This generally works. But in some cases if the signal stack is not set (e.g. #53374 , also iOS doesn't support sigaltstack), the signal will arrive on the current stack and the kernel will push the signal frame immediately below the SP, clobbering our saved LR. In those cases we have to store the LR again after decrementing the SP. This makes our function prologue a bit inefficient.
We can avoid the problem if we expand the stack unwind metadata to express "the SP has decremented but the return address is still in the LR register". Currently, the metadata is just about SP delta and the runtime always assumes the return address can be found at 0(SP) (for non-leaf functions). With the expanded metadata, we can decrement SP and then store the LR.
This also makes our prologue more similar to C functions.
I plan to do it in Go 1.20.

Didn't get chance to do it in 1.20. Will do in 1.21.


text:
net/http/fs.go: dirList write hardcode about how to show the satic file list.

What version of Go are you using (go version)?

$ go version
go version go1.20.2 windows/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=D:\workspace\go\bin
set GOCACHE=C:\Users\snowdream\AppData\Local\go-build
set GOENV=C:\Users\snowdream\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=D:\workspace\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\workspace\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.com.cn,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\workspace\go\src\snowdream.tech\snowdream-server\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\SNOWDR~1\AppData\Local\Temp\go-build2673060699=/tmp/go-build -gno-record-gcc-switches

What did you do?

I Try to build a static file web server with gin framework.
https://gin-gonic.com/docs/examples/serving-static-files/
func main() {
	router := gin.Default()
	router.StaticFS("/more_static", http.Dir("my_file_system"))

	// Listen and serve on 0.0.0.0:8080
	router.Run(":8080")
}

I find that:
At last, net/http/fs.go: dirList  function is used to show the satic file list with hardcode.
https://github.com/golang/go/blob/master/src/net/http/fs.go#L153
w.Header().Set("Content-Type", "text/html; charset=utf-8")
	fmt.Fprintf(w, "
\n")
	for i, n := 0, dirs.len(); i < n; i++ {
		name := dirs.name(i)
		if dirs.isDir(i) {
			name += "/"
		}
		// name may contain '?' or '#', which must be escaped to remain
		// part of the URL path, and not indicate the start of a query
		// string or fragment.
		url := url.URL{Path: name}
		fmt.Fprintf(w, "%s\n", url.String(), htmlReplacer.Replace(name))
	}
	fmt.Fprintf(w, "
\n")

What did you expect to see?
I want to customize the page, as i will.
eg. Like Nginx with autoindex on.

What did you see instead?

Duplicate of #29945

authors: seankhliao snowdream


text:
proposal: add Must[T] function

I would like to propose add func Must[T any](v T, err error) T function in Go.  The implementation would be like:
func Must[T any](v T, err error) T {
  if err != nil {
    panic(err)
  }
  return v
}

Motivation
Currently, we have some Must prefix functions in standard libraries.  e.g. regexp.MustCompile, template.Must, netip.MustParseAddr, netip.MustParseAddrPort, etc.
Also, I make a github search to list the functions which with Must prefix. And not surprisingly, most of Must/must functions have similar implementation.
There're two styles Must function: (Option 1 is what I propose)

func Must(v Type, err error) Type

and

func Must(err error)

Most of them just check if err != nil then panic directly.
Before Go 1.18, we didn't have generic, so we need to use MustSomething for each of Something which we want to panic immediately if we got error. Now, we have generic capability, maybe we could make these functions more clear.

@septemhill in which package would you add it, builtin ?

@septemhill in which package would it being added, builtin ?

Actually, I have no idea.
After Go 1.18 introduced generic capability, we could simplify so many exist functions.
But these simplification functions (includes this proposal) just like utilities.
If we accept the proposal, that means we might have more proposals like this one.
So, before we figure out how to classify these functions, I'll suggest put it under golang.org/x/somewhere

Duplicate of #54297

authors: Jorropo seankhliao septemhill


text:
range over func: it is NOT yet permitted to omit unwanted variables

Go version
gotip
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/gaissmai/.cache/go-build'
GOENV='/home/gaissmai/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/gaissmai/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/gaissmai/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/gaissmai/sdk/gotip'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/gaissmai/sdk/gotip/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.23-b384ee7ce Fri Apr 26 18:12:56 2024 +0000'
GODEBUG=''
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/gaissmai/project/rangefunc/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build4171176773=/tmp/go-build -gno-record-gcc-switches'

What did you do?
playing with range over funcs, got the following error:
range over all (value of type func(yield func(a int, b int) bool)) must have two iteration variables
please see the code in the playground: https://go.dev/play/p/HHJaatn3WAl?v=gotip
What did you see happen?
got the compiler error:
./prog.go:14:17: range over all (value of type func(yield func(a int, b int) bool)) must have two iteration variables
What did you expect to see?
no compiler error, the spec says it is allowed to omit unwanted variables:
for x, y := range f { ... }
for x, _ := range f { ... }
for _, y := range f { ... }
for x := range f { ... }
for range f { ... }

Duplicate of #65236

authors: gaissmai seankhliao