Re: [go-nuts] Re: Algorithm Club

[Will Faught]

On Sat, Apr 1, 2017 at 12:11 AM, Egon Elbre  wrote:

> On Sat, Apr 1, 2017 at 1:42 AM, Will Faught  wrote:
>
>>
>>> For example []GenericElement could be boxed as:
>>>
>>> struct{ itab ptr; ... data []struct{elem ptr} }
>>> or
>>> []struct{itab, elem ptr}
>>>
>>>
>> Can you explain in more detail what's going on there? What's itab? You
>> seem to have pointers represents the slice elements, and that's what I
>> meant by allocating on the heap and passing pointers around. Boxing is just
>> moving values from the stack to the heap, or starting a value in the heap
>> rather than the stack, right?
>>
>
> https://research.swtch.com/interfaces
>
> When you have a slice you could specify the interface table pointer once
> or for each element. One could prevents significant amount of memory at the
> cost of making internals more complicated.
>
> Boxing also involves adding additional type information to distinguish
> between different types of pointers.
>
>

Right, but my point is that currently it's not implemented that way, so it
works the same way, so there would be no performance regression.


>
>>
>>>
>>> https://www.infoq.com/presentations/java-evolution-performance
>>>
>>>
>>
>> Which part of that are you referring to?
>>
>>
> The 10x performance difference in dictionary implementation between C# and
> Java.
>
>
Sure, if you implement it the right way, you can do even better than pure
boxing, but (without having read your source or being familiar with what C#
does under the hood for its reified generics), but do they achieve that
with some tradeoff? Like compile-time or run-time specialization? I'm
talking about not having a tradeoff at all.


>
>
>> My original point was the relative upsides and downsides of boxing
>> generics relative to what Go is now, not boxing generics versus other kinds
>> of generics in an abstract sense. Constraints have already been made on
>> these tradeoffs, for instance fast builds. You seem to be talking about
>> general pros and cons for generics approaches and implementations. It'd be
>> great to start from scratch and ponder all these ideas, but I'm talking
>> about building on what we already have.
>>
>
> Yes.
>
> I think the reason boxing hasn't been implemented is because it doesn't
> improve the current Go language enough. You can already use interfaces as
> such boxes and implement small wrapper around them to make it type-safe...
>
>
Generics does improve the language, though, that's why generics is already
in the language to some degree with the built-in map, slice, array,
channel, etc. types, or the ability to require that both operands for the
==, +, etc. operators are the same type. Those features exhibit the type
safety and expressiveness benefits you get with generics. The Go authors
themselves have implicitly praised the virtues of generics by including it
in a limited form from the outset. An argument against generics is an
argument for slices, maps, channels, etc. only working on interface{}
types. Who wants that?


> Is something missing here?
>>
>
> Accidentally sent the email too early :D
>
> http://research.swtch.com/generic
>
> The reason Go doesn't have generics is because the designers of the
> language try to avoid all the problems listed, at least to some degree.
>
> Sure, you can disagree with this philosophy, which is fine, I completely
> understand. But, that is the route Go Team has chosen. The only way forward
> is to find newer more interesting trade-offs and implementations.
>

Agreed, fair enough, but my point was that, while the Go Team identifies
boxing as having a performance cost, it dosn't acknowledge that this cost
is no different than using interface{}, as you suggested above, which just
boxes the values anyway. If we're already going to be boxing values, we
might as well get some type safety and expressiveness out of the deal.

-- 
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] Redis - Golang >> dial unix /var/run/redis/redis.sock: connect: resource temporarily unavailable

[desaiabhijit]

Please help

Invoking Redis using "gopkg.in/redis.v4" library

Application works fine for single request but it returns "dial unix 
/var/run/redis/redis.sock: connect: resource temporarily unavailable" when 
try to use wrk under load -t50 -c50 -d10s 

trying to get the key using 

value, exp = redisClient.Get(key).Result()

below is use to create a pool

redisClient = redis.NewClient(&redis.Options{
Dialer: func() (net.Conn, error) {
return net.DialTimeout("unix", "/var/run/redis/redis.sock", 1*time.Second)
},
//Addr: "10.10.1.150",
Password: "",
DB: 0,
PoolSize: 99000,
})

Thanks in advance

Rgds,

Abhi

-- 
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] Recommended design pattern for real-time monitoring and control of an observatory

[Sebastien Binet]

James,

On Thu, Apr 6, 2017 at 2:22 AM, James McHugh  wrote:

> I'm writing some software to monitor and control my observatory. It will
> have many many inputs (clouds, rain, temp, time, roof position, telescope
> status, focuser status, camera status, filter status etc etc ) and will
> control the whole setup including opening closing the roof based on weather
> / alt of the Sun, taking images, focusing based on temp changes, auto
> guiding, selecting the best target, shutting the system down if there is
> rain or clouds,  etc etc etc
> It could get quite complex.
>
> I have all the individual pieces working, now I'm looking for a nice
> design pattern to tie it all together.
>
> Any suggestions or ideas to get me started? I'm worried if I start off
> with just a bunch of if statements and for loops it will quickly become a
> huge mess.
>

I don't if what I have is a nice design.
it certainly has grown a bit organically lately because time pressure :)

I wrote a little web server that can send command to motors controling a
piece of equipment (rotating/elevating a testbench system for the LSST
camera).
this is done from the GUI (an authenticated web page, served by the server)
via websockets.
the server relays this to the motors, using some protocol (modbus over TCP).
if any error occurs, the server relays it back again, raising an alert.

