Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[roger peppe]

On Tue, 3 Mar 2020 at 22:37, Warren Stephens 
wrote:

> rog,
>
> Very well said -- but everyone keeps talking about improving the
> maintainability without talking about the "comprehensiblity".
>
> Look at the 2 things below.  Which is more quickly comprehensible?  We
> cannot conceive of a way to have the upper one and still test each piece???
>

I'm interested to try to understand why you feel you can't write tests for
the former code by calling the top level entry point
(presumably AAA in your example). I feel that so many testing decisions are
only properly made in the context of the code itself. It's hard to talk
usefully about such things without any actual examples.  Perhaps you could
provide some Go code that you'd feel that you'd be forced to split up in
order to test (perhaps reduced in size or anonymized), so that we have
something concrete to talk about?

  cheers,
rog.


> Warren
>
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
>
> ===
>
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
>
>
>
> --
> 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/be59057f-bd56-4b57-9e23-3c59b1153a47%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/CAJhgacg_eTLDcO4%3DJ2PNAJTecreCVuRD2LwPSCa%2BOj8%3D273p%2BA%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Tristan Colgate]

It is not possible to infer the intent of a chunk of code purely from
the expressions. You can see what it does, not what it meant to do.
One way of labeling the intent is to put that code in a function. A
well chosen name can let someone determine what the function was
intended to do, and fix it if it is doing something else. You can also
test that intention holds for some reasonable set of values, and
people can expand that set of values if they find ones for which that
function seems to do something else.

So, if the choice you propose is between an function with a series of
steps, all in line, vs a function with a series of named steps that
are elsewhere, then yes, I'll go with you're option one because I'd
rather read.

  func (a *thing) processThing() error{
a.tidyTheThing()
a.mungeTheThing()
a.augmentTheThing()
  }

Than a function of potentially unbounded length which is just a frenzy
of activity on that thing.

The problem is that you are advocating for what most people would
consider to be the day 1 programming experience, where experience and
industry best practice has show us that it is better to structure
things more clearly. You are the first person I've seen actually
advocate for this approach, where my own experience, and the
experience of every text I've read, advocates for the opposite.

On Tue, 3 Mar 2020 at 22:38, Warren Stephens
 wrote:
>
> rog,
>
> Very well said -- but everyone keeps talking about improving the 
> maintainability without talking about the "comprehensiblity".
>
> Look at the 2 things below.  Which is more quickly comprehensible?  We cannot 
> conceive of a way to have the upper one and still test each piece???
>
> Warren
>
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
>
> ===
>
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
>
>
>
> --
> 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com.



-- 
Tristan Colgate-McFarlane

  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"

-- 
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/CAPGZSG%2B6KbYTOxeThC6PcxskGSXckebPb%2BUmJ6acp_e%3DRFO%3DRg%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Kevin Chadwick]

On 2020-03-03 22:22, Robert Engels wrote:
> A key statement in the link “ The JIT-generated code is *significantly* faster
> than the ahead-of-time-generated code for small matrix sizes.”
> 
> Which is what you were arguing was not possible... you can’t have it both 
> ways.

JIT code often requires RWX memory and JAVA has long been a violator of security
protections in this area. I believe Pythons crypto package is still a RWX memory
creator.

I hope the strive for performance doesn't come at the cost of reducing the
potential of an OS or memory protection unit/management to protect us. Coupled
with restarting failing programs, it is a potentially dangerous default 
practice.

IMO, performance desires by a smaller group have kept C insecure and hurt the
masses!

"https://phoronix.com/scan.php?page=news_item&px=OpenBSD-Browser-Security";
"https://marc.info/?l=openbsd-misc&m=142523501726732";

-- 
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/7cee8967-2506-e238-eca0-e1b994f7a0e4%40gmail.com.

[go-nuts] Pass C struct from Go to C method

[Nitish Saboo]

Hi,

I have CGO project.

Following is my C header file and Go code

syslog-node.h
===

#ifndef _TEST_H_
#define _TEST_H_

#include 

typedef void (*key_value_cb)(const char* key, const char* value, size_t
value_len, int work);
typedef struct Foo{
key_value_cb cb;
int data;
}Foo;
int initialize_engine(const char* filename, const char* module_path, Foo
*cb);
int reload_pattern_db(const char* filename, Foo *cb);


cfunc.go

/*

#include 

// The gateway function
void callOnMeGo_cgo(char *key, char *value, size_t value_len, int work)
{
void ParsedData(const char *key, const char *value, size_t value_len, int
work);
ParsedData(key, value, value_len, work);
}
*/
import "C"

main.go


var InitStruct *C.struct_Foo;

func InitializeEngine(pattern string, path string) {
pattern_db := C.CString(pattern)
module_path := C.CString(path)
if InitStruct != nil{
C.free(unsafe.Pointer(InitStruct))
}
InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
InitStruct.data = C.int(0)
fmt.Println(InitStruct)  <<<'&{0x4b79d0 0 [0 0 0
0]}' got printed
C.initialize_engine(pattern_db, module_path, InitStruct)

}

func ReloadPatternDB(patterndb string) {

path := C.CString(patterndb)
InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))   <

Re: [go-nuts] How to find goroutines during debugging - aka goroutine labeling

