OK. Now I understand. Thanks for all replies.
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop recei
Kazuya,
That makes no sense.
The main package is the point of entry to an executable. This is where
things happen.
You create packages that are able to do things and you use them in the main
package to some purpose.
It's going against to the reason why packages are there.
What you're asking is
On Thu, Jan 24, 2019, at 07:00, 伊藤和也 wrote:
> Is it possible?
> package main
>
> var Number int = 100
> func main() {}
>
> package hello
>
> import "fmt"
>
> func abc() {
>fmt.Println(Number)
> }2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
> > package main
> >
> > var Number int = 100
> >
> > func
When i debug go func() with dlv, use s to go into but not exec.
Who is familiar with dlv debugging go source code？
thanks！
package main
import "fmt"
func main() {
a := make(chan int)
go func() {
a <- 1
}()
for {
select {
case i, ok := <-a:
Is it possible?
package main
var Number int = 100
func main() {}
package hello
import "fmt"
func abc() {
fmt.Println(Number)
}
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
You received this message because you are subscribe
The question is what you are trying to accomplish - if you want two main
packages share variables you could make a third package and have both main
packages import that.
/M
Den 24. jan. 2019 kl. 07.40 skrev 伊藤和也
mailto:kazya.ito.dr...@gmail.com>>:
What Francisco Dalla Rosa Soares says is righ
What Francisco Dalla Rosa Soares says is right. I only compiled "b.go". Is
it possible to import "main" package to other packages except "main"?
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
You received this message because you are
Are you compiling both files together?
a.go
package main
var Number int
-
---b.go
package main
import "fmt"
func main() {
Number = 1
fmt.Println(Number)
}
-
go build a.go b.go
On Thu, Jan 24, 2019 at 3:16 PM Michael Banzon wrote:
> Can you provide the out
Can you provide the output you get and the source you are compiling?
If you could also include the command line input+output it would probably help.
/M
Den 24. jan. 2019 kl. 07.13 skrev 伊藤和也
mailto:kazya.ito.dr...@gmail.com>>:
Now I tried to use "Number" in the same package "main" in a differe
Now I tried to use "Number" in the same package "main" in a different .go
file in the same directly but I got the compile error "undefined: Number".
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
You received this message because yo
packages have nothing to do with files, if you are on some directory you
don't need to import any package, just use Number on other files
On Thu, Jan 24, 2019, 3:36 AM 伊藤和也 wrote:
> I couldn't import "main" package to other packages to use the variable
> "Number" and I try to use "Number" in ma
I couldn't import "main" package to other packages to use the variable
"Number" and I try to use "Number" in main package of different .go file
in the same directory but I couldn't.
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
Yo
Yes, you can export a variable from the main package. It's not very
useful, since normally nothing will import the package, but you can do
it if you want.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and st
thanks lan.
在 2019年1月23日星期三 UTC+8下午11:26:57，Ian Lance Taylor写道：
>
> On Tue, Jan 22, 2019 at 11:47 PM >
> wrote:
> >
> > i got :
> > # command-line-arguments
> > ./key.go:6:18: invalid operation: F() == F() (func can only be compared
> to nil)
>
> Yes, that is what the language spec says a
package main
var Number int = 100
func main() {
}
--
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, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options,
Got it, thanks.
On Wed, Jan 23, 2019 at 6:41 PM Julie Qiu wrote:
>
> We will not be updating the archives for this release. The reason is because
> these directories do not affect functionality, and we do not want to risk the
> availability of the security release, nor we want to change the con
We will not be updating the archives for this release. The reason is
because these directories do not affect functionality, and we do not want
to risk the availability of the security release, nor we want to change the
contents of already published archives.
Julie
On Wed, Jan 23, 2019 at 8:00 PM
sorry to be a bother, but are you publishing new archives? will you
publish new hashes for the archives with the commands executed thusly?
On Wed, Jan 23, 2019 at 5:12 PM Julie Qiu wrote:
>
> Hello gophers,
>
> Due to an issue with the release tooling (https://golang.org/issue/29906),
> go1.11.5
Go efficient text segmentation; support english, chinese, japanese and
other.
https://github.com/go-ego/gse/releases/tag/0.30.0
--
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,
Hello gophers,
Due to an issue with the release tooling (https://golang.org/issue/29906),
go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two
unnecessary directories in the root of the archive: "gocache" and "tmp".
They are harmless and safe to remove.
The following commands
The release tarballs include two new directories: "gocache" and "tmp".
Any special reason for that?
--
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, send an email
to golang-nuts+un
Hi gophers,
We have just released Go 1.11.5 and Go 1.10.8 to address a recently
reported security issue. We recommend that all users update to one of these
releases (if you’re not sure which, choose Go 1.11.5).
This DoS vulnerability in the crypto/elliptic implementations of the P-521
and P-384 e
* 伊藤和也 [190123 00:27]:
> I found the explanation "All types implement the empty interface".
> https://golang.org/ref/spec#Interface_types
> So an empty interface also implements an empty interface? and again the
> empty interface implements an empty interface and the empty inter...
> What I i
On Tue, Jan 22, 2019 at 11:47 PM wrote:
>
> i got :
> # command-line-arguments
> ./key.go:6:18: invalid operation: F() == F() (func can only be compared to
> nil)
Yes, that is what the language spec says and it is what I said: in Go,
function values are not comparable.
I wrote that code as an
Thanks for the suggestions. Sadly, the race detection doesn't work on ARM
platforms. I'll try adding tracing as you suggest and see what comes of it.
On Tuesday, 22 January 2019 16:18:17 UTC, robert engels wrote:
>
> Sounds a lot like a concurrency issue - possibly not flushing the request,
>
(Pardon, please ignore the previous message, it should have been private.)
Le mer. 23 janv. 2019 à 13:58, Marko Ristin-Kaufmann
a écrit :
> Hi Scott,
> Could you describe a bit in more detail what needs to be done and how
> often? Are there any knowledge requirements?
>
> I already develop githu
Hi Scott,
Could you describe a bit in more detail what needs to be done and how
often? Are there any knowledge requirements?
I already develop github.com/Parquery/gocontracts and I am quite interested
in the topic so I might be a potential candidate.
Cheers Marko
Le mer. 23 janv. 2019 à 10:20, S
On Wednesday, 23 January 2019 13:31:13 UTC+1, Victor Giordano wrote:
>
> You wrote
>
>
>> All nil values are perfectly defined: they are the zero value of the
>> particular type.
>
>
> As i see things the nil is the *default value* for the pointers. If you
> want to call it "zero value" to th
On Wed, Jan 23, 2019 at 1:30 PM Victor Giordano
wrote:
> You wrote
>
> All nil values are perfectly defined: they are the zero value of the
particular type.
>
> As i see things the nil is the default value for the pointers. If you
want to call it "zero value" to the default is up to, for me doesn
Thanks Ivan. Good to know this.
So the answer to my question is just about, like Ian said, confusion for
readers?
Am Mi., 23. Jan. 2019 um 12:15 Uhr schrieb Ivan Fraixedes :
> Perhaps
>
> There is a handy exception, though. When the value is addressable, the
>> language takes care of the commo
You wrote
> All nil values are perfectly defined: they are the zero value of the
> particular type.
As i see things the nil is the *default value* for the pointers. If you
want to call it "zero value" to the default is up to, for me doesn't work
like that. For me "zero" (0) is a value and "nil"
On Wed, Jan 23, 2019 at 1:09 PM Victor Giordano
wrote:
> 0 != nil
I don't understand what is has to do with what I wrote. Your example is not
a valid Go expression. Not all types have nil values.
Let me reiterate: A nil value of a type is always equal to the zero value
of that type. Because zer
0 != nil
El mié., 23 ene. 2019 a las 9:08, Jan Mercl (<0xj...@gmail.com>) escribió:
> On Wed, Jan 23, 2019 at 12:45 PM Victor Giordano
> wrote:
>
> >> All nil values are perfectly defined: they are the zero value of the
> particular type.
> >
> > Just to point.. .zero is value different that nil
On Wed, Jan 23, 2019 at 12:45 PM Victor Giordano
wrote:
>> All nil values are perfectly defined: they are the zero value of the
particular type.
>
> Just to point.. .zero is value different that nil.
Not sure what's meant by this. When is a nil value of a type different from
its zero value?
--
El martes, 22 de enero de 2019, 10:23:36 (UTC-3), Jan Mercl escribió:
>
> On Tue, Jan 22, 2019 at 2:17 PM Victor Giordano > wrote:
>
> > From a language specific level (higher abstraction) is means undefined,
> is the absence of a value.
>
> No value in Go can _not_ have a value.
>
> > Somethi
I was giving an interpretaion about the meaning of nil from different
pespectives
El martes, 22 de enero de 2019, 10:23:36 (UTC-3), Jan Mercl escribió:
>
> On Tue, Jan 22, 2019 at 2:17 PM Victor Giordano > wrote:
>
> > From a language specific level (higher abstraction) is means undefined,
> i
Perhaps
There is a handy exception, though. When the value is addressable, the
> language takes care of the common case of invoking a pointer method on a
> value by inserting the address operator automatically. In our example, the
> variable b is addressable, so we can call its Write method wi
Hello Gophers,
Some time ago, I started the go-formal github organisation as a place for
formal analysis tools in and for Go.
I am looking for a volunteer to take over ownership of the github
organisation go-formal as I will be unable to that role starting
in the coming weeks.
The administrat
Why is that a problem? I can indeed call it on value (at line 20). I got
result:
>
> hello
> hello
> Program exited.
>
>
I am now more confusing when I come to
https://golang.org/doc/faq#different_method_sets.
Am Mi., 23. Jan. 2019 um 06:47 Uhr schrieb Andrei Avram <
andrei.avram@gmail.com>:
On the other side maybe confusion on the part of code writers if they use
pointer receiver because of consistency instead of needing it?
Am Mi., 23. Jan. 2019 um 00:01 Uhr schrieb Ian Lance Taylor :
> On Tue, Jan 22, 2019 at 1:59 PM Xinhu Liu wrote:
> >
> > In "A Tour of Go" I read:
> >
> >> In
40 matches
Mail list logo