the server also has a ticking goroutine that gathers monitoring data from
the motors, video frames from a webcam (pointed at the apparatus).
this data is relayed to the GUI via yet another websocket channel, in the
form of base64-encoded images (for the video frames) and SVG plots (for the
monitoring data).
the ticking goroutine is also saving the monitoring data (at a slower rate
than the "real time" monitoring data) to a database.

it's all there:
 https://github.com/go-lsst/fcs-lpc-motor-ctl

a few slides about it:

http://talks.godoc.org/github.com/sbinet/talks/2016/20160928-ji-go-polymer/talk.slide#10

hth,
-s

-- 
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: Stop HTTP Server with Context cancel

[Pierre Durand]

I did it for a good reason:
If the context is canceled `srv.Shutdown` is called.
Then, `<-errCh` is not called anymore.
This code ensures that there is not leaking goroutine.

Le mercredi 5 avril 2017 07:13:19 UTC+2, Johnny Luo a écrit :
>
> func listenAndServe(ctx context.Context, srv *http.Server, errCh chan<- 
> error) {
>  err := srv.ListenAndServe()
>  select {
>  case errCh <- err:
>  case <-ctx.Done():
>  }
> }
> ListenAndServe is blocking function, so the select will not happen until 
> ListenAndServe return.  and errCh become no use
>
>
> On Wednesday, April 5, 2017 at 4:02:16 AM UTC+10, Pierre Durand wrote:
>>
>> Hello
>>
>> I wrote a small helper to stop an HTTP Server when a Context is canceled.
>> https://play.golang.org/p/Gl8APynVdh
>>
>> What do you think ?
>> Is it OK to use context cancellation for stopping long running functions ?
>>
>

-- 
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: Stop HTTP Server with Context cancel

[Kemal Hadimli]

Isn't the select processing order random? IIRC the only guarantee is 
"default" case is handled as a low priority.

So, something like this maybe?

select {
case errCh <- err:
default:
select {
case <-ctx.Done():
}
}

Again, take this with a grain of salt. I didn't check the spec or code, 
just off the top of my head.


Best,

On Thursday, April 6, 2017 at 11:29:58 AM UTC+3, Pierre Durand wrote:
>
> I did it for a good reason:
> If the context is canceled `srv.Shutdown` is called.
> Then, `<-errCh` is not called anymore.
> This code ensures that there is not leaking goroutine.
>
> Le mercredi 5 avril 2017 07:13:19 UTC+2, Johnny Luo a écrit :
>>
>> func listenAndServe(ctx context.Context, srv *http.Server, errCh chan<- 
>> error) {
>>  err := srv.ListenAndServe()
>>  select {
>>  case errCh <- err:
>>  case <-ctx.Done():
>>  }
>> }
>> ListenAndServe is blocking function, so the select will not happen until 
>> ListenAndServe return.  and errCh become no use
>>
>>
>> On Wednesday, April 5, 2017 at 4:02:16 AM UTC+10, Pierre Durand wrote:
>>>
>>> Hello
>>>
>>> I wrote a small helper to stop an HTTP Server when a Context is canceled.
>>> https://play.golang.org/p/Gl8APynVdh
>>>
>>> What do you think ?
>>> Is it OK to use context cancellation for stopping long running functions 
>>> ?
>>>
>>

-- 
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: Stop HTTP Server with Context cancel

[Pierre Durand]

Yes you're right, the processing order is pseudo random.

But my code also handle another edge case:
If `srv.ListenAndServe()` returns an error BEFORE we reach the code `case 
err := <-errCh:`,
with `default` the error is ignored.

My code ensure that:
- there is no leaking goroutine
- returned error is not ignored

Le jeudi 6 avril 2017 11:04:29 UTC+2, Kemal Hadimli a écrit :
>
> Isn't the select processing order random? IIRC the only guarantee is 
> "default" case is handled as a low priority.
>
> So, something like this maybe?
>
> select {
> case errCh <- err:
> default:
> select {
> case <-ctx.Done():
> }
> }
>
> Again, take this with a grain of salt. I didn't check the spec or code, 
> just off the top of my head.
>
>
> Best,
>
> On Thursday, April 6, 2017 at 11:29:58 AM UTC+3, Pierre Durand wrote:
>>
>> I did it for a good reason:
>> If the context is canceled `srv.Shutdown` is called.
>> Then, `<-errCh` is not called anymore.
>> This code ensures that there is not leaking goroutine.
>>
>> Le mercredi 5 avril 2017 07:13:19 UTC+2, Johnny Luo a écrit :
>>>
>>> func listenAndServe(ctx context.Context, srv *http.Server, errCh chan<- 
>>> error) {
>>>  err := srv.ListenAndServe()
>>>  select {
>>>  case errCh <- err:
>>>  case <-ctx.Done():
>>>  }
>>> }
>>> ListenAndServe is blocking function, so the select will not happen until 
>>> ListenAndServe return.  and errCh become no use
>>>
>>>
>>> On Wednesday, April 5, 2017 at 4:02:16 AM UTC+10, Pierre Durand wrote:

 Hello

 I wrote a small helper to stop an HTTP Server when a Context is 
 canceled.
 https://play.golang.org/p/Gl8APynVdh

 What do you think ?
 Is it OK to use context cancellation for stopping long running 
 functions ?

>>>

-- 
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: Stop HTTP Server with Context cancel

[Konstantin Khomoutov]

On Thu, 6 Apr 2017 02:04:29 -0700 (PDT)
Kemal Hadimli  wrote:

> Isn't the select processing order random? IIRC the only guarantee is 
> "default" case is handled as a low priority.
> 
> So, something like this maybe?
> 
> select {
> case errCh <- err:
> default:
> select {
> case <-ctx.Done():
> }
> }
> 
> Again, take this with a grain of salt. I didn't check the spec or
> code, just off the top of my head.

The default branch proceeds only if none of the case branches is ready
for communication so your reasoning appears to be correct.

-- 
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: Error handling best practices and unit testing complex error values

[Henry]

Use dependency injection and mock the objects to simulate the errors.

In my opinion though, there is no need for an error to hold references to 
its underlying errors. Errors are just values. You take their values, add 
any additional information, and create a new error. You shouldn't need to 
test whether the error contains any specific underlying error. The point of 
'wrapping' error is to prevent access to the underlying errors. I will show 
some examples:

Given you have the following layers: presentation->domain->data. Let's say 
a user attempts to sign in with an invalid username. The data layer checks 
with the database and finds out that there is no such user. So the data 
layer component returns data.ErrMissingUser. Upon receiving the error, the 
domain layer takes the data.ErrMissingUser's error message, adds any 
additional information, and returns a new error domain.ErrInvalidUser to 
the presentation layer. For testing the domain layer component, mock the 
data component and simulate it to return the data.ErrMissingUser. Then in 
your test, check whether the domain component returns domain.ErrInvalidUser.

When dealing with non-predefined errors, let's say there is a database 
error, the data layer returns the error to the domain layer. The domain 
layer takes the error message, adds any additional information, and creates 
a new error. When testing the domain layer, mock the data component and 
have it return an error. Then, in your test, ensure that the domain 
component returns an error. 

Different people may have different approach to this.


On Wednesday, April 5, 2017 at 7:29:24 PM UTC+7, jlb1...@gmail.com wrote:

> Let's say I have an app with three layers: a view (JSON endpoint), 
> service, and persistence layer.
>
>
> Now a `NotFoundError` error occurs at the persistence layer when a record 
> cannot be found. `NotFoundError` is a simple wrapper around a lower level 
> database driver error that I don't want the application to be aware of 
> (since it's an implementation detail).
>
>
> For example, if the `gocql` driver emits an `ErrNotFound` error, the 
> persistence layer will wrap it in a custom error type so that the original 
> error is preserved but not exposed.
>
>
> package database
>
> type NotFoundError struct {
>   originalErr error // persistence layer wraps the driver error
> }
>
>
>
> The service layer then type switches on whatever errors it receives from 
> lower layers. For example in a call to the persistence layer:
>
>
>
> package service
>
> func (s *Service) GetSomething(id string) (string, error) {
>   s, err := database.Get(id)
>   if err != nil {
> return "", handleError(err, “service: failed to get something”)
>   }
> }
>
>
> func handleError(err error, context, message string) error {
>   switch err.(type) {
> case database.NotFoundError:
>   return &ServiceError{
> Code: NotFoundCode,
> Message: message,
> originalErr: errors.Wrap(err, context),
>   }
> default:
>  ...
>   }
> }
>
>
>
> a service error is a custom error type that looks like:
>
>
> type ServiceError struct {
>  originalErr error
>  Codeint `json:"code"`
>  Field string`json:"target,omitempty"`
>  Message string  `json:"message,omitempty"`
>  Details []*ServiceError `json:"details,omitempty"`
> }
>
>
>
>
> To recap, the error propagates through the following layers:
>
>
> driver -> persistence -> service -> view
>
>
> Each layer type switches on the error type it receives from the preceding 
> layer. 
>
> Errors may be recursively nested (the "Details" field is a 
> []*ServiceError) and "originalErr" contains the original error with a stack 
> trace provided by the pkg/errors  library.
>
>
> How would one approach unit testing something like this? 
>
>
> Doing a simple reflect.DeepEqual on the actual and expected error values 
> would be ideal, but the stack trace contained in the actual error means 
> that the expected error will always fail the equality comparison (since 
> DeepEqual also parses unexported fields). In addition, the order of errors 
> in the `Details` slice is also unreliable (for example when validating 
> fields, the order shouldn't matter) which further complicates trying to 
> compare things. I’d have to pollute my tests with loops, manual comparisons 
> and recursive logic which will itself be error-prone.
>
>
> I’ve looked through some popular projects on GitHub and I can’t find any 
> examples of code similar to this this which leads me to believe that all 
> these abstraction hierarchies and complex errors types are horribly 
> unidiomatic Go... I now know why people say Go is more of a systems 
> language. But anyway... is there a better way to deal with errors in an app 
> structured like this? How would you go about comparing these types of error 
> values? How do you handle rich errors types with lots of contextual 
> information in your own web ap

[go-nuts] Parsing base64 data with headers

[Ain]

Hi

I get string which contains:

MIME-Version: 1.0
content-type: text/xml
content-transfer-encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0
...


ie there are some headers and then base64 encoded data. I suspect there 
might be some functions in the std lib which should be able to parse this 
and give me easy access to the headers and data but I just can't find it... 
it isn't mime/multipart, right? Perhaps something in the http client 
package?

TIA
ain

-- 
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] Parsing base64 data with headers

['chris dollin' via golang-nuts]

On 6 April 2017 at 12:00, Ain  wrote:

> ie there are some headers and then base64 encoded data. I suspect there
> might be some functions in the std lib which should be able to parse this
> and give me easy access to the headers and data but I just can't find it...
> it isn't mime/multipart, right? Perhaps something in the http client
> package?

encoding/base64?

Chris

-- 
Chris "allusive" Dollin

-- 
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] Parsing base64 data with headers

[Ain]

