[go-nuts] Re: How do you escape a dot in a /usr/local/go/src/cmd/go/testdata/script pattern

[Gert]

never mind, just plain regex \[ \.

On Wednesday, December 18, 2019 at 2:38:52 AM UTC+1, Gert wrote:
>
>
> https://go-review.googlesource.com/c/go/+/201857/7/src/cmd/go/testdata/script/doc.txt
>
> go test cmd/go -run=Script/^doc$
>
> I guess this fails because of a dot located in the pattern 'go doc 
> [.]' 
>
> How do you escape it?
>

-- 
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/2b31b085-664d-432d-991f-0570d1ba0eff%40googlegroups.com.

[go-nuts] How do you escape a dot in a /usr/local/go/src/cmd/go/testdata/script pattern

[Gert]

https://go-review.googlesource.com/c/go/+/201857/7/src/cmd/go/testdata/script/doc.txt

go test cmd/go -run=Script/^doc$

I guess this fails because of a dot located in the pattern 'go doc 
[.]' 

How do you escape it?

-- 
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/0314701c-690b-48ee-80d4-63fa05c35f65%40googlegroups.com.

Re: [go-nuts] How to mock structs with interdependent interface methods?

[Karthik Krishnamurthy]

Thanks for the response Ian. My apologies for a delayed response (inline).

On Friday, December 13, 2019 at 6:11:20 AM UTC-8, Ian Davis wrote:
>
> On Thu, 12 Dec 2019, at 10:27 PM, karth...@gmail.com  wrote:
>
> Specifically, I couldn't find how to partially mock the struct. Most 
> suggestions revolve around breaking such structs but in this case, the 
> struct is already at its bare minimum. It seems like a fair ask to not 
> break the ResourceManager interface (into single and multi) for the sake 
> of testing as that would not make much sense and would be kludgy at best 
> and wouldn't scale well as more such methods make into the interface.
>
>
> I think your problems likely stem from having interfaces that are too 
> large. Interfaces in Go are more flexible than in many other languages 
> since there is no "implements" keyword that binds a struct to a particular 
> interface. This means that you can have many more specialised interfaces 
> that your struct may automatically satisfy.
>
> One consequence of this is that In Go it is usually preferable to define 
> the interface where it is consumed instead of where the implementations 
> are. This tends to make interfaces smaller, having just the methods needed 
> for the consumer. It also implies that testing via the interface is the 
> wrong approach.
>
 
This is a bit counterintuitive. Maybe this is how golang expects developers 
to write, but it is generally preferable to think of an interface as a 
contract that must be satisfied by any struct implementing it. For e.g., 
io.Writer interface expects any "writable" to implement the "Write" method 
and so, can be passed to any method that expects an io.Writer. This is 
pretty much I am trying to do. I want any struct to be able to implement 
the ResourceManager interface and thus can be passed to any method that 
accepts the ResourceManager interface.


> First write your tests against the struct to verify that getting one or 
> all resources work.
>

Right here, is my problem. Let's assume that I do write such a struct. 
However, it is not obvious to me how I can test GetAllResources when it 
internally invokes GetResource. One solution that I found was to have 
package level functions get and getAll and when mocking getAll, replace the 
get function with a mock. This is still a bit kludgy, but for now, I don't 
see a better alternative.
 

> Break the interface into smaller specialised ones and move them next to 
> the consuming code. In your case you may have an endpoint that uses a 
> GetResource method, so you define that interface. Another endpoint may need 
> just the GetAllResources method: another interface. You can then test your 
> endpoints by supplying a test struct that implements the smaller interface 
> needed.
>

I think the solution you propose above is for a problem that is different 
that I asked. My question was how to test the ResourceManagerImpl struct.
 

>
>
> -- 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/731c8690-2ffe-4093-83b2-b2b95eff425f%40googlegroups.com.

[go-nuts] Go 1.14 Beta 1 is released

[Alexander Rakoczy]

Hello gophers,

We have just released go1.14beta1, a beta version of Go 1.14.
It is cut from the master branch at the revision tagged go1.14beta1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

The macOS release of Go 1.14 enables the Hardened Runtime. See
https://golang.org/issue/34986 for details.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.14beta1
is by using the go command:
$ go get golang.org/dl/go1.14beta1
$ go1.14beta1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.14beta1

To find out what has changed in Go 1.14, read the draft release notes:
https://tip.golang.org/doc/go1.14

Cheers,
Alex for the Go Team

-- 
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/CAFtHmMgiQSvgj76oeLjomL4BVwkDZhmp8NhX8YQPHd2rWjJJEg%40mail.gmail.com.

Re: [go-nuts] Locking goroutine to "main" thread

[Alex Buchanan]

Yep. My understanding of locking the OS thread from an init() was wrong. I 
think I have it working now. Thanks guys!

On Tue, Dec 17, 2019, at 9:37 AM, Ian Davis wrote:
> 
> 
> On Sat, 14 Dec 2019, at 7:51 PM, bucha...@gmail.com wrote:
>> If I understand correctly, that would prevent me from starting any other 
>> goroutines. The following program deadlocks:
> 
> I doesn't prevent you starting other goroutines but you need to ensure that 
> all calls to the OpenGL context are performed on the thread you initialised 
> it with (my understanding is that this is because OpenGL uses thread local 
> storage). Typically you can do this by sending closures containing OpenGL 
> calls via a channel to an executor running in a goroutine locked to the main 
> thread. There is/was an example of this in the gomobile codebase. I can share 
> more detail if you get stuck.
> 
> -- Ian
> 
> 
> 

> --
>  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/zAB8Si7EMVM/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/0adcdc5a-dd2c-4506-9110-a3ecabc508b9%40www.fastmail.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/a90ad587-495c-4edf-bbc1-82491f2e6238%40www.fastmail.com.

Re: [go-nuts] Locking goroutine to "main" thread

[Ian Davis]

On Sat, 14 Dec 2019, at 7:51 PM, bucha...@gmail.com wrote:
> If I understand correctly, that would prevent me from starting any other 
> goroutines. The following program deadlocks:

I doesn't prevent you starting other goroutines but you need to ensure that all 
calls to the OpenGL context are performed on the thread you initialised it with 
(my understanding is that this is because OpenGL uses thread local storage). 
Typically you can do this by sending closures containing OpenGL calls via a 
channel to an executor running in a goroutine locked to the main thread. There 
is/was an example of this in the gomobile codebase. I can share more detail if 
you get stuck.

-- 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/0adcdc5a-dd2c-4506-9110-a3ecabc508b9%40www.fastmail.com.

[go-nuts] Help get me started on a project

[Rich]

I need to write a program that runs an external program and the user needs 
to interact with that external program.  So I know I can do something like 
this:


func main() {
cmd := exec.Command("/usr/local/bin/interactiveApp")
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
cmd.Run()

What I need to be able to do is look at what the user is typing as the user 
can make some errors that would be unfortunate, So what I want to do is 
look at what the user typed and tell them that isn't possible. If the 
command is good send it.

User: "self destruct in 10 minutes"
MyApp: "sorry you can't do that."

This is very similar to what you can do with Don Libes's Expect interact 
statement which works like a switch statement, if a match is found, it runs 
that instead of what the user typed. 

spawn "/usr/local/bin/interactiveApp"
...stuff...

interact {
"self destruct" {
send_user "Sorry you can't run that"
send "start over"
}
}
 
So if the user types "self destruct" the program will send a message to the 
user, and then send 'start over' to the interactiveApp.I've looked 
around and I've not seen anything that can reliably read from what the user 
types in, evaluate it,  and pass it to the program that is launched by exec.

I didn't write the app we're  running, and the guy that wrote it is not 
able to support it any longer. I"d write it in expect but expect uses TCL 
which is very very slow, and there are other aspects to Go that I really 
need in other areas of the program.

Thanks! 

-- 
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/65aab0d3-0d74-425e-a4fe-c26c39b98169%40googlegroups.com.

Re: [go-nuts] runtime.pclntab strippping

[rojer9]

i did a quick experiment with getting rid of strings - made 
cmd/link.ftabaddstr a no-op.
that didn't actually save that much: i got rid of all stringtab and it 
saved about 600K of the original 2.8M pclntab, or 20%, give or take.
the remainder compresses to about 800K with xz -9, so there's quite a bit 
of redundancy there.
all of the above is for ARM builds, for amd64 there's even more due to 
64-bit pointers, higher bytes of which are mostly zeroes.
for this particular binary:

pclntab.amd64 - 3341578 
pclntab.amd64.nostr - 2728272
pclntab.arm5 - 2844248
pclntab.arm5.nostr - 2246896

On Tuesday, December 17, 2019 at 12:09:15 PM UTC, Deomid Ryabkov wrote:
>
> running into the same issue: embedded system, fat Go binaries, 20% is the 
> symbol table.
> +1 for slimming it down, perhaps with full non-stripped version emitted 
> separately to analyze stack traces later (like it's common to keep 
> non-stripped binaries for that reason).
> is there an issue already for that? should one be created?
>
> On Friday, April 5, 2019 at 3:07:10 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Apr 5, 2019 at 5:33 AM Steeve Morin  wrote: 
>> > 
>> > Removing the function names and file information probably constitutes 
>> the 
>> > most part of the size, I would guess. 
>> > 
>> > Do you suggest stripping it as a post processing step or modifying the 
>> linker 
>> > to not emit the strings in the first place? 
>> > I'm not fond of adding a new flag to the linker, but it may not be such 
>> a bad 
>> > idea in a mobile context to remove function names and file information. 
>>
>> I doubt it's feasible to strip the names after the fact; I think it 
>> would have to be a linker option.  (I'm not promising that such a 
>> linker option would be accepted into the main tree.) 
>>
>> > I would assume most of that happens in cmd/link/internal/ld/pcln.go 
>> right ? 
>>
>> As far as I know, yes. 
>>
>> Ian 
>>
>>
>> > On Friday, April 5, 2019 at 12:14:49 AM UTC+2, Ian Lance Taylor wrote: 
>> >> 
>> >> On Thu, Apr 4, 2019 at 2:32 PM Steeve Morin  
>> wrote: 
>> >> > 
>> >> > We are big Go users on Android and iOS thanks to golang/mobile. 
>> >> > 
>> >> > Lately we were doing some size profiling and stumbled upon 
>> runtime.pclntab, 
>> >> > which in our case represents almost 20% of the file size according 
>> to bloaty. 
>> >> > Now I understand that it's used for things like runtime.Caller and 
>> panics. 
>> >> > That said, in a mobile context panics are not that useful as this 
>> job is handled by 
>> >> > services like Crashlytics and DWARF. 
>> >> > 
>> >> > So we were wondering if it would be possible to strip it (or not 
>> emit it altogether) 
>> >> > and what would be the consequences/limitations of that? 
>> >> 
>> >> The consequences of removing pclntab would be fairly severe.  You 
>> >> wouldn't just lose runtime.Callers and stack traces and tracing and 
>> >> profiling.  The pclntab section is also used by the garbage collector 
>> >> to traverse the stack, and by the stack copying code.  I doubt that 
>> >> many substantial Go programs would still work correctly. 
>> >> 
>> >> That said you could in principle drop part of pclntab with less severe 
>> >> consequences, such as removing the function names.  I don't know of 
>> >> any supported way to do that, though. 
>> >> 
>> >> 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 golan...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
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/ecfe5aaf-5578-41c0-b84e-e7a4a4751a69%40googlegroups.com.

Re: [go-nuts] runtime.pclntab strippping

[rojer9]

running into the same issue: embedded system, fat Go binaries, 20% is the 
symbol table.
+1 for slimming it down, perhaps with full non-stripped version emitted 
separately to analyze stack traces later (like it's common to keep 
non-stripped binaries for that reason).
is there an issue already for that? should one be created?

On Friday, April 5, 2019 at 3:07:10 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Apr 5, 2019 at 5:33 AM Steeve Morin  > wrote: 
> > 
> > Removing the function names and file information probably constitutes 
> the 
> > most part of the size, I would guess. 
> > 
> > Do you suggest stripping it as a post processing step or modifying the 
> linker 
> > to not emit the strings in the first place? 
> > I'm not fond of adding a new flag to the linker, but it may not be such 
> a bad 
> > idea in a mobile context to remove function names and file information. 
>
> I doubt it's feasible to strip the names after the fact; I think it 
> would have to be a linker option.  (I'm not promising that such a 
> linker option would be accepted into the main tree.) 
>
> > I would assume most of that happens in cmd/link/internal/ld/pcln.go 
> right ? 
>
> As far as I know, yes. 
>
> Ian 
>
>
> > On Friday, April 5, 2019 at 12:14:49 AM UTC+2, Ian Lance Taylor wrote: 
> >> 
> >> On Thu, Apr 4, 2019 at 2:32 PM Steeve Morin  
> wrote: 
> >> > 
> >> > We are big Go users on Android and iOS thanks to golang/mobile. 
> >> > 
> >> > Lately we were doing some size profiling and stumbled upon 
> runtime.pclntab, 
> >> > which in our case represents almost 20% of the file size according to 
> bloaty. 
> >> > Now I understand that it's used for things like runtime.Caller and 
> panics. 
> >> > That said, in a mobile context panics are not that useful as this job 
> is handled by 
> >> > services like Crashlytics and DWARF. 
> >> > 
> >> > So we were wondering if it would be possible to strip it (or not emit 
> it altogether) 
> >> > and what would be the consequences/limitations of that? 
> >> 
> >> The consequences of removing pclntab would be fairly severe.  You 
> >> wouldn't just lose runtime.Callers and stack traces and tracing and 
> >> profiling.  The pclntab section is also used by the garbage collector 
> >> to traverse the stack, and by the stack copying code.  I doubt that 
> >> many substantial Go programs would still work correctly. 
> >> 
> >> That said you could in principle drop part of pclntab with less severe 
> >> consequences, such as removing the function names.  I don't know of 
> >> any supported way to do that, though. 
> >> 
> >> 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 golan...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/6c0ca792-bfcc-41dd-bbac-1d30e1497d72%40googlegroups.com.