Since long I am keeping my go installation up to date by compiling from
source. Today on my attempt to update from 1.14.4 to 1.15 I triggered this
fatal:
GOROOT_BOOTSTRAP=/home/john/opt/go.build/ ./make.bash
Building Go cmd/dist using /home/john/opt/go.build/. (go1.14.4 linux/amd64)
# runti
Jan,
This is fantastic news! Congratulation on hitting such a milestone!
(patiently waiting for the windows and macos)
Andrey
On Wednesday, August 26, 2020 at 3:52:13 PM UTC-6, Jan Mercl wrote:
>
> From the change log (https://godoc.org/modernc.org/sqlite#hdr-Changelog)
>
> 2020-08-26 v1.4.0:
>
I search a lot of for learn every days.
But, often unfortunately displayed a site that contains a malware script
and security alert appear!
I think, "Can't we at least easily check if it's suspicious before we open
it."
I try to implement by Golang..
It's made at 1 week made! I glad easy codi
On Thu, Aug 27, 2020 at 10:01 AM Uday Kiran Jonnala
wrote:
>
> I have a situation on zombie parent scenario with golang
>
> A process (in the case replicator) has many goroutines internally
>
> We hit into panic() and I see the replicator process is in Zombie state
>
> <<>>>:~$ ps -ef | grep repl
Maybe I misunderstood this
>
> The first is the old adage: "Accept interfaces return concrete types."
No interface based design would have you declare a concrete type as the return
value - so it must be declaring a interface return and returning a concrete.
Which is what was being argued aga
On Thu, Aug 27, 2020 at 3:53 AM targe...@gmail.com wrote:
>
> Please don't forget that interface pointer isn't simple. It's a so-called
> "fat pointer" which consists of pointer to data and pointer to methods table.
> Thus, we have 4 potential states - (nil, nil), (nil, pointer), (pointer, nil)
On Thu, Aug 27, 2020 at 12:27 PM Robert Engels wrote:
>
> I think you just made the case... if you have existing code that declares a
> concrete return type and you change that to an interface and nothing else you
> are going to have problems.
I don't think anybody said "..change it to interfac
I think you just made the case... if you have existing code that declares a
concrete return type and you change that to an interface and nothing else you
are going to have problems.
> On Aug 27, 2020, at 12:11 PM, Jake Montgomery wrote:
>
>
>
>
>> On Thursday, August 27, 2020 at 10:45:52
On Thu, Aug 27, 2020, 18:49 Amnon wrote
>
> Just one question.
> How will you track upstream changes in the original C sqlite?
>
That's accomplished at the moment by updating the remote urls at
https://gitlab.com/cznic/sqlite/-/blob/master/generator.go#L203 as well as
the associated directories
On Thursday, August 27, 2020 at 10:45:52 AM UTC-4, burak serdar wrote:
>
> On Thu, Aug 27, 2020 at 6:12 AM 'Axel Wagner' via golang-nuts
> > wrote:
> >
> > On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com > wrote:
> >>
> >> Because you then must remember about this specific case every ti
I have a situation on zombie parent scenario with golang
A process (in the case replicator) has many goroutines internally
1. We hit into panic() and I see the replicator process is in Zombie
state
<<>>>:~$ ps -ef | grep replicator
root 87548 87507 0 Aug23 ?00:00:00 [re
Fantastic work!
And this will be super useful to the community.
I have used sqlite memory dbs for unit tests in the past, and this always
caused me portability pain.
Just one question.
How will you track upstream changes in the original C sqlite?
On Thursday, 27 August 2020 14:24:23 UTC+1, Jan
Hello gophers,
We plan to issue Go 1.15.1 and Go 1.14.8 on Tuesday, September 1.
These are minor releases that include a security fix.
Following our policy at https://golang.org/security, this is the
pre-announcement of those releases.
Cheers,
Roberto and Katie on behalf of the Go team
--
You
* targe...@gmail.com [200827 05:40]:
> On Thursday, August 27, 2020 at 12:20:59 PM UTC+3 axel.wa...@googlemail.com
> wrote:
>> I'm saying the current situation is less confusing than what you
>> describe, yes.
>>
>> AIUI, with what you describe, if I have a variable `x` of type `*T`
>> and an int
>
> Ok, so your data collectors never complete. A simple change to make this
> easier to diagnose is to not spin up another collector controller at the 2
> min mark if the previous has not completed.
>
> I would determine if the stuck collector is BQ or Elastic and check the
> server side logs.
>
W
On Thu, Aug 27, 2020 at 6:12 AM 'Axel Wagner' via golang-nuts
wrote:
>
> On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com
> wrote:
>>
>> Because you then must remember about this specific case every time you cast
>> potentially nil pointer variable to interface. Every time you must write `if
On Thu, Aug 27, 2020 at 2:46 PM Nick wrote:
> I took a little tour around the code, am I correct in thinking that
> it's mostly a clever translation of the C code to Go, using
> generator.go? What is 'ccgo' that seems to be doing all this?
ccgo is a C compiler producing Go code. It's a work in p
Hi,
Some of go tests in src/cmd/go was failing on my machine with SSL
certificate problem. those test trying to do `go get` and `git clone`.
After investigation I found out that in go_test.go file there is a line
doing this:
os.Setenv("HOME", "/test-go-home-does-not-exist")
After commenting this
Quoth Jan Mercl:
> First stable release for linux/amd64. The database/sql driver and its tests
> are
> CGo free. Tests of the translated sqlite3.c library still require CGo.
This is really cool, congratulations!
I'm now going to ask some really ignorant questions, so sorry for
that!
I took a l
(whoops: "I don't run into cases […] very often")
On Thu, Aug 27, 2020 at 2:12 PM Axel Wagner
wrote:
> On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com
> wrote:
>
>> Because you then must remember about this specific case *every time *you
>> cast potentially nil pointer variable to interface
On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com
wrote:
> Because you then must remember about this specific case *every time *you
> cast potentially nil pointer variable to interface. Every time you must
> write `if x != nil { return x; } else { return nil; }` instead of just
> `return x;`
>
> And for different types this is pretty normal as you can have
>x == 0.2 // true
>y = int(x)
>float64(y) != 0.2 // true too
A more correct analogy would've been:
var x := 0.2
var y := float32(x)
math.IsNaN(float64(y)) // true in this analogy
> It is a property of all
On Thursday, 27 August 2020 11:39:11 UTC+2, targe...@gmail.com wrote:
>
> To me, if `x == nil` and then `y != nil` after `y = x` is much more
> confusing.
>
This can happen only if x and y have different types.
And for different types this is pretty normal as you can have
x == 0.2 // true
“Tip” of course :)
> On Aug 27, 2020, at 6:03 AM, targe...@gmail.com wrote:
>
>
> > I'm mostly form C++ land
> from of course :)
>
>> On Thursday, August 27, 2020 at 2:01:33 PM UTC+3 targe...@gmail.com wrote:
>> I know this. I'm mostly form C++ land, so you may imagine how many warts are
>>
Could be a bug in the http/2 implementation. I would disable http/2 and see if
you encounter the problem.
> On Aug 27, 2020, at 6:02 AM, Robert Engels wrote:
>
>
> Ok, so your data collectors never complete. A simple change to make this
> easier to diagnose is to not spin up another collect
Ok, so your data collectors never complete. A simple change to make this easier
to diagnose is to not spin up another collector controller at the 2 min mark if
the previous has not completed.
I would determine if the stuck collector is BQ or Elastic and check the server
side logs.
> On Aug 2
> I'm mostly form C++ land
from of course :)
On Thursday, August 27, 2020 at 2:01:33 PM UTC+3 targe...@gmail.com wrote:
> I know this. I'm mostly form C++ land, so you may imagine how many warts
> are there "on the top of the index finger" :)
> I'm merely speaking against opinion that Shroeding
I know this. I'm mostly form C++ land, so you may imagine how many warts
are there "on the top of the index finger" :)
I'm merely speaking against opinion that Shroedingerface is not a problem
at all.
On Thursday, August 27, 2020 at 1:55:54 PM UTC+3 ren...@ix.netcom.com wrote:
> This will be a G
This will be a Go wart that will never go away. All languages have warts. This
one just happens to be on the top of the index finger There is so little
utility in a nil interface but it’s there.
> On Aug 27, 2020, at 5:14 AM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
>
>> On Thu, Aug 27
> Even though I really don't understand why this isn't just one of those
"you learn about it, you know about it, you never run into any problems
again" type of things.
Because you then must remember about this specific case *every time *you
cast potentially nil pointer variable to interface. Ev
On Thu, Aug 27, 2020 at 11:39 AM targe...@gmail.com
wrote:
> > I'm saying the current situation is less confusing than what you
> describe, yes.
> > AIUI, with what you describe, if I have a variable `x` of type `*T` and
> an interface variable `y`, then `y = x` and `y = (*T)(x)` have different
>
> I'm saying the current situation is less confusing than what you
describe, yes.
> AIUI, with what you describe, if I have a variable `x` of type `*T` and
an interface variable `y`, then `y = x` and `y = (*T)(x)` have different
semantics. I think it is strange to have a conversion of `x` *to i
On Thu, Aug 27, 2020 at 11:10 AM targe...@gmail.com
wrote:
> it would definitely. Though price for consistency looks very much
> acceptable.
I don't think "consistency" is at all the right word here. If anything,
things would get *less* consistent, not more.
> Personally, I would also find it
> This would require to insert extra nil-checks when assigning a
pointer-value to an interface, as the compiler can't know if a pointer is
nil or not.
it would definitely. Though price for consistency looks very much
acceptable.
> Personally, I would also find it very confusing, if converting
On Thu, Aug 27, 2020 at 10:06 AM targe...@gmail.com
wrote:
> Not sure if it was mentioned here, but IMO the main issues isn't nil data
> itself, but how easy it's created. It'd be much less of a surprise if
> creating nil-data required explicit cast from nil struct pointer to
> interface pointer
Not sure if it was mentioned here, but IMO the main issues isn't nil data
itself, but how easy it's created. It'd be much less of a surprise if
creating nil-data required explicit cast from nil struct pointer to
interface pointer and resulted in just nil interface pointer in case of
implicit ca
On Thu, Aug 27, 2020 at 2:12 AM Mandolyte wrote:
> What is the state of Windows/MacOS?
Planned, not started. Collaborators and maintainers of other platforms
are welcome.
> How about Windows Subsystem for Linux?
WSL does not appear on the goosList:
https://golang.org/src/go/build/syslist.go so
37 matches
Mail list logo