[Jesper Louis Andersen]

On Wed, Mar 4, 2020 at 7:24 AM Florin Pățan  wrote:

> I think the current solution is a perfectly reasonable solution.
>
> As I explained in the article, you can have 0 performance impact when used
> in production environments, because you can disable this feature.
>

My experience is that a little performance impact is a small price to pay
for having better instrumentation in a system. Often, it allows you to
observe the behavior of the running system and this leads to optimizations
in the system long before they become a problem in production environments.
If we have a place where we should use all the power a modern CPU gives us,
I think this is a good place. Knowledge of a programs execution profile is
often extremely valuable in the long run. The key reason being that once
you have real users in the system, they start using your applications in
ways you never imagined they would. And thus, they often redefine what is a
hot code path inside the code base, requiring optimization. Also, you will
have outlier users who puts pressure on your system. But those outliers
today are the common user tomorrow, so optimizing for them is also
beneficial. You can skip this, in the name of efficiency, but chances are
you will be in peril as your are working blindly on assumptions about the
programs execution behavior.

As for the solution, I think it looks fine as well. Process tagging is
something I've used in many systems with massive concurrency, as the
knowledge is invaluable in post-mortem situations. Observability is
important[0].

[0] The by far best definition of Observability I've seen is due to Charity
Majors, who lifted the term straight out of Control Theory:
https://en.wikipedia.org/wiki/Observability It is one of those highly
formal definitions which informal spirit applies quite well to software.

-- 
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/CAGrdgiU9bRnemqP4QSOu2dnANMy%3DxWC4-JbivcBupPYSoi8U4g%40mail.gmail.com.

[go-nuts] Some ideas about scope declarations and variable redeclarations.

[T L]

Now, the qualified selector form is "aPkg.Exported".
The form is the same as object selector, "aObj.Property".
Sometimes, it is not very clear for code readers to recognize
the first parts of such slectors is an import or an object.
So, I think the C++ way "aPkg::Exported" is more readable.

Let's extend the C++ denotion a bit, by using the "::foo"
to represent the identifer "foo" declared at the top
level of the current package, and using ":bar" to
represent the innermost declared identifer "bar".
The notation ":bar" is only meaningful when it is used
as a target value in a variable declaration (see below).

Suppose we can declare scope identifers, here is
an example to show the above ideas:

var a = 1
func f() {
var a = 2
{
scope x
var a = 3
{
println(::a, x:a, a, :a) // 1 2 3 3
}
}
}

(The above description is just to make the following
described new variable redeclaration syntax look natural.
In fact ":id" may only be allowed to be used as L-values
in variable declarations below.)

We all know that, although short variable declarations (x, y := a, b)
do solve some problems, they also brings some new ones.
The new problems include:
1. break the "one solution to do something" principle in Go.
   Short declarations overlap too much with standard declarations in 
functionalities.
2. short declarations brings some confusions to Go programmers, in 
particular to new gophers.
   * It is not very clear to get which identifiers are new declared
 and which are redeclared at the first glance.
   * Almost every gophers ever dropped in the famous variable shadowing
 trap caused by using short declarations. A real world example:
 https://github.com/Azure/go-ntlmssp/pull/24
   * Not all L-values suitable to act as target values are allowed
 be show up as the target values in short declarations.
 https://github.com/golang/go/issues/30318

Recently, I just got an idea which is inspired from this thread:
https://github.com/golang/go/issues/377.
The idea (almost) removes short declarations and also solves
the problems short declarations solved. More importantly,
it doesn't bring the problems short declarations brought.
However, my perception might be limited. There might be
flaws in this idea, and the idea might bring new problems.
So any criticisms are welcome.

The following code shows the logic of the idea:

package bar

func foo() {
   var x, err = f()
   ...
   // Here ":err" means the "err" declared above.
   var y, z, :err = g()
   ...
   {
   // The ":err" also means the "err" declared above.
   var w, :err = h()
   ...
   // This "err" is a new declared one.
   var m, n, err = k()
   ...
   }
}

Selectors, dereferences, element indexing, and the above
mentioned ":id" forms are allowed to show up as target values
in a variable declaration, as long as there is at least one
pure identifier in the declaration. The pure identifiers represent
new declared variables. The new variables are initialized,
others are re-assigned with new values.

type T struct {
i *int
s []int
}
var t T
var p = new(int)

func bar() {
   // "err" is new declared, others are not.
   var *p, t.i, t.s[1], :p, err = 1, p, 2, t.i, errors.New("bar")
   // *:p is not valid. In other words, :id must show up independently.
   ...
}

The := redeclaration syntax should be kept ONLY in the
simple statements in control flows, just for aesthetics reason. 
In other words, "... := ..." is totally a shorthand of
"var ... = ..." in the simple statements in control flows.

if a, b := c, d; a {
}
//<=>
if var a, b = c, d; a { // some ugly
}
// However, personally, I also think the ugly version is acceptable.

The idea should be Go 1 compatible. What I mean here is
the above proposed new redeclartion syntax may coexist with
the current standard and short variable declarations.
And it is easy to let "go fix" translate short variable
declarations into the above proposed new syntax form.
The short declarations in the simple statements
in control flows don't need to be translated.

