Re: [go-nuts] Re: Q about defer

[Kevin Malachowski]

Actually, this part is a bit more relevant:

"That is, if the surrounding function returns through an explicit return
statement, deferred functions are executed after any result parameters are
set by that return statement but before the function returns to its caller."

On Fri, Dec 24, 2021, 12:50 PM Kevin Chowski  wrote:

> Specifically, this part from the #Defer_statements linked by Peter:
>
> "For instance, if the deferred function is a function literal and the
> surrounding function has named result parameters that are in scope within
> the literal, the deferred function may access and modify the result
> parameters before they are returned."
>
> In the case of `test`, the x variable is a named return variable so the
> defer is able to modify the returned value after the `return` but before
> the caller receives the result.
>
> In the case of `anotherTest`, the x variable is a local variable; when the
> `return x` is executed, the value of `x` is effectively copied into a new
> location that is distinct from the `x` variable, so the defer is modifying
> a different value than the one that is actually being returned.
>
> As a third example, note that you can also return a value directly even
> when using named return variables, which will immediately set the return
> variables to the values in the return statement before defers are executed:
> https://play.golang.com/p/JduT2zD5Nah
>
>
> On Friday, December 24, 2021 at 7:39:32 AM UTC-7 peterGo wrote:
>
>> The Go Programming Language Specification
>>
>> https://go.dev/ref/spec
>>
>> Defer statements
>>
>> https://go.dev/ref/spec#Defer_statements
>>
>> Peter
>>
>> On Friday, December 24, 2021 at 8:34:58 AM UTC-5 muhorto...@gmail.com
>> wrote:
>>
>>> https://play.golang.com/p/lypWMc6Kuff
>>> Why do we get 2 in test() and 1 in anotherTest()? Is it related to the
>>> definition of the variable in the output?
>>>
>> --
> 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/CS-YQw_xAtc/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/96cc1555-2b1e-4094-ae16-a9168acbe1a1n%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/CAPOrGrk0MDK%2BKO%2BkfAGocRKJrWn5pyOBzrRJxkfR9bvZ%3DapO5w%40mail.gmail.com.

[go-nuts] testing code that uses ioutil.ReadDir?

[Kevin Malachowski]

Is there a particular reason you want 100% code coverage?

Not trying to start a flame war: given limited time and effort, unless the rest 
of my projects had 100% coverage already, I would personally spend my time 
working with a package with lower coverage, or just fixing known bugs. If your 
codebase has no bugs and otherwise full coverage... I have to say I'm jealous :)

In any case, one way to test your application's handling of an error from that 
function is to fake it out during unit tests (simple example, let me know if 
you want a more thorough one: https://play.golang.org/p/uKGFLYVlQxz). Of course 
this does not test the "integration" of your application code and 
ioutil.ReadDir, but IMHO trying to get extremely high code coverage in non-unit 
tests is really a time sink.

-- 
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/1908d64d-fb3f-4d73-9302-b215c49dac36%40googlegroups.com.

[go-nuts] pprof "disasm" command not working?

[Kevin Malachowski]

This is perhaps due to some silly thing I am doing, but I at least have a 
minimal test case so I figured I'd reach out for help at this point: I 
cannot get "disasm" in "go tool pprof" working. "list" works correctly 
afaict (and weblist too), but "disasm" only prints out the total time, not 
the expected output as implied by online docs and blogs that I've found.

Go version: go version go1.13.6 windows/amd64

Minimal reproducer:
   1. Compile an extremely simple program which imports "net/http/pprof" 
and otherwise does busy work (https://play.golang.org/p/RZakdbLqiTQ).
   2. Run that program
   3. Run "go tool pprof localhost:1123/debug/pprof/profile?seconds=3"
   4. Inside the pprof commandline, try "list" and "disasm"; note the (lack 
of) output for disasm:

(pprof) list callAThing
> Total: 3.47s
> ROUTINE  main.callAThing in 
> C:\Users\chowski\prog\gopath\src\sandbox\pprof_not_working\test_pprof.go
>   60ms  2.94s (flat, cum) 84.73% of Total
>  .  . 16:   callAThing(i)
>  .  . 17:   }
>  .  . 18:}
>  .  . 19:
>  .  . 20:func callAThing(i int) int {
>   30ms   30ms 21:   for x := 0; x < 1; x++ {
>   10ms  1.83s 22:   y := fmt.Sprintf("%d; %v", x, i)
>   20ms  1.08s 23:   fmt.Fprintf(ioutil.Discard, "%s", 
> y)
>  .  . 24:   }
>  .  . 25:   return i
>  .  . 26:}
> (pprof) disasm callAThing
> Total: 3.47s
> (pprof)


