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
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
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
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
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:
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
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
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:
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
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
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,
> >
>
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
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
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
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
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
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
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 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
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
20 matches
Mail list logo