-- 
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/3073e599-4c37-4aa7-a78a-9685eeb54252%40googlegroups.com.

Re: [go-nuts] How to handle EINTR from syscall.Dup2

[Philip Boampong]

On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor  wrote:
>
> If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to
> newfd; 3) return EINTR leaving newfd closed, then dup2 requires
> considerable care in any multi-threaded program.  It requires that if
> one thread is calling dup2, no other thread is permitted to open a
> file or socket or other file descriptor.  That seems both unfortunate
> and unbelievable.  I would like to see hard evidence before believing
> that kernel developers for any OS would create a system with such a
> bug.

I'm not trying to convince you, I'm just showing the little
information I found (with links); you could have just said they are
wrong.
What you wrote here, I'm trying to say it from the start. That kind of
dup2 would be impractical to use, and why have *any* atomicity
guarantee at all if you have to synchronize everything yourself
anyway?
But I could argue that the man is not explicit enough to disprove the
wrong interpretation, even if it is "common sense".

It seems that if I want to use dup2 at all, I have no other choice
than to believe that retry on EINTR is harmless (and I hope in every
sane system it is).

-- 
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/CAEvMKD95nk6cked9M8Z5HsRK9Vg_n4cmayb7H_J%2BeDzBRbmqog%40mail.gmail.com.

Re: [go-nuts] How to handle EINTR from syscall.Dup2

[Philip Boampong]

Thanks for the feedback.

> "If the close operation fails to close fildes2, dup2() shall return -1 
> without changing the open file description to which fildes2 refers."
> "If close() is interrupted by a signal that is to be caught, it shall return 
> -1 with errno set to [EINTR] and the state of fildes is unspecified."

The two statements you quoted are not necessarily contradictory: one
is in the context of dup2(2), the other is in the context of close(2).
In the context of dup2 they may be using the word "close" informally,
without implying that a literal close(2) should be called internally.
(Even though is seems inconvenient to actually have two different behaviors.)

I wish the spec was more specific, but the dup2 prescription not to
change the open file description to which fildes2 refers in case of
error, seems to be intended as a guarantee that you can safely retry
dup2 on EINTR.

As you observed, by ignoring the result of the implicit close, Linux
dup2 solves the problem from another angle. It deviates from the
standard but it maintains compatibility, in the sense that it won't
break if you wrap your dup2's into retry loops.

If a dup2 can free filedes2/newfd and return EINTR, you are basically
accepting that even ordinary signals (e.g. used by the runtime) can
crash your dup2 in an irrecoverable way. I hope this can't be the case
in a sane system (unless someone knows of a system which is actually
affected).

> The situation is confused by the dup2 man page still stating that EINTR might 
> be returned by dup2, which actually cannot happen.

Yes, I was confused by that too.
Also, neither dup2 nor close are mentioned in the signal(7) man page,
therefore you can't tell if they are supposed to be affected by
SA_RESTART or not.

-- 
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/CAEvMKD-GD4AUF_OO%2BYdRYnukof5k5WUqnkSOz%3Dueqk%2BSqzwUoA%40mail.gmail.com.

Re: [go-nuts] How to handle EINTR from syscall.Dup2

[Ian Lance Taylor]

On Wed, Mar 4, 2020 at 6:20 AM Philip Boampong  wrote:
>
> On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor  wrote:
> >
> > If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to
> > newfd; 3) return EINTR leaving newfd closed, then dup2 requires
> > considerable care in any multi-threaded program.  It requires that if
> > one thread is calling dup2, no other thread is permitted to open a
> > file or socket or other file descriptor.  That seems both unfortunate
> > and unbelievable.  I would like to see hard evidence before believing
> > that kernel developers for any OS would create a system with such a
> > bug.
>
> I'm not trying to convince you, I'm just showing the little
> information I found (with links); you could have just said they are
> wrong.

The links that I looked at were speculating about behavior, not
demonstrating real behavior in kernels.  I don't know how to judge
whether those speculations about hypothetical behavior are correct or
not.  Many things are hypothetically possible.  I'm just saying that
before changing any code I would need to see actual evidence that some
kernel behaves in that way, not just speculation that it might.

If I missed something in those links, I apologize.

> It seems that if I want to use dup2 at all, I have no other choice
> than to believe that retry on EINTR is harmless (and I hope in every
> sane system it is).

In practice, if you don't use a FUSE file system, I bet that you will
never see an EINTR error from dup2.  That goes double for Go programs,
as the Go runtime installs all signal handlers with SA_RESTART set.

This isn't worth all that much, but using the os/exec package to start
a new program will use dup2 to set up file descriptors.  Those calls
to dup2 do not retry on EINTR; any EINTR error will be reported back
to the caller as an execution failure.  I am not aware of any bug
reports in which that actually happened.

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/CAOyqgcVk7nqqyibgnYTLcHy%3D8EUtbO%3DM7c%2ByXUvqha6aAMwOAQ%40mail.gmail.com.

[go-nuts] Re: go vet on playground emits message on printf %x with floating point

[Jake Montgomery]

This is a known problem: https://github.com/golang/go/issues/34993
It was fixed in Go 1.14: 
https://go-review.googlesource.com/c/tools/+/202041/

I'm curious what you use hex float for?

