On Wed, Mar 24, 2021 at 8:25 PM Kurtis Rader wrote:
> On Wed, Mar 24, 2021 at 7:05 PM awer...@gmail.com
> wrote:
>
>> Oh, we've got another confirmed case of the scary runtime error. I guess
>> now the question is, does anybody know of any memory corruption bugs in
>> macOS and go1.15.5? I
Thank you, looking forward to new Go version with regabi.
在2021年3月25日星期四 UTC+8 上午12:04:39 写道:
> Also, be aware that work that we really hope lands in 1.17 will tinker
> with all the call operations.
>
> The goal is to switch to an ABI that passes parameters to/from calls in
> registers, and
On Wed, Mar 24, 2021 at 9:16 PM Dr. Lincy Jim wrote:
> Yes I am using Go in WSL(Sorry I forgot to mention it)
> go 1.13 version is in Networks
> \\wsl$\Ubuntu\home\lincy\go
>
> but the 1.15 version is in Networks \\wsl$\Ubuntu\user\local (go 1.15
> has been extracted here)
>
> Should i
Hi Kurtis,
Yes I am using Go in WSL(Sorry I forgot to mention it)
go 1.13 version is in Networks
\\wsl$\Ubuntu\home\lincy\go
but the 1.15 version is in Networks \\wsl$\Ubuntu\user\local (go 1.15 has
been extracted here)
Should i manually copy the go 15 folder and place it where go 13 is?
You say you are using Windows 10 but the commands you showed us makes it
clear you are using Go in WSL (Windows Subsystem for Linux) rather than
native Windows 10. I mention this because it is an important detail.
You modify the PATH env var in your current shell but then run `source
~/.bashrc`.
On Wed, Mar 24, 2021 at 3:30 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 11:25 PM Matt Mueller wrote:
>
> > I noticed a lonely BUG comment without an explanation in the flag package:
> > https://github.com/golang/go/blob/master/src/flag/flag.go#L955
>
> Looking at the code
Hi,
My os is windows 10 on which i have installed golang1.16 andd the version
of golang on my vscode is1.13
but since I am using my laptop for work ,i have been asked to upgrade from
1.13 to 1.15
I did the following steps in terminal of vscode-ubuntu
$ sudo wget
On Wed, Mar 24, 2021 at 7:05 PM awer...@gmail.com
wrote:
> Oh, we've got another confirmed case of the scary runtime error. I guess
> now the question is, does anybody know of any memory corruption bugs in
> macOS and go1.15.5? I didn't see anything obvious.
>
I'm unaware of any memory
On Wed, Mar 24, 2021 at 5:04 PM 'Axel Wagner' via golang-nuts
wrote:
>
> I would have thought that by now we've all learned that there is nothing to
> be gained by having this discussion here.
>
> I can't help it though, to point out that this thread started with an
> extremely apolitical
Oh, we've got another confirmed case of the scary runtime error. I guess
now the question is, does anybody know of any memory corruption bugs in
macOS and go1.15.5? I didn't see anything obvious.
runtime: gp: gp=0xc000802900, goid=0, gp->atomicstatus=0
runtime: g: g=0xc000602480, goid=0,
A situation has arisen a few times lately where we've seen segfaults that
have strange looking address values. Another thing that makes the situation
confusing is that the memory referenced by the stack trace should have been
allocated at init time. This seems to only be happening on macOS. The
On Wed, 2021-03-24 at 18:31 -0700, Scott Pakin wrote:
> I just noticed that some of the package comments in the standard
> library are coming from the wrong source file. Here are two examples
> from a golang.org/pkg/ screenshot:
>
>
> In the case of the former, src/os/exec/read3.go appears to be
I would have thought that by now we've *all* learned that there is nothing
to be gained by having this discussion here.
I can't help it though, to point out that this thread started with an
extremely apolitical message, before it got diverted.
I liked Chris's message and would thus like to
I more naturally think of it ('All lives matter) as an emotional or
philosophical statement.
I feel it is absurd and harmful for sloganeering - especially
'language-engineered' sloganeering along the lines of 'have you stopped
beating your wife yet?' - to be promoted on a technical page ; I
On Wed, 2021-03-24 at 22:09 +, alex breadman wrote:
> Let's keep divisive political BS away from this lovely project.
>
> Glad to see the political header removed from the website, at least
> on mobile.
>
> All lives matter.
This too is a political statement.
--
You received this message
On Wed, Mar 24, 2021 at 11:25 PM Matt Mueller wrote:
> I noticed a lonely BUG comment without an explanation in the flag package:
> https://github.com/golang/go/blob/master/src/flag/flag.go#L955
Looking at the code it seems to me that the comment is saying the
_client_ code has a bug in that
I noticed a lonely BUG comment without an explanation in the flag
package: https://github.com/golang/go/blob/master/src/flag/flag.go#L955
I did a quick `git blame` and it goes all the way back to the initial
commit:
https://github.com/golang/go/commit/ac0dd5ae525db0d057e94c03c3f506bc30afae31.
I'm not a go-mobile contributor, but since the repository is only mirrored
on GitHub and hosted elsewhere I'm not sure if GitHub Actions would be the
right choice. I think they'd reach a CI tool that can have its results
appear both on GitHub and on googlesource.com.
On Mon, Mar 22, 2021 at 8:48
Thanks Carmen, and others on the CoC committee. I don't think anyone would
say the work you do is fun, but whenever we get these rashes of toxic
behavior on the mailing list or on GitHub, it makes me glad the CoC exists.
On Tue, Mar 23, 2021 at 7:01 AM 'can...@google.com' via golang-nuts <
Let's keep divisive political BS away from this lovely project.
Glad to see the political header removed from the website, at least on
mobile.
All lives matter.
On Wed, 24 Mar 2021, 8:41 pm Chris Burkert, wrote:
> Several messages during the last weeks irritated me and I guess I was not
> the
On Wed, Mar 24, 2021 at 3:18 PM ben...@gmail.com wrote:
> I'm comparing to various legal systems, in which there is almost always
> the possibility of appeal, even for heinous crimes.
>
Not forever; and especially not in cases of abuse of process. For example,
the United States Supreme Court
Several messages during the last weeks irritated me and I guess I was not
the only one. Eventually we are all humans but often enough we don’t treat
ourselves like that. Let’s treat machines like machines and humans like
humans - not the other way round.
That’s why I want to say “Thank you
Fair response - pragmatic and helpful. Thanks, Ian. -Ben
On Thu, Mar 25, 2021 at 8:34 AM Ian Lance Taylor wrote:
> On Wed, Mar 24, 2021 at 12:19 PM ben...@gmail.com
> wrote:
> >
> > > permanent bans were given to multiple individuals, with no possibility
> for appeal
> >
> > I don't disagree
On Wed, Mar 24, 2021 at 12:19 PM ben...@gmail.com wrote:
>
> > permanent bans were given to multiple individuals, with no possibility for
> > appeal
>
> I don't disagree with the bans, but this part -- the "no possibility for
> appeal" seems very ... totalitarian. What if a mistake was made?
> permanent bans were given to multiple individuals, with no possibility
for appeal
I don't disagree with the bans, but this part -- the "no possibility for
appeal" seems very ... totalitarian. What if a mistake was made? (Again,
not saying it was here, but in general, to err is human.) I'm
On Wed, Mar 24, 2021 at 11:18 AM Shiva wrote:
>
> Thank you for that, Ian.
>
> Just to confirm, I see the following -
>
> *_linux.c,
> *_linux.h,
> *_linux.go,
> *_linux.s,
> *_linux.pl
>
> They are in different directories - crypto, internal\syscall, net, os,
> runtime, sync\atomic and syscall
Thank you for that, Ian.
Just to confirm, I see the following -
*_linux.c,
*_linux.h,
*_linux.go,
*_linux.s,
*_linux.pl
They are in different directories - crypto, internal\syscall, net, os,
runtime, sync\atomic and syscall under the src directory. But you had
earlier mentioned only
That is, you're sending the SIGTERM via systemd?
Is it possible that systemd is sending it to the whole process group, and
not just to the parent? Is systemd running the go command directly, or via
a shell?
If you want to be 100% sure, you can start the children in separate process
groups.
Thanks to both you and jake!
I remembered something similar to "import path should not be relative
paths". (Otoh the replace directive is not an import path, so I should
have checked before asking this.)
Anyways, thanks again!
On 3/24/21, Amnon wrote:
> You can just tar up your ~/go/pkg/mod
I have a series of web pages generated from a template in OCaml and Perl
that I am able to express succinctly as a template in Go to replicate the
style of for my new implementation.
However, I'd like to do the "inverse" of that template and read a page back
into a struct of data, allowing me to
You can just tar up your ~/go/pkg/mod directory (plus your own sources) and
you will be good.
On Wednesday, 24 March 2021 at 16:19:13 UTC jake...@gmail.com wrote:
> > I believe I can't use replace?
>
> I'm glad the vendoring solution is what you want. But IIUC what you are
> trying to do,
> I believe I can't use replace?
I'm glad the vendoring solution is what you want. But IIUC what you are
trying to do, then there is no reason you can not use replace. For example:
require gergrly/otherpackage v0.0.0
replace gergrly/otherpackage => ../otherpackage
This works for me. You
Also, be aware that work that we really hope lands in 1.17 will tinker with
all the call operations.
The goal is to switch to an ABI that passes parameters to/from calls in
registers, and the way
that ends up expressed in SSA is that first (and we do this part in 1.16)
the parameters to the
Hi from group newbie,
If anyone's interested I wrote a SSH client with go that allows to copy
your configuration files and environment variables to the remote while you
connect.
You can find the tool from https://github.com/drodil/envssh and I made also
short demo of the tool to Youtube
Elaborating on the previous answer, which led me to the source of the issue
I'm facing but did not quite solve the problem.
In case you have no control over the server, you are using private CA, and
the server does not include Certificate Authorities
On 3/23/21 11:59 PM, Kurtis Rader wrote:
> It sounds as if you might be running your "REST endpoint" program from
> an interactive shell (i.e., a terminal) and sending SIGTERM by
> pressing something like Ctrl-C. Interactive job control, which
> includes how signals generated by a "terminal" are
Thanks, that's exactly what I was looking for!
For the next go programmer looking for a solution in similar situation:
on page https://golang.org/ref/mod#vendoring
"... or to ensure that all files used for a build are stored in a
single file tree"
On 3/24/21, Miguel Angel Rivera Notararigo
You can use the vendor folder, just copy (or symlink, but you will need to
keep them updated) what you need there and will work.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it,
Yes, and... (just in case someone else comes across this thread wondering
in the distant future) ,
func(v T) T is not too big a problem but func(v T) R
If the function body has cases, i.e. flow sensitive, that's where the
brackets are mandatory to make the inference more straightforwardly
Sorry I forgot 1 more expectation/boundary condition: I'd like to be
able to tar both go code in the local filesystem and the referenced go
packages in the local filesystem and copy it to a different OS to
different absolute paths?
I believe I can't use replace?
On 3/24/21, fge...@gmail.com
Assuming GO111MODULE=on, if I don't want to publish anything and I
only want to build go code in the local filesystem, referencing only
go packages in the local filesystem.
Can I do that without local version control software and a private module proxy?
After reading most module documentation on
I agree here that there is a lot of repetition in the function definitions
of let's say a generic math package:
types Numbers { type float32,float64, }
func Abs[T Floats](a T) T {}
func Sin[T Floats](a T) T {}
func Cos[T Floats](a T) T {}
etc. (50 orso more?)
It feels a bit redundant and
Thank you Keith for clarification. It's really of great help.
Ge
在2021年3月24日星期三 UTC+8 上午7:45:13 写道:
> On Tuesday, March 23, 2021 at 9:11:13 AM UTC-7 Ge wrote:
>
>>
>> Hi,
>> Recently I encountered a problem which seems to be related to SSA
>> optimization
>> and feels hard to figure out what
43 matches
Mail list logo