Re: [go-nuts] Evaluation order of return
I understood perfectly now, thanks for the explanations and the link! I really appreciate you guys! On Thursday, September 24, 2020 at 3:28:10 AM UTC+3 Ian Lance Taylor wrote: > On Wed, Sep 23, 2020 at 1:10 AM cs.ali...@gmail.com > wrote: > > > > I am not actually questioning the current design, as you both said it is > not a good practice to call a return statement as I wrote above, I am > trying to understand the relation between memory, interface and order of > evaluation. It is clear that the compiler takes account of whether a return > statement is an interface or a struct and the memory size of the returned > value, If I return a struct rather than an interface, it changes the order, > If I add fields to the structs it changes the order. Is there a paper that > I can find why the compiler considers them for ordering, why it is > important for performance or anything else? > > I'm not aware of any paper specific to the Go compiler. > > I find it most useful to consider a compiler as creating a set of > constraints derived from the input based on the language semantics. > These are constraints like in "a = b; b = c" the read of b in the > first assignment must be completed before the store to b in the second > assignment. Once the set of constraints is created, the compiler must > solve those constraints given an instruction architecture including a > set of registers. The goal is to optimize execution time while > minimizing compilation time without violating any constraints. > Because compilation time matters, compilers do not fully analyze all > possible solutions; instead, when it comes to things like memory > load/store order, instruction selection, and register allocation, they > are full of heuristics that tend to give good results in practice. > > When you view a compiler in that way, a question like "why does adding > fields to a struct change the order of memory loads and stores" > becomes uninteresting. The reason has to do with the details of all > the constraints that applied while compiling that particular package. > There is no rule that says "if the struct has more fields, do this." > It's just that the set of heuristics happened to produce a particular > result. Changing some other piece of code in some other part of the > package might produce a different result. Or a different version of > the compiler might apply different heuristics and get different > results. > > 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/b2aa2ac3-a7da-4415-9534-7076551da5e7n%40googlegroups.com.
[go-nuts] Re: basics of understanding golang memory usage
With help from Nelson Mimura Gonzalez and Bryan S Rosenburg I was able to make some progress on the relationship between the cgroups view and the procfs view. In the cgroups view: `memory.usage_in_bytes` is the sum of `memory.stat:rss` + `memory.stat:cache` + `memory.stat:mapped_file` + `memory.kmem.usabe_in_bytes`. The cgroups `memory.stat:rss` is one page less than the sum of these procfs values: (sum of Rss of anonymous pmap blocks) + (sum of Anonymous of fd pmap blocks). Regards, Mike On Tuesday, August 18, 2020 at 1:56:30 AM UTC-4 mspr...@us.ibm.com wrote: > I collected data on an example program from four angles. See > https://docs.google.com/document/d/1KUz7IjnD93X2VTVkRAhhNa7rHScCaIH8GLrsoaDIW_g > > for the raw data and my puny attempts to correlate the four views. There > are some exact equalities, some near matches, some gross differences in > things that seem like they should be the same, and things I wasn't able to > match in any way. This begs lots of questions. > > Why is memory.usage_in_bytes from cgroups so much smaller than the other > top-line measurements? What is statm.size counting that the coredump "all" > is not? > > I assume that the text part of the connection-agent binary is shared. Why > is the readonly data part of the connection-agent binary _not_ shared? > > What is statm.data counting that MemStats.Sys is not? > > Why is MemStats.HeapIdle so much bigger than the coredump's heap free > spans? > Why is MemStats.heapReleased so much bigger than the coredump's heap > released? > In MemStats, (HeapIdle - HeapReleased) = 1,490,944 > In coredump, (heap free spans) - (heap released) = 1,613,824 --- not so > very different. What is making the roughly 52 MB difference between > MemStats and the coredump? > > Why is the bss in the coredump so huge? Does it correspond to anything in > any of the other views? > > What do the three big anonymous blocks in the procfs view correpond to in > the other views? > > Thanks, > Mike > > -- 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/1be31756-b836-4449-b56a-dd8f9b1fdae8n%40googlegroups.com.
Re: [go-nuts] global goroutine data / thread local storage?
On Wed, Sep 23, 2020 at 6:02 PM Alex Mills wrote: > > Not a joke, in terms of performance, if you access the goroutine id via the C > library call? I'm not sure what C library call you mean. > My only concern would be if goroutine id's were reused, if not it would work. Goroutine IDs are not reused. (Well, a goroutine ID is just a 64-bit integer so it could technically wrap around and be reused in that way, but it seems unlikely.) Ian > On Wed, Sep 23, 2020 at 5:54 PM Ian Lance Taylor wrote: >> >> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills wrote: >> > >> > There appears to be a way to get a reference on the goroutine id: >> > >> > http://blog.sgmansfield.com/2015/12/goroutine-ids/ >> >> But as you can see by reading that blog article, that is almost a joke. >> >> Go considers these things to be better handled explicitly, which is >> why people are telling you to use a context.Context value. And, yes, >> you'll want to use a Context aware logging package. >> >> In Go it's trivial to create new goroutines, and as soon as you do >> that any goroutine-local-variable scheme falls apart. So Go has >> consistently chosen to not provide that capability, and similarly to >> not provide goroutine IDs. It's an intentional choice by the >> language. There have been a number of discussions about this in the >> past on this mailing list. >> >> 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/CAOyqgcUsLyVurqXqt6GDgMBQYcoVK%2BP4%2Bdm14ju-VKiA%3Dh1jYg%40mail.gmail.com.
Re: [go-nuts] loadinternal: cannot find runtime/cgo
As far as I know, this is a demo that relies on internals that are not part of the official API, so there are probably mismatches because of that. Maybe try with an older Go version first? Also, how did you install Go itself? Maybe the GOROOT is not set up correctly for example? [Joop Kiefte - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=p5hhg) [p5hhg] On September 24, 2020 at 15:30 GMT, saurav deshpande wrote: https://github.com/achilleasa/bare-metal-gophers Downloaded the source code from above link Tried running the make file but get the error of cannot find runtime/cgo. Version: 1.15 linux os Please guide. Thank you -- 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/ed39e670-dc26-4df1-812b-13bb9e28c187n%40googlegroups.com](https://groups.google.com/d/msgid/golang-nuts/ed39e670-dc26-4df1-812b-13bb9e28c187n%40googlegroups.com?utm_medium=email_source=footer). -- 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/c-64693-kfgzn2bc-w6vu46%3D1x6rz0y%402.gethop.com.
[go-nuts] loadinternal: cannot find runtime/cgo
https://github.com/achilleasa/bare-metal-gophers Downloaded the source code from above link Tried running the make file but get the error of *cannot find runtime/cgo.* *Version: 1.15 linux os* Please guide. Thank you -- 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/ed39e670-dc26-4df1-812b-13bb9e28c187n%40googlegroups.com.
Re: [go-nuts] Windows Write Call Error when Writing to Network mapped Folder.
On Tue, Sep 22, 2020 at 10:56:43AM -0700, helhadad wrote:
> Hi Folks,
> I am trying to create file and write to it on a *network mapped drive*,
> which I can access, create, delete and edit files using windows explorer or
> CMD (Windows 10/Server 2016).
>
> You can find all details of the issue and response from other Go-Expert
> below:
>
> https://stackoverflow.com/questions/63960049/writing-to-networked-mapped-drive-empty-files-or-failure
>
> I would appreciate if you enlighten me about the issue and how to solve it.
I would in particular highlight one weirdness discovered in [1]:
when the OP did use forward slashes in their call to os.OpenFile,
the error message read
{Op:"write", Path:"H://00_SC//Dest01.txt", Err:0x57}
that is, every forward slash in the input has been doubled.
Another issue I can't fully grasp is why creating of the file goes well,
and the error is only returned on the first call to Write on the returned
file handle? Some folks suggested special dances are required in order to
properly open a file on such a network share but this does not explain why
plain commands like `copy` work in a cmd.exe session with that same resource
attached by the `net use` command.
(Kindly looking for soliciting any insight from Alex Brainman.)
Is there a way to trace what happens on the system call level?
1. https://stackoverflow.com/questions/63960049#comment113160125_63960049
--
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/20200924143320.7cdinhe4o3f5rsit%40carbon.
Re: [go-nuts] Re: How to import one field from package, etc
To answer the title question: no, there's no way to limit an imported
package to a subset of its exported identifiers. But, given the example
provided, it seems the suggested solution works exactly as you desire.
You can give a local identifier to an imported package (e.g.
https://play.golang.org/p/WJChIJoMMys ) or you can bring another package's
exported identifiers into the current package's scope with "." as a package
name (e.g. https://play.golang.org/p/3IyGkPNJZMx ) but I don't think either
is what you're asking for.
Can you provide any more context as to what your end goal is and why the
using the package name to access your identifiers is a problem?
On Wednesday, September 23, 2020 at 4:33:39 PM UTC-4 al...@channelmeter.com
wrote:
> It works temporarily, but then I have to manually update each file that
> imports + exports the methods, it won't "just work" with new versions of
> the library that gets imported, right?
>
>
> On Wed, Sep 23, 2020 at 11:59 AM Jason Phillips
> wrote:
>
>> Did you try your own suggestion? It seems to work fine:
>> https://play.golang.org/p/KVo5COKj2ii
>>
>> On Wednesday, September 23, 2020 at 1:46:05 PM UTC-4
>> al...@channelmeter.com wrote:
>>
>>> Using node.js, we might have this:
>>>
>>> const z = new Z();
>>> exports.z = z
>>>
>>> and then in another file we can import
>>>
>>> import {z} from '../z'
>>>
>>> with Golang, I am trying to do something similar:
>>>
>>> package log
>>>
>>> import Logger "github.com/foo/bar/logger"
>>>
>>> // create an instance
>>> var log = Logger.create()
>>>
>>> // export the methods
>>> var Info = log.Info
>>> var Warn = log.Warn
>>> var Error = log.Error
>>>
>>> and then we import it like
>>>
>>> import "github.com/a/b/log"
>>>
>>> func init(){
>>>log.Info("something")
>>>log.Warn("something")
>>> }
>>>
>>> /// ===
>>>
>>> basically what I am asking is if there is a way to create an instance
>>> and access it's methods - so that in my code I don't have to do:
>>>
>>> log.log.Info()
>>>
>>> but instead I can do:
>>>
>>> log.Info()
>>>
>>> hope the question makes sense.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/d2f2125f-9260-4268-ac31-cfe738dc3f5en%40googlegroups.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/e37e284b-d67b-4202-820b-cc6496efceecn%40googlegroups.com.