On Tuesday, March 3, 2020 at 7:10:00 PM UTC-5, bup...@gmail.com wrote:

> Playground: https://play.golang.org/p/2j2PlKwiA7B
>
> Source code:
>
> package main
>
> import (
>  "fmt"
> )
>
> func main() {
>  fmt.Printf("%x\n", 5.0/7.0)
> }
>
>
> Expected: No message emits by go vet
>
>
> Actual: go vet emits the following message:
>
> ./prog.go:8:2: Printf format %x has arg 5.0 / 7.0 of wrong type float64 
>
>
> According to https://golang.org/pkg/fmt/ , %x with floating point 
> displays hexadecimal notation (with decimal power of two exponent), which 
> is legal usage. 
>

-- 
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/23f5469a-07c3-4331-9ab7-36c0f05050a0%40googlegroups.com.

Re: [go-nuts] Pass C struct from Go to C method

[Ian Lance Taylor]

On Wed, Mar 4, 2020 at 3:57 AM Nitish Saboo  wrote:
>
> I have CGO project.
>
> Following is my C header file and Go code
>
> syslog-node.h
> ===
>
> #ifndef _TEST_H_
> #define _TEST_H_
>
> #include 
>
> typedef void (*key_value_cb)(const char* key, const char* value, size_t 
> value_len, int work);
> typedef struct Foo{
> key_value_cb cb;
> int data;
> }Foo;
> int initialize_engine(const char* filename, const char* module_path, Foo *cb);
> int reload_pattern_db(const char* filename, Foo *cb);
>
>
> cfunc.go
> 
> /*
>
> #include 
>
> // The gateway function
> void callOnMeGo_cgo(char *key, char *value, size_t value_len, int work)
> {
> void ParsedData(const char *key, const char *value, size_t value_len, int 
> work);
> ParsedData(key, value, value_len, work);
> }
> */
> import "C"
>
> main.go
> 
>
> var InitStruct *C.struct_Foo;
>
> func InitializeEngine(pattern string, path string) {
> pattern_db := C.CString(pattern)
> module_path := C.CString(path)
> if InitStruct != nil{
> C.free(unsafe.Pointer(InitStruct))
> }
> InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> InitStruct.data = C.int(0)
> fmt.Println(InitStruct)  <<<'&{0x4b79d0 0 [0 0 0 0]}' 
> got printed
> C.initialize_engine(pattern_db, module_path, InitStruct)
>
> }
>
> func ReloadPatternDB(patterndb string) {
>
> path := C.CString(patterndb)
> InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))   << new memory
> InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> InitStruct.data = C.int(0)
> fmt.Println(InitStruct)<<< '&{0x4b79d0 0 [0 0 0 
> 0]}' got printed
> C.reload_pattern_db(path, InitStruct)
>
> }
>
>
> I have a Go code where I have to call C functions 'initialize_engine' and 
> 'reload_pattern_db' respectively(one after the other ) and pass the C struct 
> from Go code.
>
>
> The issue is after allocating memory to 'InitStruct' using calloc in 
> 'InitializeEngine' method, the same memory location is getting printed in 
> ReloadPatternDB method even though I am allocating a new memory to 
> 'InitStruct' using calloc in 'ReloadPatternDB' method.
>
> 1) Is this the correct way to pass a C struct from a Go code to C code.
> 2) Is this a correct way to free the struct memory assigned to InitStruct 
> using calloc on Go side ?

You haven't showed us where the same memory location is getting
printed.  Note that fmt.Println is not printing the address of
InitStruct; it is printing the values of the fields.  If you want to
print the address, use fmt.Printf("%p\n", InitStruct).

Also note that InitStruct is a global variable.

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/CAOyqgcWgu6_MzroQhRifMBoq6r8br%2B031_t7GOdDDdnbg_2Liw%40mail.gmail.com.

Re: [go-nuts] How to handle EINTR from syscall.Dup2

[Philip Boampong]

On Wed, Mar 4, 2020 at 4:09 PM Ian Lance Taylor  wrote:
>
> The links that I looked at were speculating about behavior, not
> demonstrating real behavior in kernels.  I don't know how to judge
> whether those speculations about hypothetical behavior are correct or
> not.  Many things are hypothetically possible.  I'm just saying that
> before changing any code I would need to see actual evidence that some
> kernel behaves in that way, not just speculation that it might.

If they were demonstrating real behavior in kernels, I wouldn't be asking.
I had already wrapped all of my dup2's inside retry loops when I came
across that part of the python source which recommends not to do it
because it would cause problems; then I started having doubts.
I reiterated their theory here in response to the feedback only
because I was trying to make my question understood. I'm not
suggesting to change any code nor to act on speculation.

> In practice, if you don't use a FUSE file system, I bet that you will
> never see an EINTR error from dup2.

In Linux it seems that it can't happen regardless of the filesystem,
but I would prefer to leave a little slack if the man page says
otherwise.
I would also like to handle FUSE file systems as gracefully as possible.

> That goes double for Go programs, as the Go runtime installs all
> signal handlers with SA_RESTART set.

Unfortunately the signal(7) man page doesn't tell if dup2 (or even
close) are affected by SA_RESTART.

> This isn't worth all that much, but using the os/exec package to start
> a new program will use dup2 to set up file descriptors.