Anyone know what I'm doing wrong? Is there a program that I need to have 
installed to get this to work?

-- 
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/6e34c030-56e3-4d13-ac0c-277afdd588da%40googlegroups.com.

Re: [go-nuts] Re: [64]byte()[:]

[Kevin Malachowski]

Good call, I don't know why I didn't think of the stack allocation.

The conversion to string first is also quite interesting. If bytes.Equal is
inlined in practice, profiling is probably the only way to tell which is
faster.




On Sun, Nov 17, 2019, 2:48 AM Axel Wagner 
wrote:

> On Sun, Nov 17, 2019 at 1:00 AM Kevin Malachowski 
> wrote:
>
>> "make"ing a byre slice every time you call Equal is not likely as
>> efficient; surely it will put pressure on the garbage collector, assuming
>> it's not just called a few times.
>>
>
> AFAICT the compiler correctly deduces that the slice doesn't escape and
> puts it on the stack. So, no, it doesn't :)
>
>
>>
>> Writing something in less lines is not strictly better. I'd probably just
>> make package level variable and reuse it among multiple calls to that
>> function.
>>
>> --
>> 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/9cfa25b8-4a18-47ca-9f37-5d5ae5b71849%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/CAPOrGrkJQXfqMmi%3Dbyx63CHNg-0%2BHSmvEOuqHSw%2B8mWQToj%3DPg%40mail.gmail.com.

[go-nuts] Re: [64]byte()[:]

[Kevin Malachowski]

"make"ing a byre slice every time you call Equal is not likely as efficient; 
surely it will put pressure on the garbage collector, assuming it's not just 
called a few times.

Writing something in less lines is not strictly better. I'd probably just make 
package level variable and reuse it among multiple calls to that function.

-- 
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/9cfa25b8-4a18-47ca-9f37-5d5ae5b71849%40googlegroups.com.

Re: [go-nuts] go runtime/stubs.go noescape

[Kevin Malachowski]

I believe the question was about the specific implementation of noescape, 
specifically the "exclusive or" in that unsafe expression.

To the original poster: are you just curious why, or is there a more specific 
question you have? I'm assuming that function looks like that to correctly 
trick the compiler; perhaps escape analysis gives up if you start xor-ing 
uintptr values or something like that.

-- 
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/2f2b4f8d-1218-4a12-adf1-34e8b4d63648%40googlegroups.com.

[go-nuts] runtime.readmemstats -> buckhash_sys increase

['Kevin Malachowski' via golang-nuts]

Is your application leaking memory allocated in C? (Are you using cgo-related 
packages at all?)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Q on using reflect: how to distinguish methods from functions?

[Kevin Malachowski]

Why do you need to figure out whether something is a Method? Usually it doesn't 
really matter.

