[go-nuts] x/mobile: log skipped functions and variables to console

[Federico Bond]

x/mobile adds comments to the generated bridge source when a function or 
variable has an unsupported type and thus cannot be correctly bridged. No 
indication is given in the console output of gomobile that this has 
happened though, forcing devs to look at the actual generated code to find 
out why some function or field/variable is missing.

It would be nice for gomobile to log these when calling the gomobile bind 
command. A simple log message should suffice in most cases, but a future 
extension could add a strict mode option and fail the compilation if any of 
these problems is found.

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/694a8579-3623-44ea-90cf-3d0697c26252n%40googlegroups.com.

[go-nuts] Re: Why we don't have simple throws error statement

[Brian Candler]

On Friday, 31 July 2020 15:06:33 UTC+1, semi...@gmail.com wrote:
>
> I know, there are so many discussion about error handling. I read tons of 
> idea about that. Looks like most of idea rejected from community but every 
> idea brings our goal closer.
>

The more I use go's existing error handling, the more I like it.

It's clear and it's explicit.  Could a function return an error, or not? 
It's right there in the function signature.  It's something you can't 
ignore.

foo := func()// fails to compile if foo returns two values
foo, err := func()   // OK, but will fail if you don't use the 'err' 
value
foo, _ := func() // explicitly ignore the error: a big code smell 
signal
 
You then make a decision as to what to do.  Should I just return from my 
own function and let the error propagate up unchanged?  Should I propagate 
a new error which wraps or replaces the original error?  Should I do 
something else?

There have been dozens of proposals for changing it, and I've not seen one 
which is as clear or as simple.

For your "throws func" - you didn't describe the semantics.  I am guessing 
it is intended to be equivalent to the following?

func myFileRDWRFunc(filename string) (string, error) {
f, err := os.OpenFile(filename, os.O_RDWR, 0600)
if err != nil { // backward compatibility (??)
return "", err
}

err = f.WriteString("anystring")
if err != nil {
log.Println(err)
f.Close()
return "", err
}

err = f.Seek(0, 0)
if err != nil {
log.Println(err)
f.Close()
return "", err
}

b, err := ioutil.ReadAll(f)
if err != nil {
log.Println(err)
f.Close()
return "", err
}

return string(b), nil
}

That is: I think you're saying IF there's a multi-valued function return, 
AND the last value is an error, THEN it will silently consume that value, 
and jump to the handler if not nil.  Is that correct?  What about functions 
which return multiple values but the last one is not an error?  What 
happens if the handler doesn't have a "return" statement - does it continue 
where it left off??

Aside: I don't think putting f.Close() in the error handler is right.  
There should be "defer f.Close()" as soon as the file has been opened - so 
that it is closed both in normal and error conditions.

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/9e8adbbf-dbb2-42f1-bc72-4cc2ee939269o%40googlegroups.com.

[go-nuts] Non-alphanumerics in template field names?

[Bob DuCharme]

I have seen that a map key name of "foo:bar" works just fine... unless I 
reference it in a template. {{.foo:bar}} gives me a segmentation violation 
at runtime, but works fine if there was no colon in the map key name. I 
have tried various ways to escape the colon or quote the field name (e.g. 
{{."foo:bar"}}, {{.foo%3Abar}} ) with no luck. 

Does anyone know a way to allow non-alphanumeric characters (besides the 
underscore, which I know works) in names that get referenced in templates? 

Thanks,

Bob

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/ec64bc07-52a8-429d-bf13-7853da959925n%40googlegroups.com.

Re: [go-nuts] Beginner's question on why two slices don't share the underlying storage

[Ian Lance Taylor]