Good to know. I did try to search for "syscall.Dup2" in the Go source
but that's not how dup2 is called; now I've found some.

-- 
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/CAEvMKD_OtXm-kQtda346DsUNcx%3Duj4ygZbDZRL7m%2Br%3DFrWexhg%40mail.gmail.com.

[go-nuts] Re: SIGILL running 1.14 on macOS

[Jon Conradt]

You can follow the progress toward 1.14.1 
via https://github.com/golang/go/milestone/137

Looking at 1.13.0 and 1.12.0 it looks like the time between a .0 release 
and a .0 release is about three weeks. So I'm hoping for a St. Patrick's 
Day releases of 1.14.1

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 web visit 
https://groups.google.com/d/msgid/golang-nuts/a1e83ff5-5544-4129-bc44-bfd8e5f98fbc%40googlegroups.com.

Re: [go-nuts] Learning the runtime

[Ian Lance Taylor]

On Tue, Mar 3, 2020 at 9:15 PM  wrote:
>
> Is there any way to learn the internals of the runtime package, besides just 
> reading all the code? There are a lot of types in the package with cryptic 
> names and no documentation, so if all I have is the code, it's going to be a 
> steep learning curve.

Different parts of the runtime have different docs, although I'm not
aware of any place that gathers all those docs in a single place.

What part in particular are you interested in?

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/CAOyqgcWS-KYfve7iY%2BYR-amafNvSQrWPZefeU50ZF%3D%2BwiFEuZg%40mail.gmail.com.

[go-nuts] escape analysis question

[burns . ethan]

Hi All,

I am trying to debug why a byte slice is escaping in my program. I have a 
small reproducible example here:

% cat escape.go
package main

func main() {
x := make([]byte, 5)
y := new([]byte)
*y = x
nothing((*y)[3])
}

func nothing(b byte) {}
% go tool compile -m -m -l escape.go
escape.go:4:11: make([]byte, 5) escapes to heap:
escape.go:4:11:   flow: x = &{storage for make([]byte, 5)}:
escape.go:4:11: from make([]byte, 5) (spill) at escape.go:4:11
escape.go:4:11: from x := make([]byte, 5) (assign) at escape.go:4:4
escape.go:4:11:   flow: {heap} = x:
escape.go:4:11: from *y = x (assign) at escape.go:6:5
escape.go:4:11: make([]byte, 5) escapes to heap
escape.go:5:10: new([]byte) does not escape

It seems to me like neither x nor it's backing array should escape, but I'm 
having trouble figuring out why it's flagged as escaping from the debug 
output.

% go version
go version go1.14 darwin/amd64


Any help would be appreciated.

Ethan

-- 
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/4150346f-5b2f-4dab-852f-5b61315921ff%40googlegroups.com.