neljapäev, 6. aprill 2017 14:07.13 UTC+3 kirjutas ehedgehog:
>
> On 6 April 2017 at 12:00, Ain > wrote: 
>
> > ie there are some headers and then base64 encoded data. I suspect there 
> > might be some functions in the std lib which should be able to parse 
> this 
> > and give me easy access to the headers and data but I just can't find 
> it... 
> > it isn't mime/multipart, right? Perhaps something in the http client 
> > package? 
>
> encoding/base64? 
>

Yes, it could be used to decode the base64 data, but the "message" I have 
has some headers in the beginning (which the encoding/base64 wouldn't 
handle AFAIK). I'm hoping that there is already some func which handles 
parsing such a message as is.


ain

 

>
> Chris 
>
> -- 
> Chris "allusive" Dollin 
>

-- 
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] Parsing base64 data with headers

[Konstantin Khomoutov]

On Thu, 6 Apr 2017 04:00:20 -0700 (PDT)
Ain  wrote:

> I get string which contains:
> 
> MIME-Version: 1.0
> content-type: text/xml
> content-transfer-encoding: base64
> 
> PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0
> ...
> 
> 
> ie there are some headers and then base64 encoded data. I suspect
> there might be some functions in the std lib which should be able to
> parse this and give me easy access to the headers and data but I just
> can't find it... it isn't mime/multipart, right? Perhaps something
> in the http client package?

Almost.

What you're dealing with is a typical set of headers of a so-called
"MIME-formatted" e-mail message followed by its body.  The usual set of
headers is missing (those 'From', 'To' etc) and that's why it looks
strange.

So you parse it like a regular mail message using the net/mail package
and then base64-decode its body.

The program (playground link is [1])

8<
package main

import (
"bytes"
"encoding/base64"
"fmt"
"io"
"net/mail"
"strings"
)

const s = `MIME-Version: 1.0
content-type: text/xml
content-transfer-encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0
`

func main() {
sr := strings.NewReader(s)

msg, err := mail.ReadMessage(sr)
if err != nil {
panic(err)
}

fmt.Printf("%#v\n", msg.Header)

var buf bytes.Buffer
dec := base64.NewDecoder(base64.StdEncoding, msg.Body)
_, err = io.Copy(&buf, dec)
if err != nil {
panic(err)
}

fmt.Println(buf.String())
}
8<

outputs:

| mail.Header{"Content-Type":[]string{"text/xml"}, 
"Content-Transfer-Encoding":[]string{"base64"}, "Mime-Version": []string{"1.0"}}
| 
| https://play.golang.org/p/lOKAAfQRs8

-- 
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: Parsing base64 data with headers

[djadala]

https://golang.org/pkg/mime/multipart/  ?

On Thursday, April 6, 2017 at 2:00:21 PM UTC+3, Ain wrote:
>
> Hi
>
> I get string which contains:
>
> MIME-Version: 1.0
> content-type: text/xml
> content-transfer-encoding: base64
>
>
> PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0
> ...
>
>
> ie there are some headers and then base64 encoded data. I suspect there 
> might be some functions in the std lib which should be able to parse this 
> and give me easy access to the headers and data but I just can't find it... 
> it isn't mime/multipart, right? Perhaps something in the http client 
> package?
>
> TIA
> ain
>

-- 
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] Parsing base64 data with headers

[Ain]

neljapäev, 6. aprill 2017 14:51.13 UTC+3 kirjutas Konstantin Khomoutov:
>
> On Thu, 6 Apr 2017 04:00:20 -0700 (PDT) 
> Ain > wrote: 
>
> > 
> > ie there are some headers and then base64 encoded data. I suspect 
> > there might be some functions in the std lib which should be able to 
> > parse this and give me easy access to the headers and data but I just 
> > can't find it... it isn't mime/multipart, right? Perhaps something 
> > in the http client package? 
>
> Almost. 
>
> What you're dealing with is a typical set of headers of a so-called 
> "MIME-formatted" e-mail message followed by its body.  The usual set of 
> headers is missing (those 'From', 'To' etc) and that's why it looks 
> strange. 
>
> So you parse it like a regular mail message using the net/mail package 
> and then base64-decode its body. 
>
> The program (playground link is [1]) 
>


Thank you, that's exactly what I was looking for!


ain

-- 
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] Parsing base64 data with headers

[Konstantin Khomoutov]

On Thu, 6 Apr 2017 14:50:43 +0300
Konstantin Khomoutov  wrote:

> > I get string which contains:
[...]
> What you're dealing with is a typical set of headers of a so-called
> "MIME-formatted" e-mail message followed by its body.  The usual set
> of headers is missing (those 'From', 'To' etc) and that's why it looks
> strange.
> 
> So you parse it like a regular mail message using the net/mail package
> and then base64-decode its body.
[...]
> As shown, you can (should?) inspect the parsed headers to know which
> content type the decoded document really is (say, if in the future
> your source would sent Content-Type: text/json you'll be better
> prepared for this).
[...]

Also note that depending on your source it might indeed be possible to
get data with the value of the "Content-Type" header set to one
of "multipart" types [2] in which case the message's body will be text
delimited into a set of parts each of which will have its own set of
headers, including the Content-Type header.  Dealing with such payloads
is what mime/multipart is for.

I don't know your situation but I'd assert the headers you parse have
expected values (i.e. content type is "text/xml" or "application/xml"
etc, and the content transfer encoding is indeed base64).

2. https://en.wikipedia.org/wiki/MIME#Content-Type

-- 
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: Algorithm Club

[Jesper Louis Andersen]