(I don't have an answer for you, but if you give more background I or someone 
else may be able to be more useful; trying to avoid the X-Y problem.)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] scanner.Scan is holding my goroutine ;(

['Kevin Malachowski' via golang-nuts]

Can you post a short, self-contained (compile-able and runnable) example which 
shows the problem? Preferably hosted on play.golang.org for easy sharing and 
editing.

If the scanner is reading from a reader which has been closed (returns io.EOF), 
the sc.Scan should return false (and the sc.Err would return nil). Depending on 
the surrounding code, that should mean that the for loop you presented should 
terminate. It's possible the code which contains your bug has not been shared, 
so posting a self-contained reproduction program would help move the 
conversation forward.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

['Kevin Malachowski' via golang-nuts]

The best way to access the return value of a function is to name the return 
variable:

func DoTwoThings(db *Database) (err error) {
tx, err := db.Begin()
if err != nil {
return err
}
defer tx.Close()

...
}

Then any accidental shadowing doesn't matter because the "defer" is 
referring to the actual return variable; it also means that you can support 
returning a new error directly (i.e. `return nil, fmt.Errorf(...)`) rather 
than needing to set the outer 'err' variable and then return it.

On Monday, December 3, 2018 at 3:55:03 PM UTC-8, Ben Hoyt wrote:
>
> Robert, here is code (actual working code this time) similar to what we 
> have: https://play.golang.org/p/jUPqgnk6Ttk
>
> Leonel, yep, I understand that, which is why we have this problem. The 
> thing is, this pattern makes it very easy to forget to always re-use the 
> same error variable, especially in code that's a bit more complex with a 
> bunch of nested ifs, etc. So we're trying to come up with a pattern that's 
> hard or impossible to misuse, instead of easy to misuse.
>
> -Ben
>
> On Mon, Dec 3, 2018 at 6:46 PM Leonel Quinteros  > wrote:
>
>> Hi Ben, 
>>
>> I'm pretty sure that the *err* variable is getting shadowed on your 
>> Update construct. 
>> Instead of doing: 
>>
>> if _, err := UpdateBar(tx); err != nil {
>> return err
>> }
>>
>> You should do something like: 
>>
>> _, err = UpdateBar(tx)
>> if err != nil {
>> return err
>> }
>>
>> Just like you do with the insert and avoiding the *:=* operand
>>
>> Let me know if that works. 
>>
>>
>> Best! 
>> Leonel
>>
>>
>> El lunes, 3 de diciembre de 2018, 18:53:30 (UTC-3), Ben Hoyt escribió:
>>>
>>> Hi folks,
>>>
>>> We found some subtle bugs in our db transaction code for handling 
>>> commits/rollbacks. Here's the pattern we were using (not real, but shows 
>>> the issue):
>>>
>>> func DoTwoThings() error {
>>> tx, err := db.Begin()
>>> if err != nil {
>>> return err
>>> }
>>> // commit or rollback the transaction before we return
>>> defer tx.Close()
>>>
>>> err := InsertFoo(tx)
>>> if err != nil {
>>> return err
>>> }
>>> if _, err := UpdateBar(tx); err != nil {
>>> return err
>>> }
>>> return nil
>>> }
>>>
>>> The problem is there's a subtle but potentially quite bad bug with this 
>>> usage pattern -- if the InsertFoo succeeds but UpdateBar fails, the first 
>>> "err" variable will be nil, so the deferred tx.Close() will COMMIT the 
>>> transaction rather than ROLLBACK, and the database will be in an 
>>> inconsistent state.
>>>
>>> The code above is a bit contrived, and you can easily fix it by moving 
>>> the "_, err := UpdateBar()" outside of the if so it's referring to the same 
>>> "err" variable, but it's very easy to miss and get it wrong. So we decided 
>>> it was a bad pattern and started thinking about the best way to fix.
>>>
>>> One idea is a RollbackUnlessCommitted() function which you can defer, 
>>> and then you call Commit() once manually (stolen from gocraft/dbr):
>>>
>>> func DoTwoThings() error {
>>> tx, err := db.Begin()
>>> if err != nil {
>>> return err
>>> }
>>> defer tx.RollbackUnlessCommitted()
>>>
>>> err := InsertFoo(tx)
>>> if err != nil {
>>> return err
>>> }
>>> if _, err := UpdateBar(tx); err != nil {
>>> return err
>>> }
>>> tx.Commit()
>>> return nil
>>> }
>>>
>>> Another idea is to create a "Transact" function which takes an anonymous 
>>> function and does all the transaction handling:
>>>
>>> func (db *DatabaseImpl) Transact(txFunc func() error) (err error) {
>>> tx, err := db.Begin()
>>> if err != nil {
>>> return
>>> }
>>> defer func() {
>>> if p := recover(); p != nil {
>>> tx.Rollback()
>>> panic(p) // re-throw panic after Rollback
>>> } else if err != nil {
>>> tx.Rollback() // err is non-nil; don't change it
>>> } else {
>>> err = tx.Commit() // err is nil; if Commit returns error 
>>> update err
>>> }
>>> }()
>>> err = txFunc(tx)
>>> return err
>>> }
>>>
>>> And then the DoTwoThings function becomes:
>>>
>>> func DoTwoThings() error {
>>> return db.Transact(func() error) {
>>> err := InsertFoo(tx)
>>> if err != nil {
>>> return err
>>> }
>>> if _, err := UpdateBar(tx); err != nil {
>>> return err
>>> }
>>> })
>>> }
>>>
>>> I think the second is probably safer and nicer, but it's slightly 
>>> awkward in that it requires an extra level of indentation. Still, awkward 
>>> is better than buggy.
>>>
>>> Does anyone else have a better pattern for this kind of thing, or 
>>> feedback on the above?
>>>
>>> -Ben
>>>
>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> 

