In the Interfaces section of "A Tour of Go" it says
"A value of interface type can hold any value that implements those
methods."
Shouldn't this be
"A variable of interface type can hold any value that implements those
methods."
Jon
--
You received this message because you are subscribed t
haps have write permission to /usr/local/go?
Then there's also the question of why building a Go program should write to
/usr/local/go/pkg/linux_amd64_dynlink.
Jon
On Saturday, August 12, 2023 at 1:01:22 PM UTC-7 Ian Lance Taylor wrote:
> On Sat, Aug 12, 2023 at 10:27 AM jlfo...@berkeley.edu
&
er manually.
I suggest you add this to your test suite.
Cordially,
Jon Forrest
On Friday, August 11, 2023 at 10:00:12 PM UTC-7 Ian Lance Taylor wrote:
> On Fri, Aug 11, 2023 at 6:15 PM jlfo...@berkeley.edu
> wrote:
> >
> > Now that Go 1.21 has been released, I've retu
Now that Go 1.21 has been released, I've returned to trying to figure out
how to
dynamically link a Go program. Back in January I posted the results of my
first attempt
with an earlier version of Go, which was:
1) Building a Go shared library by running
go install -buildmode=shared std
As a beginning Go programmer, I was initially attracted to the short
variable declaration syntax.
It’s great for declaring variables of a simple type. What could be wrong
with letting the Go compiler infer a variable type by looking at what’s
being assigned to the variable, such as:
func ma
You're absolutely right, of course.
Jon
--
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.
To view this discussion on the
Consider the program below.
I want to compute the duration between a time that I put in the
"old_time_str" variable and the current time. If I put the current time in
a string, the program shows the correct duration. If I get the current time
using time.Now() then the duration shown is 7 hours
Shouldn't "term" be included in the list shown on
https://pkg.go.dev/golang.org/x?
Going directly to https://pkg.go.dev/golang.org/x/term appears to work fine.
Jon
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
I have a Mid 2013 Macbook Pro that stopped being supported by MacOS several
releases ago.
I heard about OpenCore, which magically patches the installer for the
current release of MacOS
to run on older hardware. To my utter amazement, it works! I'm now running
the latest version
of MacOS Ventura
Good idea.
FYI - this is on a Fedora 37 6.1.8-200.fc37.x86_64 server with go version
go1.20 linux/amd64.
I'm running a VM in Virtualbox with snapshots so it's very easy to go back
to an unmodified
system after running an experiment. Note that I'm adding the '-a' option to
the go build commands
I agree with you 100%. The 'go install' step that creates the shared
runtime library should only be done by
root.
On the other hand, there's no reason I can see for the 'go build' step to
write anything at all
into /usr/local/go. But that's clearly happening. That's one of the causes
of this pr
Thanks for the comments. I had to do it as root because running
go install -buildmode=shared std
as me results in
go install internal/goarch: mkdir /usr/local/go/pkg/linux_amd64_dynlink:
permission denied
As root, changing the ownership of /usr/local/go/pkg/linux_amd64_dynlink to
me, and then
I'm the original poster. I've looked into this more and I might have an
explanation for
what's going on.
Just for yuks, I started with perhaps the simplest Go program, which I
called t.go:
package main
func main() {
}
As root, I was able to build both a dynamically (21512 bytes) and a
statica
The discussion of SSD wear and tear is going way off my original question.
I'm sorry I even mentioned it.
Can we drop it?
I'm still interested in the answer to the original question, which we've
made some progress in answering.
As of now the answer is yes, subject to some permission and performa
3 at 7:51:25 PM UTC-8 Ian Lance Taylor wrote:
> On Sat, Jan 28, 2023 at 11:27 AM jlfo...@berkeley.edu
> wrote:
> >
> > For people like me who have no intention of ever distributing a Go
> executable, I wonder
> > if it would be useful, and possible, to link to a shared
For people like me who have no intention of ever distributing a Go
executable, I wonder
if it would be useful, and possible, to link to a shared library version of
the Go
Runtime. This would make my binaries much smaller and would reduce ware and
tear on my SSD.
Of course, this presumes that suc
to fix the cyclic dependencies rather than hack
> the go compiler and make it do something it wasn't designed to do?
>
> Best regards,
> Christian
>
> On Tue, Nov 22, 2022, 4:44 PM jlfo...@berkeley.edu
> wrote:
>
>> The reason I'm asking this question is bec
> Put all your package files in a single directory. Or break them up into
> multiple packages.
> That is the way everyone else write Go. If you follow the convention, your
> life will be simpler,
> and your code will be easier for others to understand and maintain.
>
>
> On Tues
Back in June I asked why Go requires all the files in a package to be in
the same
directory. I learned that this is an implementation-specific decision. I
was also referred to
https://stackoverflow.com/questions/45899203/can-i-develop-a-go-package-in-multiple-source-directories
which discusses
On Friday, June 10, 2022 at 8:47:54 PM UTC-7 jlfo...@berkeley.edu wrote:
>
> One hack solution I came up with to break cycles when Package A depends on
> Package B which depends on Package A is to
> create a symbolic link in Package A to the file(s) in Package B that
>
On Friday, June 10, 2022 at 6:48:58 PM UTC-7 ben...@gmail.com wrote:
>
> I agree it might be painful, and might lead to non-idiomatic Go! But it
> sounds like a really good challenge, and will no doubt teach you a lot
> along the way. It looks like you've already learned something from this
>
Thanks for the quick inciteful response.
> From https://go.dev/ref/spec#Import_declarations:
>
> > It is illegal for a package to import itself, directly or indirectly,
> or to directly import a package without referring to any of its exported
> identifiers.
>
>
I should have researched this
I'm having trouble understanding what should be a trivial issue.
I have the following file structure:
.
├── go.mod
├── main.go
├── p1
│ └── p1.go
└── p2
└── p2.go
The files are small and simple.
-- go.mod
module wp
go 1.18
-- main.go
// main.go
package main
import (
"wp/p1"
Other than what's in the Go distribution, I haven't been able to find any
packages for accessing .a archives. Is there anything else out there?
Google wasn't helpful.
Cordially,
Jon Forrest
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To un
the os.FileInfo
> interface. While you can't refer to a private type like os.fileStat there
> is nothing prohibiting the os package from returning a private type that
> satisfies an interface. See, for example,
> https://github.com/golang/go/blob/45f45444b307cea7c8330b100b30
(go version go1.17.7 linux/amd64)
Consider the following trivial program:
--
package main
import (
"fmt"
"os"
)
func main() {
file := "."
fileinfo, _ := os.Stat(file)
fmt.Printf("type of fileinfo = %T\n", fileinfo)
}
--
This runs and produces the
On Sunday, January 9, 2022 at 3:07:18 PM UTC-8 bse...@computer.org wrote:
> Note that a with a map[string]string, the code:
>
> m[s]=s
>
> The contents of the string s are not duplicated, only the string header s
> is.
>
I didn't know this. That's very good to know.
What about this:
package
I'm aware of Artem Krylysov's idea for string interning published on
https://artem.krylysov.com/blog/2018/12/12/string-interning-in-go/
If I understand it correctly, each string is stored twice in a map, once as
a key and once as a value. That means that words that only appear once in
his example
On Sunday, December 19, 2021 at 9:24:00 AM UTC-8 Jan Mercl wrote:
> On Sun, Dec 19, 2021 at 6:03 PM jlfo...@berkeley.edu
> wrote:
> > 1) Let's say I wanted to make the map elements smaller, so the map value
> would be a pointer to a structure, not the structure itself.
Consider the following extremely condensed program:
package main
type func_type func (a string)(out int)
type fte struct {
name string
expand_args bool
function func_type
}
var ft = map[string]fte {
"a":{"a", true, func_a},
};
func func_a(a string
Some people put all their variable declarations at the beginning of a
function.
Others put them at various places in a function, where the variables are
used.
I've always wondered if a variable declaration results in any runtime
overhead.
One obvious concern is what happens if a variable declar
I'm wondering if it would be worth the effort to improve Go's vectorization
optimizations as opposed to creating/improving
its bindings to the various GPUs.
Jon
On Thursday, November 4, 2021 at 7:28:15 AM UTC-7 david@gmail.com wrote:
> On Thu, Nov 4, 2021 at 5:43 AM quin...@gmail.com
> w
You're right, of course. Thanks.
So is it true that package level initializations (that are used) require no
runtime, other than some loader
time to set up?
Jon
On Wednesday, October 27, 2021 at 3:54:08 PM UTC-7 Ian Lance Taylor wrote:
> On Wed, Oct 27, 2021 at 3:34 PM jlfo...@berk
lease
correct me.
Cordially,
Jon Forrest
On Wednesday, October 27, 2021 at 11:58:11 AM UTC-7 Kurtis Rader wrote:
> On Wed, Oct 27, 2021 at 10:49 AM jlfo...@berkeley.edu <
> jlfo...@berkeley.edu> wrote:
>
>> I've noticed that Go doesn't seem to support the intialized .d
I've noticed that Go doesn't seem to support the intialized .data segment
that I used to find on Unix. Is this correct? I've tried using various Go
tools to find out but I'm not sure what I was seeing.
If it isn't supported now, is this something planned for the future?
Cordially,
Jon Forrest
ct.
>
> https://play.golang.org/p/f0x8p_04lP1 ;)
>
>
> On Sun, 2021-10-24 at 16:44 -0700, jlfo...@berkeley.edu wrote:
> > Thanks for the replies.
> >
> > I had been trying to translate the trick from C into Go where you can
> > find how many structures are in an
> unsafe.Sizeof().
>
> The second case (len being the sum of its members' lengths) would require
> recursive calls, and almost surely infinite cycles as we eventually get to
> pointers.
>
> On Sunday, October 24, 2021 at 8:11:37 PM UTC+2 jlfo...@berkeley.edu
> wrote:
>
>&
I noticed that the len() function doesn't take a struct as an argument (see
below).
This is a big surprise. Can someone shed some light on why this restriction
exists?
Cordially,
Jon Forrest
--
package main
import "fmt"
var s struct {
i1 int
i2 int
}
func ma
I'm wondering what the current state of GNU getopt-style Go packages is.
I've done some research and found the following:
DavidGamba / go-getoptions
alecthomas / kong
elegos / flags
jessevdk / go-flags
pborman / getopt
pborman / options
skeeto / optparse-go
spf13 / cobra
subchen / go-cli
tcler /
I've noticed that few, if any, Go programs use Makefiles. Is that because
the overhead of using make is greater than the overhead of just always
compiling and linking everything?
One piece of evidence for this is that the Go compiler leaves no artifacts,
like object files, so as is make wouldn'
windows 10 x86_64
go version go1.15.1 windows/amd64
vscode 1.49.2
vscode go extension 0.17.0
I learned something disappointing about debugging Go from VS Code.
Consider the following trivial program extracted from a larger program:
package main
var gvar int
func main() {
var lvar int
41 matches
Mail list logo