On Fri, Mar 31, 2017 at 6:19 PM Michael Jones 
wrote:

> There is part of the topic that has always been slightly beyond my grasp.
> (Maybe I do understand...but just lack absolute certainty.) Maybe others
> know the answer...
>
> In a template system (which is what I prefer but that's not the point of
> this email) we have the notion of the TYPE(s) being a formal argument. We
> presume that the code will compile or fail based on the suitability of the
> instantiated type. That is, a templated Min would fail on the comparison
> "<" if the TYPE was "Map[something]something." Call that a lexical fail.
>
>
You can implement a parameterized type as a universal. This means you can
take a type, T, as a parameter, but you are specifically not allowed to do
anything to T other than to pass it around. In particular, you are not
allowed to call any method on T.

The notion is useful in a lot of situations. A container of type Map
can parameterize over V. That is, you can have the type 'forall V .
Map' for concrete types K (which is 'int' in this instance).
Another example is a function like ' length : forall A . []A -> int' which
can count the "size" of a slice for any slice type.

Once you require additional functions, you must supply what amounts to a
signature. That is, you must make sure that whenever you introduce your
type parameter T, you also introduce a function, 'less' over that parameter
T. Different langauges use different notions, but OCaml uses this one:

module type ORD =
  sig
type t
val less : t -> t -> bool
  end

We can then implement different modules which "ascribe" to the above module
type and "plug them in", specializing our implementation. C++ uses a
slightly different notation, but you can achieve the same. Haskell uses a
concept called Type Classes, Scala uses Traits and Swift probably uses
Protocols. Different notions which lets you acheive what you want.

But all of these notions does not verify any property of your 'less'
function. We should obviously require that our 'less' function is total,
which amounts to checking the following 4 properties:

less_refl: forall X . less X X
less_anti : forall X Y . less X Y && less Y X => X = Y
less_trans : forall X Y Z . less X Y && less Y Z => less X Z
less_comp : forall X Y . less X Y || less Y X

Some programming languages and proof assistants allows you to require such
rules be true for a parameterized type. You are simply, as a programmer,
tasked with providing evidence for the truth of the above 4 rules. It does
slow down the programmer however, often by a factor of 30 or more.

A slightly simpler solution, which I often use, is to write down the above
rules as QuickCheck properties and then verify them by trying out random
inputs from a generator. For instance by writing:

-module(less_total).

less(X, Y) -> X < Y.

prop_less_trans() ->
?FORALL({X, Y, Z}, {real(), real(), real()},
?IMPLIES(less(X, Y) andalso less(Y, Z),
 less(X, Z))).

And then running 'eqc:module({testing_time, 30}, less_total)' which gives
as many random test cases as possible in a 30 second time frame (usually in
the millions). If the 'real()' generator periodically generates infs and
nans (it should!) then we can eventually find the problem you mention.

In my experience, it is currently feasible to require randomized test cases
for your production code, if the code requires high amounts of correctness.
Some algorithms, PAXOS-variants I'm looking at you, are almost impossible
to get right unless you approach them semi-formally. But requiring such
rigor of every piece of code is futile. Not all code requires production
quality, and much code is experimental for other reasons. Also, it would
severely limit the amount of programmers who could write code---and I think
we need more programmers, not less.

The key insight is that you are plugging in your T and your Less under the
assumption they work. That is, you are looking at your T and Less as being
part of your axioms in the system. You can then write your sorter under
those axioms. The reason you want to decouple the notion of T and Less from
the rest of the code is manyfold:

* efficiency: you can plug in a better implementation later
* flexibility: you can plug in another implementation later
* correctness: your proof is not required to "dig into" the details of the
T and Less implementation.

So in practice, we are just programming under assumptions about the
underlying correctness properties. And because we are rather bad as
computer scientists, we don't require the necessary rigor of the parts we
are using. Mathematicians are in the same boat, but at least they tend to
build upon things which has been proven correct, so they are vastly better
off.

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

[go-nuts] Re: Recommended design pattern for real-time monitoring and control of an observatory

[Ron Evans]

Allow me to humbly suggest you checkout Gobot https://gobot.io which is 
intended for this category of application.

Disclosure: I am a maintainer of Gobot :)

Sincerely,
Ron

On Thursday, April 6, 2017 at 2:22:15 AM UTC+2, James McHugh wrote:
>
> I'm writing some software to monitor and control my observatory. It will 
> have many many inputs (clouds, rain, temp, time, roof position, telescope 
> status, focuser status, camera status, filter status etc etc ) and will 
> control the whole setup including opening closing the roof based on weather 
> / alt of the Sun, taking images, focusing based on temp changes, auto 
> guiding, selecting the best target, shutting the system down if there is 
> rain or clouds,  etc etc etc 
> It could get quite complex.
>
> I have all the individual pieces working, now I'm looking for a nice 
> design pattern to tie it all together.
>
> Any suggestions or ideas to get me started? I'm worried if I start off 
> with just a bunch of if statements and for loops it will quickly become a 
> huge mess.
>
> Regards
>
> James
>

-- 
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] Mapping restricted types to Go

[aconway]

I've been reading around on this and I'd like a sanity check on the 
solution I'm thinking about before I bake it into a public API.