[go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

['Kevin Malachowski' via golang-nuts]

If you can't recompile the binary, an option is to use a generic dynamic 
instrumentation platform like DynamoRIO 
 (which I think works for Go 
programs after a recent bugfix). It works on windows, mac, and linux, and 
has been used in the past for various security-based testing and 
verification. Plenty of papers available on the 
website: http://dynamorio.org/pubs.html



On Thursday, November 15, 2018 at 3:06:11 PM UTC-8, Damian Gryski wrote:
>
> One approach would be to augment the compiler to instrument the binary 
> with the techniques outlined in:
>
> XRay: A Function Call Tracing System
> https://ai.google/research/pubs/pub45287
>
> Damian
>
> On Thursday, November 15, 2018 at 9:09:19 AM UTC-8, ju...@sqreen.io wrote:
>>
>> Hi,
>>
>> I am working on dynamic instrumentation of Go programs at run time, 
>> possibly without static source-code instrumentation. As I would like a 
>> solution as close to Go and standard as possible, I was first thinking of 
>> using `go generate` to generate a file adding things `reflect` doesn't 
>> provide such as the list of packages, functions, global variables... That 
>> way, I should be able to use `reflect` to modify any dynamic calls by 
>> modifying the method tables of their underlying type representations.
>>
>> But regarding statically linked calls, the less intrusive technique I 
>> found are uprobes, which is linux-specific. And at the opposite, there are 
>> user-space binary code instrumentation libraries such as dyninst that 
>> modify the code at run time...
>>
>> So I am wondering if anyone here has any thoughts on this subject, that 
>> doesn't seem to be solved for Go programs.
>>
>> Thanks!
>>
>> Julio
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Garbage collector and Slices

['Kevin Malachowski' via golang-nuts]

That information is old now - Go has a precise GC now. There is some sort 
of metadata stored for each variable related to whether the type contains 
pointers (as Jan alluded to earlier in the thread).

On Monday, August 20, 2018 at 7:28:51 AM UTC-7, Florian Uekermann wrote:
>
> From the GC POV, the only interesting thing about an unsafe.Pointer is if 
>> its value falls anywhere into a GC managed memory block for liveness 
>> analysis, AFAIK.
>>
> And then it will check that memory block for stuff that looks like a 
> pointer (not caring what the actual type being pointed to is) afaik. That 
> is what I meant with conservative GC.
> I found a thread from  2013, where Ian says the same 
> https://groups.google.com/forum/#!topic/golang-nuts/yNis7bQG_rY.
> Maybe my information is outdated, I haven't followed the GC evolution in 
> recent years that closely.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why "strings" package exists ?

[Kevin Malachowski]

Well, the 'error' type has a method. But none of the other primitives do.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Silent errors during template execution

[Kevin Malachowski]

Can you post a minimal (but compilable and runnable) example which shows 
exactly what isn't working? You can create and share this conveniently using 
play.golang.org.

Creating a small, self-contained example is helpful in that it helps us see 
exactly what isn't working, and can be helpful to you because the effort 
required to produce this example sometimes ends up leading you to your own bug. 
For example, since you didn't post any Go code, it's hard to tell if you're 
just running into a simple mistake like forgetting to check for an error 
somewhere.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tweaking sync.Pool for mostly-empty pools

[Kevin Malachowski]

If there is likely nothing in the Pool, then maybe it's better to not use 
one at all. Can you compare the internal workload with an implementation 
where all callers just call the `New` function directly? What's the purpose 
of using a pooled memory if there's often nothing in the pool?

On Wednesday, February 14, 2018 at 3:56:34 PM UTC-8, Carlo Alberto Ferraris 
wrote:
>
> In an attempt to reduce the time pprof says is spent in sync.Pool 
> (internal workloads, sorry) I modified Get and getSlow to skip locking the 
> per-P shared pools if the pools are likely to be empty. This yields 
> promising results, but I'm not sure the approach is sound since the check I 
> do is inherently racy.
>
> As a (artificial and contrived) benchmark, I'm using this:
>
> func BenchmarkPoolUnderflow(b *testing.B) {
>   var p Pool
>   b.RunParallel(func(pb *testing.PB) {
> for pb.Next() {
>   p.Put(1)
>   p.Get()
>   p.Get()
> }
>   })
> }
>
> This is meant to simulate a pool in which more or objects are Get() than 
> are Put() (it wouldn't make much sense to simulate a pool in which we only 
> get, so to keep things simple I opted for a 2:1 ratio)
>
> The change I applied to Get and getSlow is the following. Starting from 
> the current pattern of:
>
> l := ... # per-P poolLocal
> l.Lock()
> last := len(l.shared) - 1
> if last >= 0 {
>   x = l.shared[last]
>   l.shared = l.shared[:last]
> }
> l.Unlock()
>
> I add a check (not protected by the mutex, that is the expensive op we're 
> trying to skip if it's not necessary) to see if the pool is likely to be 
> non-empty: 
>
> l := ... # per-P poolLocal
> if len(l.shared) > 0 { # the racy check for non-emptiness
>   l.Lock()
>   last := len(l.shared) - 1
>   if last >= 0 {
> x = l.shared[last]
> l.shared = l.shared[:last]
>   }
>   l.Unlock()
> }
>
> I know I should not call this a benign race, but in this case I don't see 
> how this can lead to problems. If the racy check gets it right, then it's 
> almost a net win. If if it gets it wrong, either we do what we do now (i.e. 
> we lock, just to find an empty pool), or we skip an otherwise non-empty 
> pool - thereby failing to immediately return an otherwise reusable object 
> (note that 1. there is a per-P shared pool for each P, so I'd estimate the 
> chances of this happening on all of them to be pretty low and 2. the Pool 
> documentation explicitly say that Get is allowed to treat the pool as 
> empty). Also note that the race detector is already explicitly disabled in 
> all sync.Pool methods.
>
> The reason I'm asking is to understand whether my reasoning is sound and, 
> regardless, if anybody has suggestions about how to do this in a better way.
>
> The current results (of the approach above, plus some refactoring to 
> recover some lost performance on the other benchmarks) on my laptop are the 
> following:
>
> name old time/op  new time/op  delta
> Pool-4   14.5ns ± 3%  14.2ns ± 2%   -1.64%  (p=0.023 n=9+10)
> PoolOverflow-4   1.99µs ±12%  1.78µs ± 1%  -10.62%  (p=0.000 n=10+8)
> PoolUnderflow-4   152ns ± 6%30ns ± 1%  -80.00%  (p=0.000 n=10+8)
>
> (the first two benchmarks are already part of sync.Pool, the last one is 
> the one I described above)
>
> Any feedback is welcome. If this is deemed safe I'm going to submit a CL.
>
> Carlo
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is it possible to determine total number of bytes read/written for an HTTP request? (including headers)

[Kevin Malachowski]

Given TCP connection reuse I don't think the os/kernel will be able to tell 
apart the TCP connections any better than intercepting the net.Conn with a 
custom listener. Especially if you're using anything encrypted, staying in Go 
is going to be necessary for you to get the sort of data you need.

You might be able to use your wrapped Listener strategy if you are willing to 
set "Connection: Close" on your incoming connections. I suspect that will 
degrade performance though. You might be able to hack together a Listener which 
is actually able to pool http client connections yet convince the http library 
to Close them when it is done with each request, but that sounds hard to do 
well and would likely to tightly coupled to the http package's implementation.

Do you need an exact count? You could probably get a pretty good estimation by 
just serializing the HTTP headers, counting how long that is, and adding in the 
size of the Body.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] A string with zero ptr and cause SIGSEGV

[Kevin Malachowski]

Try running the code with the race detector (compile with -race), mysterious 
crashes are usually caused by data races.

It's weird that it would happen with a string parameter to a function though. 
Are you using multiple goroutines in that function to modify/access a string? 
Can you share the code of the rest of the function, or create a small 
reproducing test case?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON and Embedded Types (Aliases)

[Kevin Malachowski]

Given the last playground post, I'd guess that the aliased type (i.e. 'int' 
here) is being used for visibility rather than the alias's new name.

