On Sat, Nov 17, 2018 at 6:15 PM Justin Israel
wrote:
>
>
> On Sat, Nov 17, 2018 at 6:06 PM Robert Engels
> wrote:
>
>> I think that is incorrect. The vendoring was a way to ensure certain
>> dependencies remained constant. The modules should eliminate that, barring
>> deletion of the source repo
On Sat, Nov 17, 2018 at 6:06 PM Robert Engels wrote:
> I think that is incorrect. The vendoring was a way to ensure certain
> dependencies remained constant. The modules should eliminate that, barring
> deletion of the source repo.
>
Even with modules, vendoring is still useful for situations wh
I think that is incorrect. The vendoring was a way to ensure certain
dependencies remained constant. The modules should eliminate that, barring
deletion of the source repo.
> On Nov 16, 2018, at 11:00 PM, Justin Israel wrote:
>
>
>
>> On Sat, Nov 17, 2018 at 5:34 PM Henry wrote:
>> Hi,
>>
On Sat, Nov 17, 2018 at 5:34 PM Henry wrote:
> Hi,
>
> It seems to me that go modules and vendor attempt to solve the same
> problem. I wonder whether we should just choose one and scrap the other, or
> find a way to consolidate them under a single unified feature.
>
Comparing "modules" and "ven
Hi,
It seems to me that go modules and vendor attempt to solve the same
problem. I wonder whether we should just choose one and scrap the other, or
find a way to consolidate them under a single unified feature. I am a bit
concerned with the direction Go is going. People keep adding stuffs into
It seems like http.Client's CheckRedirect hook only populates the
via[n].Response for n>0 (i.e., not for the first hop). This is useful if,
for instance, you want to check the status code (301, 302, etc) of each
redirect.
Here's a playground demo: https://play.golang.org/p/cKoWVhdjKwf
I can file
On Fri, 16 Nov 2018, at 6:05 PM, Wagner Riffel wrote:
> I'm either on 60.3 under linux and it's working fine.
OK thanks, it must be something on my system
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
The 512GB heap limit was removed in go 1.11. Here's the commit that
did it, it has some additional information:
https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsub
This article
https://syslog.ravelin.com/further-dangers-of-large-heaps-in-go-7a267b57d487
would imply it is far less than that.
I responded that something didn’t feel right, but maybe Gos lack of
generational GC is a real stumbling block here.
> On Nov 16, 2018, at 11:58 AM, Matthew Zimmerma
I'm either on 60.3 under linux and it's working fine.
On Fri, Nov 16, 2018 at 1:25 PM Sam Whited wrote:
>
> FWIW, I'm on 65 nightly and haven't noticed any problems (including back when
> 63 was the nightly release).
>
> —Sam
>
> On Fri, Nov 16, 2018, at 09:22, Ian Davis wrote:
> > Hi all,
> >
>
What are the current memory limits? I know it used to be 512gb. Is there
a difference between the platforms? I couldn't find documentation on this.
Thanks!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and sto
FWIW, I'm on 65 nightly and haven't noticed any problems (including back when
63 was the nightly release).
—Sam
On Fri, Nov 16, 2018, at 09:22, Ian Davis wrote:
> Hi all,
>
> Since upgrading to Firefox 60.3 on Linux I am unable to view any pages
> on https://go-review.googlesource.com/ and I w
Hi all,
Since upgrading to Firefox 60.3 on Linux I am unable to view any pages on
https://go-review.googlesource.com/ and I wondered if anyone else was seeing
this problem or if it's an issue with my setup?
Chromium renders the pages fine. When I view source with Firefox I see the
following:
Just remember that changing from unbuffered to buffered to make something work
may just be hiding the problem and it will surface again in other situations.
> On Nov 16, 2018, at 8:33 AM, sivasothy shanmugalingam wrote:
>
> Thanks, I used one channel that is blocking. I found error and correc
Thanks, I used one channel that is blocking. I found error and correct it
On Fri, Nov 16, 2018 at 3:31 PM Vladimir Varankin
wrote:
> I believe, "runtime.chanrecv1" is the receiving part of a channel. From
> what you've described, it sounds like you have a dead-lock somewhere.
>
> In your "out.sv
I believe, "runtime.chanrecv1" is the receiving part of a channel. From
what you've described, it sounds like you have a dead-lock somewhere.
In your "out.svg" diagram check what functions are dominating around
channel read and check if dead-lock is there.
On Thursday, November 15, 2018 at 6:
On Fri, Nov 16, 2018 at 2:40 PM Juan Mamani
wrote:
> Why can not access global var MyGlobalVar? Any idea?
Go has no global scope. It has universe scope, but you cannot define
anything there. `MyGlobalVar` has package scope. To access an exported
identifier imported from pacakge foo, you must use
The sample code:
// main.go in varglobal/
package main
import(
"fmt"
"varglobal/db"
)
var MyGlobalVar string ="Any value :)"
func main(){
db.TryDisplayMyVar()
}
// db.go in varglobal/db/
package db
import "fmt"
func TryDisplayMyVar(){
fmt.Println("Val
Jajajajjjajajajaj let me commit a big LOL!!
El vie., 16 nov. 2018 a las 0:29, Chris FractalBach ()
escribió:
> It reached it's "golden years"
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receivi
On Thu, 2018-11-15 at 14:20 +, Paul Jolly wrote:
[…]
> > The update rewrites non-canonical version identifiers to semver form,
> > so A's v1 becomes v1.0.0 and E's dev becomes the pseudo-version for the
> > latest commit on the dev branch, perhaps v0.0.0-20180523231146-
> > b3f5c0f6e5f1.
It is
20 matches
Mail list logo