The problem: I'm providing a 2 way mapping from Go to another type system 
(https://godoc.org/qpid.apache.org/amqp for the curious). The specific 
problem: AMQP allows maps with mixed type key/value (no problem there - 
map[interface{}]interface{}) but some maps have "restricted type" rules, 
such as "the key may only be of AMQP type ulong or symbol" - in Go that 
means uint64 or 'type Symbol string' since AMQP symbol and string are 
encoded differently.

So how to represent this in a way that is:
- efficient
- Go-like: use type switch/type assertion as normal
- type safe: I could just use map[interface{}] but then illegal key types 
wouldn't be caught till runtime

Here's my solution - I have seen the tag technique used e.g. in the go 
parser, but I haven't seen it in a public API, so wonder if there are any 
gotchas or better ideas. Overall I'm pretty happy with it, the need for an 
extra type and conversions for uint64 isn't ideal but it's not too bad. 
Code below is a simple executable, obvoiusly the real think will be in 
package amqp (or maybe package amqp.restrict, there are other type 
restrictions to deal with and I'd like to keep dummy types like Uin64 out 
of the general population...)

package main

// Public interface

type Symbol string
type Uint64 uint64

// An AnnotationKey can be either a Uint64 or a Symbol.
//
// NOTE: Uint64 is equivalent to the built-in type uint64, but is distinct 
so
// the compiler can detect illegal types being used with AnnotationKey
// See the example for more
type AnnotationKey interface {
allowedAsAnnotationKey() // A marker method so the compiler can 
restrict to legal types, does nothing.
}

func (Uint64) allowedAsAnnotationKey() {}
func (Symbol) allowedAsAnnotationKey() {}

func main() {
var k AnnotationKey
k = AnnotationKey(Symbol("foo"))
var s Symbol
s = k.(Symbol)
println(s)

// Note conversions needed between built-in uint64 and Uint64
var n uint64 // Built-in uint64 type
n = 42
k = AnnotationKey(Uint64(n)) // Convert to Uint64 to use with 
AnnotationKey
n = uint64(k.(Uint64))   // Convert back to built-in uint64
println(n)

/*
// The following will not compile without explicit conversion:
k = AnnotationKey(n) // Cannot convert: use k = 
AnnotationKey(Uint64(n))
n = k.(Uint64)   // Cannot assign: use n = uint64(k.(uint64)

// The following types are not allowed for AnnotationKey
k = AnnotationKey("foo") // Cannot convert: string is not allowed 
for AnnotationKey
k = AnnotationKey(true)  // Cannot convert: bool is not allowed for 
AnnotationKey
*/
}



-- 
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] Number of OS threads used by Go runtime

[yuri . shakhmatov]

Hi all!

Is there any way to count number of OS threads used by Go runtime 
programmatically (ie without using bash with top/ps and others)? 

--
Best regards, Yuri

-- 
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: Recommended design pattern for real-time monitoring and control of an observatory

[jack]

James,

Let me suggest the TICK Stack  (Written in Go) and 
Grafana . Its pretty get setup and has much of what 
you want out of the box. Here is a blog post 

 
describing the setup. I'm also working on a webinar describing how to do 
this.

Jack

On Wednesday, April 5, 2017 at 5:22:15 PM UTC-7, James McHugh wrote:
>
> I'm writing some software to monitor and control my observatory. It will 
> have many many inputs (clouds, rain, temp, time, roof position, telescope 
> status, focuser status, camera status, filter status etc etc ) and will 
> control the whole setup including opening closing the roof based on weather 
> / alt of the Sun, taking images, focusing based on temp changes, auto 
> guiding, selecting the best target, shutting the system down if there is 
> rain or clouds,  etc etc etc 
> It could get quite complex.
>
> I have all the individual pieces working, now I'm looking for a nice 
> design pattern to tie it all together.
>
> Any suggestions or ideas to get me started? I'm worried if I start off 
> with just a bunch of if statements and for loops it will quickly become a 
> huge mess.
>
> Regards
>
> James
>

-- 
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] gomock - why do recorder methods use interface{}?

[Jonathan Yu]

Thanks so much for your answer, Julian, that makes total sense! I guess the
examples I've seen so far are missing these more "advanced" use cases :)

Appreciate the quick and informative reply.

On Wed, Apr 5, 2017 at 4:13 PM, Julian Phillips 
wrote:

> On 05/04/2017 18:06, Jonathan Yu wrote:
>
>> Hi everyone,
>>
>> I've been using gomock to generate mock objects (in source mode), and it's
>> been pretty great - way better than maintaining similar code on my own.
>> One
>> thing that I find curious, though, is that expectations are recorded using
>> a generic interface{} type, rather than the original type.
>>
>> For example, in the sample mock_user.go
>> > >
>> file, we have:
>>
>> func (_m *MockIndex) Anon(_param0 string) {
>> _m.ctrl.Call(_m, "Anon", _param0)
>> }
>>
>> func (_mr *_MockIndexRecorder) Anon(arg0 interface{}) *gomock.Call {
>> return _mr.mock.ctrl.RecordCall(_mr.mock, "Anon", arg0)
>> }
>>
>> Does anyone know why the Recorder interface is generated with interface{}?
>> Doesn't this mean that we lose type safety when defining expectations?
>> After all, you can do: mock.EXPECT().Anon(123) even though the method must
>> be called with a string parameter, right?
>>
>
> Because you _don't_ have to use a value of the appropriate type when
> setting up the expectations, e.g.:
>
> "mock.EXPECT().Anon(gmock.Any())" or "mock.EXPECT().Anon(gomock.Not
> ("invalid"))"
>
> in fact "mock.EXPECT().Anon("123")" is actually a shortcut for
> "mock.EXPECT.Anon(gomock.Eq("123"))"
>
> (see https://godoc.org/github.com/golang/mock/gomock#Matcher)
>
> HTH,
>
> --
> Julian
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

-- 
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] [blog post] go tool trace: Golang's hidden trace visualiser