[go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

Folks,

First off thanks for the feedback!  -- positive and negative.

Second, hopefully people can trust that I fully understand the standard 
approach to code refactoring and writing tests.  I have done a bunch of it, 
and am sure will continue to do a bunch of it.  I understand the merits of 
it.  It is a valuable thing to do for the long run.  No pejorative is 
intended here.

That said, I am trying to reset here with another example about a possible 
new way to have good tests AND have code for which it is easy to quickly 
understand the relationships between all sub-tasks of the code -- it is 
modified code from *The Go Programming Language* book.  Note: There is a 
bunch of "goto nonsense" added to get the Go compiler to accept the 4 
labels for compiling.

The attributes that I would like to highlight are:

   1. a *single* function which accomplishes a complete task
   2. which is composed of *ordered* steps
   3. where some steps may have *sub-steps*, and perhaps sub-sub-steps

Observations:

   1. You can put this code into a modern editor with block expansion and 
   contraction, and contract the 3 main steps to easily show (without 
   scrolling) steps 1 to 3.
   2. You can then expand step2 alone and see how step2A is clearly a 
   sub-step of step2.
   3. You can also imagine how other sub-steps and sub-sub-steps would 
   maintain a *quasi-flow chart relationship* to each other -- top to 
   bottom, with indentation, etc.
   4. You can also imagine that each step and sub-step could be a proper 
   func if refactored out of the parent func.

Aspirations:

   1. Go language could be extended in some way that tests could be added 
   to steps WITHOUT refactoring the steps or sub-steps.
   2. Adding such tests could accomplish the same effects as refactored 
   code, but WITHOUT losing the quasi-flow chart relationship of the steps.
   3. Adding such tests could be faster to write by avoiding the 
   refactoring effort.
   4. Adding tests this way could potentially produce faster running code 
   by avoiding the extra calls required by refactored code.
   5. There is some possibility that a language extension could highlight 
   or define the specific variables that are most important to comprehend 
   while reading thru the code.
   6. There is some possibility that a language extension could allow vars 
   (such as 'err') to be redefined per step, rather than the sometimes 
   problematic "fall-thru" definition of vars in prior code.

Critiques welcome,

Warren

package main

import (
"fmt"
"sync"
)

func main() {

fmt.Printf("Hello folks!\n")
err := doSomeStuff(true)
if err != nil {
fmt.Printf("doThisStuff did not succeed! %v\n", err)
}
fmt.Printf("Goodbye folks!\n")
}

const N = 20

var naturals = make(chan int, N)
var squares = make(chan int, N)

func doSomeStuff(dummy bool) error {

var n sync.WaitGroup

// there is a bunch of nonsense added here to get the Go compiler to accept 
the 4 labels

// Counter
step1:
if dummy {
n.Add(1)
go func() {
for x := 0; x < N; x++ {
naturals <- x
}
n.Done()
}()
n.Wait()
if !dummy {
goto step1
}
}

// Squarer
step2:
if dummy {
n.Add(1)
go func() {
for x := 0; x < N; x++ {
v := <-naturals
squares <- v * v

// Squarer complainer
step2A:
if v > 100 {
fmt.Println("v is too big!")
v = 0
goto step2A
}
}
n.Done()
}()
n.Wait()
if !dummy {
goto step2
}
}

// Printer
step3:
if dummy {
n.Add(1)
go func() {
for x := 0; x < N; x++ {
n := <-squares
fmt.Println(x, n)
}
n.Done()
}()
n.Wait()
if !dummy {
goto step3
}
}

return nil
}


Again, it will be easier to understand the idea if the code is copied into 
an editor with a block expansion and contraction feature.


-- 
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/6e65e609-17cf-44cd-bb41-f6bd99969284%40googlegroups.com.

[go-nuts] Re: escape analysis question

['Kevin Chowski' via golang-nuts]

Slightly more minimal, in my testing it seems that the call to 'nothing' is 
not needed.

I do not quite know why, but these two lines seem to show how the compiler 
is reasoning about this escape:

escape.go:4:11:   flow: {heap} = x:
escape.go:4:11: from *y = x (assign) at escape.go:6:5

I do not know why it thinks assigning to '*y' is equivalent to assigning to 
the heap; later it even mentions that `new([]byte) does not escape`, and 
that is the definition of 'y'.

Sorry I'm not more helpful, I looked into this a bit more myself and also 
came up without any good answers.

On Wednesday, March 4, 2020 at 2:58:37 PM UTC-7, burns...@gmail.com wrote:
>
> Hi All,
>
> I am trying to debug why a byte slice is escaping in my program. I have a 
> small reproducible example here:
>
> % cat escape.go
> package main
>
> func main() {
> x := make([]byte, 5)
> y := new([]byte)
> *y = x
> nothing((*y)[3])
> }
>
> func nothing(b byte) {}
> % go tool compile -m -m -l escape.go
> escape.go:4:11: make([]byte, 5) escapes to heap:
> escape.go:4:11:   flow: x = &{storage for make([]byte, 5)}:
> escape.go:4:11: from make([]byte, 5) (spill) at escape.go:4:11
> escape.go:4:11: from x := make([]byte, 5) (assign) at escape.go:4:4
> escape.go:4:11:   flow: {heap} = x:
> escape.go:4:11: from *y = x (assign) at escape.go:6:5
> escape.go:4:11: make([]byte, 5) escapes to heap
> escape.go:5:10: new([]byte) does not escape
>
> It seems to me like neither x nor it's backing array should escape, but 
> I'm having trouble figuring out why it's flagged as escaping from the debug 
> output.
>
> % go version
> go version go1.14 darwin/amd64
>
>
> Any help would be appreciated.
>
> Ethan
>
>

-- 
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/a315ea46-f8ac-4a8f-bc43-c2b16367e72f%40googlegroups.com.

Re: [go-nuts] Go 1.14: how to -linkshared to a library produced by -buildmode=shared?

[Mikhail Gusarov]

Hi Bryan,

On 4 Mar 2020, at 2:27, 'Bryan C. Mills' via golang-nuts wrote:


Did this work in 1.13?


Actually, no. In 1.13 it triggers the panic as described in this bug:

https://golang.org/issue/35759 is probably related; see especially the 
TODO

here

.


Please file an issue  so we don't lose 
track

of it.


Sure filed as #37675.

--
Misha

--
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/B78E78D8-94F0-49C9-B814-872E9FE6CBA1%40ridge.co.

Re: [go-nuts] Re: escape analysis question

[Ethan Burns]

Thanks for looking into it and simplifying the example!

Just to explain, I added the call to nothing(), because I was worried that
otherwise the result would be recognized as unused and the entire code
would be optimized away. Good to know it's not relevant to reproduce.
Thanks again.

On Wed, Mar 4, 2020, 18:45 'Kevin Chowski' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Slightly more minimal, in my testing it seems that the call to 'nothing'
> is not needed.
>
> I do not quite know why, but these two lines seem to show how the compiler
> is reasoning about this escape:
>
> escape.go:4:11:   flow: {heap} = x:
> escape.go:4:11: from *y = x (assign) at escape.go:6:5
>
> I do not know why it thinks assigning to '*y' is equivalent to assigning
> to the heap; later it even mentions that `new([]byte) does not escape`, and
> that is the definition of 'y'.
>
> Sorry I'm not more helpful, I looked into this a bit more myself and also
> came up without any good answers.
>
> On Wednesday, March 4, 2020 at 2:58:37 PM UTC-7, burns...@gmail.com wrote:
>>
>> Hi All,
>>
>> I am trying to debug why a byte slice is escaping in my program. I have a
>> small reproducible example here:
>>
>> % cat escape.go
>> package main
>>
>> func main() {
>> x := make([]byte, 5)
>> y := new([]byte)
>> *y = x
>> nothing((*y)[3])
>> }
>>
>> func nothing(b byte) {}
>> % go tool compile -m -m -l escape.go
>> escape.go:4:11: make([]byte, 5) escapes to heap:
>> escape.go:4:11:   flow: x = &{storage for make([]byte, 5)}:
>> escape.go:4:11: from make([]byte, 5) (spill) at escape.go:4:11
>> escape.go:4:11: from x := make([]byte, 5) (assign) at escape.go:4:4
>> escape.go:4:11:   flow: {heap} = x:
>> escape.go:4:11: from *y = x (assign) at escape.go:6:5
>> escape.go:4:11: make([]byte, 5) escapes to heap
>> escape.go:5:10: new([]byte) does not escape
>>
>> It seems to me like neither x nor it's backing array should escape, but
>> I'm having trouble figuring out why it's flagged as escaping from the debug
>> output.
>>
>> % go version
>> go version go1.14 darwin/amd64
>>
>>
>> Any help would be appreciated.
>>
>> Ethan
>>
>> --
> 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/2s0_gQjR7yE/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/a315ea46-f8ac-4a8f-bc43-c2b16367e72f%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/CAGE%3DEi2AhqUE%3DyjX57472VTXco2JcuHAjZ4CskvNDdk-04_XeA%40mail.gmail.com.

Re: [go-nuts] Learning the runtime

['Keith Randall' via golang-nuts]

There are a bunch of talks from Gophercon and elsewhere that cover pieces 
of the runtime:

Channels: https://www.youtube.com/watch?v=KBZlN0izeiY
Scheduler: https://www.youtube.com/watch?v=YHRO5WQGh0k
Maps: https://www.youtube.com/watch?v=Tl7mi9QmLns [shameless self plug]
Goroutines, defers, stacks: https://www.youtube.com/watch?v=mYqhBYdqCyg

On Wednesday, March 4, 2020 at 1:23:35 PM UTC-8 Ian Lance Taylor wrote:

> On Tue, Mar 3, 2020 at 9:15 PM  wrote:
> >
> > Is there any way to learn the internals of the runtime package, besides 
> just reading all the code? There are a lot of types in the package with 
> cryptic names and no documentation, so if all I have is the code, it's 
> going to be a steep learning curve.
>
> Different parts of the runtime have different docs, although I'm not
> aware of any place that gathers all those docs in a single place.
>
> What part in particular are you interested in?
>
> 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/720c8ce7-a19f-4f9a-b548-5af543a3698a%40googlegroups.com.

[go-nuts] Re: Learning the runtime

[buchanae]

> What part in particular are you interested in?

I ended up in the runtime code because I'm interested in plugins, the 
linker, loader, and how the runtime manages types. In particular, I'm 
interested in https://github.com/golang/go/issues/28783. My comment here 
explains why: 
https://github.com/golang/go/issues/20461#issuecomment-593731566. So, I 
suppose I'm interested in how the runtime manages types, and how the 
garbage collector works.

I've started reading src/plugin, runtime/plugin.go, runtime/symtab.go, and 
runtime/iface.go. I have a loose understanding of what I see, but the 
details are still beyond me.

I'm also just interested in the challenge of learning the details of the 
runtime in general.

> There are a bunch of talks from Gophercon and elsewhere that cover pieces 
of the runtime:

Thanks! I'll check those out.

-- 
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/6584df93-61ef-46bc-981f-f3c9e6694544%40googlegroups.com.

[go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'

[Xiangdong JI]

Hi,

Given the attached screenshot of pprof output, I wonder how to figure out 
the callers of 'runtime.mcall' and their cost? Thanks.

(The image is generated by profiling BenchmarkGoroutineBlocking).

[image: Capture.JPG]


-- 
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/b0ac497f-ae50-4033-b970-d35c02350df3%40googlegroups.com.

Re: [go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'

[Ian Lance Taylor]

On Wed, Mar 4, 2020 at 6:44 PM Xiangdong JI  wrote:
>
> Given the attached screenshot of pprof output, I wonder how to figure out the 
> callers of 'runtime.mcall' and their cost? Thanks.

You can't, but it doesn't matter.  The mcall function is used when a
thread changes from executing one goroutine to a different goroutine.
Knowing the code that triggers the call into mcall won't tell you
anything.  It's just where that goroutine happened to be preempted.

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/CAOyqgcU8dz-VpQP7y4r%3D1sho_bLuLdMtfZbckyx7uFyEueDZ_g%40mail.gmail.com.

[go-nuts] Re: Learning the runtime

[buchanae]

Turns out, other parts of the runtime have decent docs – mgc.go is very 
well commented, for example. I may have started my research in the darkest 
corners (itab, ptab, ftab, oh my).

-- 
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/8ec6da8f-f6da-42fe-9023-ad1b87ac6d76%40googlegroups.com.

Re: [go-nuts] Pass C struct from Go to C method

[Nitish Saboo]

Hi Ian,

Thank you for the response.Got it.
Basically, fmt.Println(InitStruct) is printing the values of fields, cb and
data, for the struct Foo pointed by InitStruct.
fmt.Printf("%p\n", InitStruct) is printing the memory address.
Btw..can you please clarify the following :

1)Is this the correct way to pass a C struct from a Go code to C code.

2) Can I free the struct memory assigned to Initstruct using calloc on Go
side  in the following manner ?

if InitStruct != nil{
C.free(unsafe.Pointer(InitStruct))
}

Thanks,
Nitish



On Wed, Mar 4, 2020 at 11:19 PM Ian Lance Taylor  wrote:

> On Wed, Mar 4, 2020 at 3:57 AM Nitish Saboo 
> wrote:
> >
> > I have CGO project.
> >
> > Following is my C header file and Go code
> >
> > syslog-node.h
> > ===
> >
> > #ifndef _TEST_H_
> > #define _TEST_H_
> >
> > #include 
> >
> > typedef void (*key_value_cb)(const char* key, const char* value, size_t
> value_len, int work);
> > typedef struct Foo{
> > key_value_cb cb;
> > int data;
> > }Foo;
> > int initialize_engine(const char* filename, const char* module_path, Foo
> *cb);
> > int reload_pattern_db(const char* filename, Foo *cb);
> >
> >
> > cfunc.go
> > 
> > /*
> >
> > #include 
> >
> > // The gateway function
> > void callOnMeGo_cgo(char *key, char *value, size_t value_len, int work)
> > {
> > void ParsedData(const char *key, const char *value, size_t value_len,
> int work);
> > ParsedData(key, value, value_len, work);
> > }
> > */
> > import "C"
> >
> > main.go
> > 
> >
> > var InitStruct *C.struct_Foo;
> >
> > func InitializeEngine(pattern string, path string) {
> > pattern_db := C.CString(pattern)
> > module_path := C.CString(path)
> > if InitStruct != nil{
> > C.free(unsafe.Pointer(InitStruct))
> > }
> > InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> > InitStruct.data = C.int(0)
> > fmt.Println(InitStruct)  <<<'&{0x4b79d0 0 [0 0 0
> 0]}' got printed
> > C.initialize_engine(pattern_db, module_path, InitStruct)
> >
> > }
> >
> > func ReloadPatternDB(patterndb string) {
> >
> > path := C.CString(patterndb)
> > InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
>  << > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> > InitStruct.data = C.int(0)
> > fmt.Println(InitStruct)<<< '&{0x4b79d0 0 [0
> 0 0 0]}' got printed
> > C.reload_pattern_db(path, InitStruct)
> >
> > }
> >
> >
> > I have a Go code where I have to call C functions 'initialize_engine'
> and 'reload_pattern_db' respectively(one after the other ) and pass the C
> struct from Go code.
> >
> >
> > The issue is after allocating memory to 'InitStruct' using calloc in
> 'InitializeEngine' method, the same memory location is getting printed in
> ReloadPatternDB method even though I am allocating a new memory to
> 'InitStruct' using calloc in 'ReloadPatternDB' method.
> >
> > 1) Is this the correct way to pass a C struct from a Go code to C code.
> > 2) Is this a correct way to free the struct memory assigned to
> InitStruct using calloc on Go side ?
>
> You haven't showed us where the same memory location is getting
> printed.  Note that fmt.Println is not printing the address of
> InitStruct; it is printing the values of the fields.  If you want to
> print the address, use fmt.Printf("%p\n", InitStruct).
>
> Also note that InitStruct is a global variable.
>
> 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/CALjMrq5d-vh-StGaXJe3-aAAsajcrK%3D%3DDxe%3DOx_vxgW%3D1vvRSQ%40mail.gmail.com.