On Fri, Jul 31, 2020 at 8:47 AM   wrote:
>
> I would appreciate it if someone could help me understand what exactly I'm 
> doing in the code below. My experience with Go spans a few weekends in total 
> so please bear with the naiveté of my question.
>
> When I do this
>
> https://play.golang.org/p/rQvmZEqq8tp
>
> the factory and the gadget share the same specs. When I do this
>
> https://play.golang.org/p/-Gi5N-kpKFq
>
> they don't.
>
> Question: What is the proper way to reason about this code?
>
> I'm mostly looking for an efficient mental model that makes an expert go "of 
> course...", because I've been trying to track references and pointers in my 
> head with no success.

A slice is a struct that contains a pointer to an underlying array.
When you change a slice, you change the pointer.  When you change an
element of a slice, you change an element of the underlying array.

It may help to read https://blog.golang.org/slices-intro.

Ian

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVKgFJ6mC0GcxOL2pENFFBChJM%3DwEg5UYk5-zZcy67mTA%40mail.gmail.com.

[go-nuts] UPL license is not detected on pkg.go.dev

[George Feinberg]

It appears that the UPL license (see https://opensource.org/licenses/UPL) 
for our project 
(https://pkg.go.dev/github.com/oracle/nosql-go-sdk@v1.2.0/nosqldb?tab=doc) 
is not on the list of detected licenses on pkd.go.dev.

Before creating an issue and asking that it be added I wanted to make sure 
that it isn't already underway. It doesn't seem so.

Thanks,
George

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/0854011b-1293-42d5-b115-eb634c7cefaeo%40googlegroups.com.

[go-nuts] Beginner's question on why two slices don't share the underlying storage

[____]

Hi all,

I would appreciate it if someone could help me understand what exactly I'm 
doing in the code below. My experience with Go spans a few weekends in 
total so please bear with the naiveté of my question.

When I do this

https://play.golang.org/p/rQvmZEqq8tp

the factory and the gadget share the same specs. When I do this 

https://play.golang.org/p/-Gi5N-kpKFq

they don't. 

*Question*: *What is the proper way to reason about this code?*

I'm mostly looking for an efficient mental model that makes an expert go 
"of course...", because I've been trying to track references and pointers 
in my head with no success.

On a different note---my apologies if I sound cheesy---thank you for making 
and generously sharing Go. I think you can tell a good piece of engineering 
when it puts a smile on your face.

Thanks in advance.

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/324a3a88-0aa9-42aa-9afc-a9c2874abd86o%40googlegroups.com.

[go-nuts] Re: Why we don't have simple throws error statement

[Yasar Semih Alev]

Note; I don't want to send any proposal currently. Firstly, I would like to 
share and discuss my idea with community.

On Friday, 31 July 2020 at 17:06:33 UTC+3 Yasar Semih Alev wrote:

> Hey Community,
>
> I know, there are so many discussion about error handling. I read tons of 
> idea about that. Looks like most of idea rejected from community but every 
> idea brings our goal closer.
>
> May be we need simple solution. I like Go's simplest ways always. I don't 
> think so we need complex solution about that. Could we handle complexity 
> the error checking with simple throws statement?
>
>
> func myFileRDWRFunc(filename string) (string, error) {
>f, err := os.OpenFile(filename, os.O_RDWR, 0600)
>if err != nil { // backward compatibility
>return "", err
>}
>
> throws func(err error) { // catch all errors
>log.Println(err)
>f.Close()
>
> return "", err
>}()
>
> f.WriteString("anystring")
>f.Seek(0, 0)
> b := ioutil.ReadAll(f)
>
> return string(b), nil
> }
>
> Cheers.
>
> Semih.
>
>

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/fd9308fa-9369-42bf-9fec-7b6691728f24n%40googlegroups.com.

[go-nuts] Why we don't have simple throws error statement

[semihalev]

Hey Community,

I know, there are so many discussion about error handling. I read tons of 
idea about that. Looks like most of idea rejected from community but every 
idea brings our goal closer.

May be we need simple solution. I like Go's simplest ways always. I don't 
think so we need complex solution about that. Could we handle complexity 
the error checking with simple throws statement?


func myFileRDWRFunc(filename string) (string, error) {
   f, err := os.OpenFile(filename, os.O_RDWR, 0600)
   if err != nil { // backward compatibility
   return "", err
   }

throws func(err error) { // catch all errors
   log.Println(err)
   f.Close()

return "", err
   }()

f.WriteString("anystring")
   f.Seek(0, 0)
b := ioutil.ReadAll(f)

return string(b), nil
}

Cheers.

Semih.

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/242e536c-1a85-4855-a64e-a41f67889e0eo%40googlegroups.com.

Re: [go-nuts] I can't install the programm

[peterGo]

Kurtis Rader,

"You [Jorge Dobry] have a 64-bit CPU and 4 GB of memory so I'm wondering 
why you installed the 32-bit version of Windows. That seems like an odd 
thing to do."

I didn't think it was odd. The Intel® Core™2 Duo Processor T5450 is an 
ancient, low-end processor. Microsoft offered a free upgrade to Windows 10 
from Windows 8.

Peter

On Thursday, July 30, 2020 at 10:24:53 PM UTC-4, Kurtis Rader wrote:
>
> On Thu, Jul 30, 2020 at 6:04 PM Jorge Dobry  > wrote:
>
>> I can't install the programm GO
>>
>> I have only 32 bit in my computer
>>
>> What can I do?
>>
>
> Go is supported on 32-bit Windows. See  https://golang.org/doc/install. 
> The download page, https://golang.org/dl/, has an installer that should 
> work for you. Did you try installing that version? If yes what happened?
>
> P.S., You have a 64-bit CPU and 4 GB of memory so I'm wondering why you 
> installed the 32-bit version of Windows. That seems like an odd thing to do.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/b9102ce7-d856-4706-a5bb-8298edc5e2bfo%40googlegroups.com.

[go-nuts] Re: directory name and module name not same, go tool pprof, list function faild

[Vladimir Varankin]

Hey,

In your example, "~/Documents/tool/tejia_analysis" is your module's source 
root, right? Could you show where "app_server/util/analysis.go" is on the 
FS and what is the name of the module?

pprof has a coupe flags to manipulate with the path, helping it to search 
for the source code. I used to use the combination of "-source_path" and 
"-trim_path" to map my local source code to the paths that were embedded 
into the app's binary.

On Thursday, July 30, 2020 at 8:09:29 AM UTC+2 blade...@gmail.com wrote:

> hi, i create a project, directory name and module name not same, and i 
> profile it , use list command  to print code and profile, it tips me not 
> find the file,  how to make it works?
>
>
> macbookpro:tejia_analysis fredlee$ go tool pprof 
> http://ip:6065/debug/pprof/heap
>
> Fetching profile over HTTP from http://ip:6065/debug/pprof/heap
>
> Saved profile in 
> /Users/fredlee/pprof/pprof.tejia_analysis.alloc_objects.alloc_space.inuse_objects.inuse_space.006.pb.gz
>
> File: tejia_analysis
>
> Type: inuse_space
>
> Time: Jul 30, 2020 at 2:03pm (CST)
>
> Entering interactive mode (type "help" for commands, "o" for options)
>
> (pprof) top20 -cum
>
> Showing nodes accounting for 2509.12MB, 98.97% of 2535.11MB total
>
> Dropped 37 nodes (cum <= 12.68MB)
>
>   flat  flat%   sum%cum   cum%
>
>  0 0% 0%  2533.11MB 99.92%  app_server/util.(*Analysis).Job
>
>  0 0% 0%  2533.11MB 99.92%  
> app_server/util.(*Analysis).Start
>
>  1007.72MB 39.75% 39.75%  2523.10MB 99.53%  
> app_server/util.(*Analysis).LoadSearchLog
>
>  0 0% 39.75%  1466.37MB 57.84%  
> go.mongodb.org/mongo-driver/bson.(*Decoder).Decode
>
>  0 0% 39.75%  1466.37MB 57.84%  
> go.mongodb.org/mongo-driver/bson.UnmarshalWithRegistry
>
>  0 0% 39.75%  1466.37MB 57.84%  
> go.mongodb.org/mongo-driver/bson.unmarshalFromReader
>
>  0 0% 39.75%  1466.37MB 57.84%  
> go.mongodb.org/mongo-driver/bson/bsoncodec.(*StructCodec).DecodeValue
>
>  0 0% 39.75%  1466.37MB 57.84%  
> go.mongodb.org/mongo-driver/mongo.(*Cursor).Decode (inline)
>
>  0 0% 39.75%  1457.37MB 57.49%  
> go.mongodb.org/mongo-driver/bson/bsoncodec.(*StringCodec).DecodeValue
>
>  0 0% 39.75%  1457.37MB 57.49%  
> go.mongodb.org/mongo-driver/bson/bsonrw.(*valueReader).ReadString
>
>  1457.37MB 57.49% 97.24%  1457.37MB 57.49%  
> go.mongodb.org/mongo-driver/bson/bsonrw.(*valueReader).readString
>
>  0 0% 97.24%44.03MB  1.74%  net/url.ParseQuery (inline)
>
>44.03MB  1.74% 98.97%44.03MB  1.74%  net/url.parseQuery
>
> (pprof) list LoadSearchLog
>
> Total: 2.48GB
>
> ROUTINE  app_server/util.(*Analysis).LoadSearchLog 
> in app_server/util/analysis.go
>
>  1007.72MB 2.46GB (flat, cum) 99.53% of Total
>
>  Error: could not find file app_server/util/analysis.go on path 
> /Users/fredlee/Documents/tool/tejia_analysis
>
>
>

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/720fbe94-a27b-457c-8be8-30b28b5fbd2fn%40googlegroups.com.

Re: [go-nuts] import a file

[Volker Dobler]

On Friday, 31 July 2020 04:55:50 UTC+2, jules wrote:
>
> Modules are a great idea and I want to use them, but I can't get it to 
> compile
> a "hello golang" program even:
>
> ===
> $ ls  /home/jfields/go/src/jsonstuff
> typestuff.go
> $ go mod init src
> go: creating new go.mod: module src
> $ more go.mod 
> module src
>
> go 1.14
> $ go run main.go
> main.go:7:2: package jsonstuff is not in GOROOT 
> (/usr/local/go/src/jsonstuff)
> $ rm go.mod
> $ go run main.go
> Hello golang
> {0}
> =
>

Once again:

1. Naming the module "src" is _wrong_.
Do _not_ do this! Use "myfirst.project".
 
2. Do nut use go run. Use go build.
(or at least, if there are  _fundamental_ issues
which prevent you from typing  `go build` at
least use `go run .`.

3. Now that your module is called "myfirst.project"
the import path of package jsonstuff in main.go
_must_ read
   import "myfirst.project/jsonstuff"

You _must_ name your module properly and
you _must_ use the proper import path. You code
as is is _invalid_ and _cannot_ be compiled.
You must follow the rules.

You should delete everything  and start afresh
in the way described by How To Write Go Code.

V.

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/b9988553-8172-48d0-95e0-dc396b15ac09o%40googlegroups.com.

Re: [go-nuts] import a file

[Nathan Fisher]

Hola!

Based on your initial project layout you have a couple of issues. When
using the legacy gopath everything should ideally live under that path.
Imports then become relative to that root.

Your main lives outside of the root which works with go run but is not how
a project should be structured.

For a small toy project I would place both files in the same directory and
set their package name to main.

If however your objective is to better understand imports then I would
reconsider your project structure. In the root directory of your project I
would place your main.go and run “go mod init” there. In that root
directory you can then create your jsonstuff directory. As an example:

project/main.go
project/go.mod
project/jsonstuff/types.go

When using go mod it typically (but not always) maps to a single
module/project/repository.

go mod init 

The module specified above is usually a URI without the protocol. By
following this practise it makes the project “go gettable”. If you maintain
src as your module name you would need to change the import for jsonstuff
to src/jsonstuff and move your main.go to the src directory.

As mentioned by others src isn’t a good name for a module. Better to do
something like:

go mod init github.com//helloworld

You would then change your jsonstuff import to:

github.com//helloworld/jsonstuff

Be aware only one package can live per directory except the special *_test
form which restricts test access to the packages public api only.

On Thu, Jul 30, 2020 at 23:55, Julian Fields 
wrote:

> Thanks Jesper and Volker.
> After reading the article(s) and go help modules and a few blogs, I still
> was not able to see why deleting go.mod makes the program import
> jsonstuff package, and compile and run?
> Modules are a great idea and I want to use them, but I can't get it to
> compile
> a "hello golang" program even:
>
> ===
> $ ls  /home/jfields/go/src/jsonstuff
> typestuff.go
> $ go mod init src
> go: creating new go.mod: module src
> $ more go.mod
> module src
>
> go 1.14
> $ go run main.go
> main.go:7:2: package jsonstuff is not in GOROOT
> (/usr/local/go/src/jsonstuff)
> $ rm go.mod
> $ go run main.go
> Hello golang
> {0}
> =
>
>
> On Thu, Jul 30, 2020 at 5:01 AM Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
>> On Thu, Jul 30, 2020 at 12:54 PM Volker Dobler <
>> dr.volker.dob...@gmail.com> wrote:
>>
>>> You dop not import files and you do
>>> not run files and you do not test files. Files contain the
>>> sources but are basically uninteresting: Focus on
>>> packages (and modules).
>>>
>>
>> In Go, we disconnect the name of a file and the package in which it
>> lives. That is, the programmer is free (mostly) to choose whatever names
>> for files in a package, and also free to create as many files as is seen
>> necessary. It is in contrast to a large set of other languages, which
>> require that the package and the filename stay the same. The advantage is
>> that you can have very large packages and gracefully split them over
>> multiple files without having to resort to inventing new internal package
>> names.
>>
>> My general view is that you shouldn't assume a connection between the
>> file system and the packages of your language, and the languages which do
>> have the wrong design. However, since that "mistake" is made in many
>> languages, people tend to get somewhat confused when they encounter a
>> system where it isn't the case.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/pP-0WEpzbEs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX%2BN%2BospARM7adQ1E0wk-K7M73Jbj1KEUXkxjGGq9Q9zg%40mail.gmail.com
>> 
>> .
>>
> --
> 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 web visit
> https://groups.google.com/d/msgid/golang-nuts/CAAcmRO8TZ4ftK%2BFsTQTw7nEGZ0e3gFFpv5uygb4S6YavVRe_Xg%40mail.gmail.com
> 
> .
>
-- 
Nathan Fisher
 w: http://junctionbox.ca/

-- 
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 

[go-nuts] [ANN] GoLand 2020.2

[Florin Pățan]

Hi Gophers,

I'm here with a small update about our latest release of GoLand, the Go IDE 
from JetBrains.

In this release we worked to:
- improve the Go modules support
- navigate from comments to symbols definitions
- add a Problems View window
- add a few new inspections for things like string(int) conversion, 
detecting duplicate struct tags, etc.
- share code to Go Playground
- add support for the experimental Go 2 Generics proposal
- support for workflows for Github pull requests straight from the IDE

To find out more details about this release, check out the announcement page 
.

If you use it/try it, we are happy to hear about your experience with the 
IDE.

-- 
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 web visit 
https://groups.google.com/d/msgid/golang-nuts/c840444c-9035-4e89-9697-9cd613f889e4n%40googlegroups.com.