[Will Sewell]

Hi, I've just written a blog post/tutorial on Go's relatively unknown, but 
incredibly useful, trace visualiser: `go tool trace`. The post provides a 
tour of the interface, and examples of the kind of problems it can aid in 
tracking down.

I was originally made aware of it by Rhys Hiltner in my previous message to 
this mailing list when I was investigating long GC pause 
times: https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. 
So thanks for pointing it out Rhys! As he mentions in that thread, it is 
currently not well documented, so I felt it was a good opportunity for a 
blog post after playing around with it for a bit.

In the future I'd like to investigate and write about how the runtime event 
system itself actually works because it seems like an interesting area.

Let me know if you have any feedback.

Thanks,
Will

-- 
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: [blog post] go tool trace: Golang's hidden trace visualiser

[Will Sewell]

Apologies. I just realised I didn't actually link to the post! It's here: 
https://making.pusher.com/go-tool-trace/.

On Thursday, 6 April 2017 17:29:22 UTC+1, Will Sewell wrote:
>
> Hi, I've just written a blog post/tutorial on Go's relatively unknown, but 
> incredibly useful, trace visualiser: `go tool trace`. The post provides a 
> tour of the interface, and examples of the kind of problems it can aid in 
> tracking down.
>
> I was originally made aware of it by Rhys Hiltner in my previous message 
> to this mailing list when I was investigating long GC pause times: 
> https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. So 
> thanks for pointing it out Rhys! As he mentions in that thread, it is 
> currently not well documented, so I felt it was a good opportunity for a 
> blog post after playing around with it for a bit.
>
> In the future I'd like to investigate and write about how the runtime 
> event system itself actually works because it seems like an interesting 
> area.
>
> Let me know if you have any feedback.
>
> Thanks,
> Will
>

-- 
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: Algorithm Club

[Michael Jones]

Thank you for this thoughtful response. It helpful and inspires new
thoughts.

When I was a boy learning C (1976 or 1977, UNIX 6th Edition at Bell Labs
via "learn") the definition of qsort() was a new idea for me. The exposure
of base and stride so nakedly (after BASIC and FORTRAN and LISP and SAIL
and ALGOL60 which hid them behind a name) was new and the role of the
comparison function was a surprise in terms of API and the approach of
passing in the brain as an argument.

At first I did not like it, because it seemed that so many function calls
would be expensive and I was sensitized to that. (having used a PDP-8
taught lessons about expensive.) I always was a little iffy about qsort
because of this and from time to time would write a custom sort in my
programs where the difference made a difference. On the other hand, qsort()
always worked and was admirably flexible--serving myself and millions of
others now for more than half a century.

I've always looked closely at how people thought about reusable sort
utilities and efficiency. On IBM mainframes there was a 3rd party sort
utility that generated machine code for your comparison function two human
generations before JIT. In SmallTalk it was like qsort since everything had
compare methods. This was the "old" way. The newer way is different, having
a less() method and using it twice to decide about greater() and equal().
That works too...except when it doesn't...as in the case of quiet and
signalling NaNs in IEEE floating point. It might be faster too, since "<"
is less decisions than "<" or "=" or ">" and the sort code may be in a
tight loop of while less() or while greater() and thereby be faster than
the old way.

The qsort() whole-brain as argument works in all cases because the
developer knows how to make the subtle decisions. The newer partial-brain
method works in those (vast majority) of cases where the implied
rest-of-brain is semantically correct. The downside is that the developer
may not realize when this is introducing bugs. (Just as in the qsort() case
they might not realize the bug there if they don't handle NaNs properly.)

One certain way is to have mathematical statements about meaning, as you
list above. Another point of view is to acknowledge floating point as a
special thing--not numbers at all--different from integral types because of
reserved values with magic meanings when compared, and deal with that
specially.

All interesting. Thank you!
Michael

-- 
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: [blog post] go tool trace: Golang's hidden trace visualiser

[Rob Pike]

That's a great blog post, Will. Thanks for that. The Go team should have
provided one for you, I must say, so double thanks.

-rob


On Thu, Apr 6, 2017 at 10:00 AM, Will Sewell  wrote:

> Apologies. I just realised I didn't actually link to the post! It's here:
> https://making.pusher.com/go-tool-trace/.
>
>
> On Thursday, 6 April 2017 17:29:22 UTC+1, Will Sewell wrote:
>>
>> Hi, I've just written a blog post/tutorial on Go's relatively unknown,
>> but incredibly useful, trace visualiser: `go tool trace`. The post provides
>> a tour of the interface, and examples of the kind of problems it can aid in
>> tracking down.
>>
>> I was originally made aware of it by Rhys Hiltner in my previous message
>> to this mailing list when I was investigating long GC pause times:
>> https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. So
>> thanks for pointing it out Rhys! As he mentions in that thread, it is
>> currently not well documented, so I felt it was a good opportunity for a
>> blog post after playing around with it for a bit.
>>
>> In the future I'd like to investigate and write about how the runtime
>> event system itself actually works because it seems like an interesting
>> area.
>>
>> Let me know if you have any feedback.
>>
>> Thanks,
>> Will
>>
> --
> 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.
>

-- 
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] What is time.Nanosecond ?

[mpboom2003]

Thank you! I get it now.

-- 
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] Number of OS threads used by Go runtime

[Ian Lance Taylor]

On Thu, Apr 6, 2017 at 3:07 AM,   wrote:
>
> Is there any way to count number of OS threads used by Go runtime
> programmatically (ie without using bash with top/ps and others)?