It's also a little weird to use embedded types that dont need to be (there's no 
method promotion here because 'int' has no methods), or seeing aliases to 
primitive types. Do you need to do both of those things?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Experience Report building OCR in Go

[Kevin Malachowski]

Not sure about the GUI points: exp/shiny has worked really well for me and has 
existed for at least a year. I do admit that 4 years ago I tried my hand at a 
GUI framework for Go though...

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] New identifiers and selectors in short variable declarations

['Kevin Malachowski' via golang-nuts]

It is not a new declaration, it is definitely an assignment. This can be 
determined because (in Go) a new declaration has effects when closing over 
variables: https://play.golang.org/p/a_IZdOWeqYf

(ignore the obvious race condition; it works the same but looks uglier with 
the requisite locks: https://play.golang.org/p/OXBK5XEg9Yf)

On Tuesday, January 9, 2018 at 2:20:06 PM UTC-8, Ayan George wrote:
>
>
>
> On 01/09/2018 04:45 PM, Ian Lance Taylor wrote: 
> > On Tue, Jan 9, 2018 at 1:02 PM, Jim Bishopp 
> >  wrote: 
> >> 
> >> Has there ever been a discussion about allowing new identifiers and 
> >> selectors in short variable declarations? 
> >> 
> >> var a struct { x int } b, a.x := 1, 2 
> >> 
> >> ERROR: expected identifier on left side of := 
> > 
> > That idea appears in https://golang.org/issue/377, along with many 
> > others. 
> > 
>
> I had the same question myself. I settled on the idea that that is a 
> short declaration -- not an assignment -- though it does re-declare 
> existing variables (of the same type!). That behaves like assignment 
> but I think it is still declaration. 
>
> But its behavior makes sense if you consider that you can't declare or 
> re-declare struct member. 
>
> -ayan 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why are can't struct field types not be used as types

[Kevin Malachowski]

Why not name the inner type? https://play.golang.org/p/8hyMLUVbCp

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: What is the best way to represent functional options within factory methods?

[Kevin Malachowski]

Why do you need all of your factories to have a common parameter?

Also, what problem are you trying to solve? If you're just trying to organize 
your code, to what end are you pursuing this generalization? That is, what 
would you like your final code to look like? (Feel free to use psuedocode to 
get your point across.)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Do you check in vendor packages?

[Kevin Malachowski]

I generally vote for checking in, or at least ensuring that /something/ has an 
in-house copy of all dependencies. The worst thing that can happen is someone 
deleting their repository and having your project being super broken.

(See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Initializing aliased map

[Kevin Malachowski]

Note that the zero value of "aliased" is "nil". If you meant "an empty, newly 
initialized value" then, as previously mentioned, `make(aliased)` will do it 
for you, as would `aliased{}`.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Maximum number of requests per HTTP connection?

[Kevin Malachowski]

Creating an http.RoundTripper which was in charge of delegating to an 
http.Transport as well as swapping out to a new http.Transport when you want to 
swap underlying connections is probably what I'd try first.

Cleaning up the old transport might be a little tricky if your application ever 
leaks http.Response.Body by not closing it appropriately, at which point you 
could also swap out the http.Transport.Dial functions with something which keep 
track of the underlying network connections. That would allow you to 
force-close them after some time 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?

[Kevin Malachowski]

Hit send too early... Your benchmarks do show that something is strange hen
comparing the make (memclr) and copy (memory copy) cases. Out of my element
here :)

On Jun 27, 2017 7:01 PM, "Kevin Malachowski" <ke...@chowski.com> wrote:

> But memclr+copy is slower than just copy, right?
>
> On Jun 27, 2017 6:53 PM, "T L" <tapir@gmail.com> wrote:
>
>>
>>
>> On Tuesday, June 27, 2017 at 8:55:48 PM UTC-4, Kevin Malachowski wrote:
>>>
>>> It's best to compare the assembly, but my guess: 'make' has to zero out
>>> the memory, whereas allocation using append does not.
>>
>>
>> allocation using append will copy each element, which should be slower
>> than memclr.
>>
>> --
>> 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/to
>> pic/golang-nuts/nDYYHKwvYhQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?

[Kevin Malachowski]

But memclr+copy is slower than just copy, right?

On Jun 27, 2017 6:53 PM, "T L" <tapir@gmail.com> wrote:

>
>
> On Tuesday, June 27, 2017 at 8:55:48 PM UTC-4, Kevin Malachowski wrote:
>>
>> It's best to compare the assembly, but my guess: 'make' has to zero out
>> the memory, whereas allocation using append does not.
>
>
> allocation using append will copy each element, which should be slower
> than memclr.
>
> --
> 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/nDYYHKwvYhQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why copy is much slower than append when clone a slice?

[Kevin Malachowski]

It's best to compare the assembly, but my guess: 'make' has to zero out the 
memory, whereas allocation using append does 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Create methods for structs at runtime

[Kevin Malachowski]

Maybe I'm missing something obvious, but why do you need to do this? Seems like 
some sort of remote dependency injection which requires you to serialize code 
from the server to the client. Why not just release a compiled client binary 
which has all of the implementations compiled in already, and have it 
automatically download a new version and start that when you need different 
implementations? Do you need to swap in new implementations at runtime without 
restarting the client process?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] use of builtin print for debug