Re: [go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'

[Xiangdong JI]

Thanks Ian.

I'm using schedtrace and scheddetail to help understand the scheduling 
flow, the minimum monitoring window seems to be 1ms only, possible to get 
more detailed info?
Furthermore, sched* outputs extensive logs but what I expect, at present, 
might be something like when a goroutine is parked due to what reason, 
etc., can I get it with the existing diagnostics?  
 

On Thursday, March 5, 2020 at 11:24:23 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Mar 4, 2020 at 6:44 PM Xiangdong JI  > wrote: 
> > 
> > Given the attached screenshot of pprof output, I wonder how to figure 
> out the callers of 'runtime.mcall' and their cost? Thanks. 
>
> You can't, but it doesn't matter.  The mcall function is used when a 
> thread changes from executing one goroutine to a different goroutine. 
> Knowing the code that triggers the call into mcall won't tell you 
> anything.  It's just where that goroutine happened to be preempted. 
>
> 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/71ecd07a-0b42-4eba-9b22-5c7cc9821243%40googlegroups.com.

[go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Tamás Gulácsi]

If the (sub)step alone is comprehensible just in itself, hiding the previous 
(sub)steps and its context, then it is comprehensible when refactored to a 
separate function.

An then it is separately testable, documentable, and no collapsing esitor help 
is neede when viewing them main function, listing those (sub)steps.

I understand that refactoring is a risk, but adding a new language feature just 
to keep the current unstructured code, is plain wrong.

-- 
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/8832e0fd-ecf2-4261-ac8e-7a0afa51ff1f%40googlegroups.com.