Not at present.

Perhaps it could be added to the SchedStats proposal
(https://golang.org/issue/15490).

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

[go-nuts] Re: Number of OS threads used by Go runtime

[Uli Kunitz]

I suggest to give n, _ := runtime.ThreadCreateProfile(nil) a try. 

On Thursday, April 6, 2017 at 5:37:55 PM UTC+2, Юрий Шахматов wrote:
>
> Hi all!
>
> Is there any way to count number of OS threads used by Go runtime 
> programmatically (ie without using bash with top/ps and others)? 
>
> --
> Best regards, Yuri
>

-- 
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: Number of OS threads used by Go runtime

[Ian Lance Taylor]

On Thu, Apr 6, 2017 at 11:18 AM, Uli Kunitz  wrote:
> I suggest to give n, _ := runtime.ThreadCreateProfile(nil) a try.

Good point, yes, that should work.

Ian

> On Thursday, April 6, 2017 at 5:37:55 PM UTC+2, Юрий Шахматов wrote:
>>
>> Hi all!
>>
>> Is there any way to count number of OS threads used by Go runtime
>> programmatically (ie without using bash with top/ps and others)?
>>
>> --
>> Best regards, Yuri
>
> --
> 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.

-- 
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] Testing code within channel dispatchers/workers

[Tim Jones]

Is there a common pattern for writing tests for workers? I have code that 
is something like this:

type struct Dispatcher{
work chan interface{}
moreWork chan interface{}
// some other state info stored here
}

func (d *Dispatcher) Run {
for {
select {
case w := <-work:
// Code block 1
//some code
//goes here
case m := <-moreWork:
// Code block 2
//other code
//goes here
// potentially more cases   
}
} 
}

What's the best way to go about testing it? Integration tests that just 
send data through the channels and wait for the right behaviour feel 
clumsy. I can test the code blocks in isolation if I pull them out:

func (d *Dispatcher) codeBlockOne(w interface{}) {
// Code block 1
//some code
//goes here
}

func (d *Dispatcher) codeBlockTwo(m interface{}) {
// Code block 2
//other code
//goes here
}


func (d *Dispatcher) Run {
for {
select {
case w := <-work:
d.codeBlockOne(w)
case m := <-moreWork:
d.codeBlockTwo(w)
}
} 
}

But that has the side effect that it potentially exposes the code blocks to 
other code in the package (I don't want to accidentally call them without 
the channel). Is there a cleaner way?

I'm also not sure how I test that the Run() function is dispatching to the 
right code blocks. I considered injecting an object into Run that has the 
codeBlockOne and codeBlockTwo methods on it, but now I'm doing a lot of 
refactoring away from what feels like the normal way to write this code.

What's the common way that this is tested?

Tim

-- 
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] Thread local error information when wrapping lib with cgo

[Ian Lance Taylor]

On Wed, Apr 5, 2017 at 10:32 PM, distributed  wrote:
>
> Thanks for the clarification. I suppose internal UnlockOSThread does not
> override the runtime.LockOSThread by my code from the outside?

Correct.

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

Re: [go-nuts] Bots on the mailing list

[Ian Lance Taylor]

On Mon, Apr 3, 2017 at 6:21 PM, Andrew Gerrand  wrote:
>
> As an experiment, I have banned those users from the group.
> They can mail us if they have questions about it, at which point we can ask
> them what the deal is with the forwarding.
> I doubt we will hear from them.
>
> If anyone sees other addresses doing this, let me know.

It hasn't helped.  I'm still getting e-mail messages.

I may be missing something but I don't see how it could have helped.
Those users aren't on the list.  And the e-mail messages aren't being
sent back to the list.  They're being sent directly to people who send
e-mail to the list.  Anybody could be doing this simply by scraping
messages from the groups interface.

Why anybody would do this, I don't know.  The messages have some
garbage characters at the bottom.  Perhaps this is a modern equivalent
of a numbers radio station: anyone in the know can get one of these
replies just by sending an e-mail to the group, and since so many are
sent out even tracing IP connections would not reveal who the intended
recipient is.

Ian

> On 3 March 2017 at 07:56, Ian Lance Taylor  wrote:
>>
>> On Thu, Mar 2, 2017 at 12:32 PM, Nyah Check  wrote:
>> >
>> > Has anyone noticed there might be some bots subscribed to this mailing
>> > list
>> > that constantly forward discussions to our emails? I've noticed this
>> > about 3
>> > times already. I don't know if there's something the Group admins can do
>> > something about.  Here are some of the emails I've found.
>> > 1.) mott.barb...@yahoo.com
>> > 2.) erminiak...@yahoo.com
>> > 3.) thomas_ch...@yahoo.com
>> > 4.) ryan_conk...@yahoo.com
>> >
>> > Apparently they're all "yahoo" email addresses.
>>
>> I have noticed this too.  i got at least two today.  I'm a group
>> admin, but I can't think of anything to do.  The fact that the e-mails
>> are sent from @yahoo.com doesn't imply that they are being triggered
>> by e-mail sent to @yahoo.com, and even if it did we wouldn't know
>> which specific @yahoo.com address is causing the problem.  And the
>> e-mails being sent out are not going through the group, so there isn't
>> anything we can do about them.
>>
>> I'm open to suggestions.
>>
>> 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.
>> 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] Testing code within channel dispatchers/workers

[Tamás Gulácsi]

If you really want to test that you write that handful of selects correctly, 
add the worker blocks as arguments to Run:
Run(map[string]func(interface{}))

But this way you introdeced another level of indirection, which should be  
tested. 

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