['Kevin Malachowski' via golang-nuts]

You can declare a func "print" in each package which just calls the real print 
func. When you want to turn off printing, you just have one line to comment out 
in that func to affect all callers.

I'm curious why fmt.Printf doesn't work for you, though. In that case you'd 
still probably want a way to turn off that specific output, but I'm still 
curious.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why were tabs chosen for indentation?

['Kevin Malachowski' via golang-nuts]

I love that Go uses tabs because I use 3 spaces for my tabstop, and very few 
people share that preference.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is there a way to check if all pending finalizers have been executed?

['Kevin Malachowski' via golang-nuts]

In that case it's generally "better" to have an explicit Close on your Go type 
which causes the explicit freeing of C memory. This can be tedious depending on 
your specific code, though.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Duplicate File Checker Performance

['Kevin Malachowski' via golang-nuts]

Sorry, I meant that calling Write on the hash type might be slower if it's 
called more often.

(I'm on mobile right now. When I get back to a keyboard I'll try to come up 
with an example)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Duplicate File Checker Performance

['Kevin Malachowski' via golang-nuts]

It also might be inefficient to call Sum multiple times with smaller slices 
compared to calling it once with a larger slice. Try using io.CopyBuffer and 
passing in larger buffer sizes to see if the CPU and memory usage start to 
converge.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Are receivers from a channel fifo?

['Kevin Malachowski' via golang-nuts]

Try it out :) seems like a simple enough test program to write.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] defer at struct level

['Kevin Malachowski' via golang-nuts]

Do you have a code sample? I don't quite understand what you mean by something 
being "wrapped" in a struct. Will 'a' be a field in a struct? If so, you can 
just access it:

defer myStructValue.a.Close()

-- 
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.
For more options, visit https://groups.google.com/d/optout.