Re: [go-nuts] golang poll/epoll/select

[graham4king]

If you have a specific case that isn't covered by blocking in a go-routine, 
you can always use the syscall's directly, with a very similar API to what 
you would do in C. 

For example here's the epoll ones in stdlib: 
https://golang.org/pkg/syscall/#EpollCreate

New syscall wrappers are in the x/sys repo: 
https://godoc.org/golang.org/x/sys/unix

On Thursday, 22 September 2011 07:04:03 UTC-7, vase wrote:
>
>
>
> 2011/9/22 André Moraes 
>
>> In most cases you should not need to poll explicity.
>> Write a goroutine that blocks while reading the contents of your fd
>> (file, network, etc...), and then send the data read across a channel.
>>
>> Under the hood Go will take care of the poll for you.
>>
>> But if you really need to poll explicitly, I can't help you since I
>> never had to do that.
>>
>
> Hm... Can somebody from golang team tell me, what is the best way to 
> provide this (example written in C):
> xs_watch() // create a hook, that watch to specific path to cheange
> epoll_wait() //wait to event on fd that returned by watch
> xs_read_watch() //read watched data that appeared
> xs_unwatch() //delete watch and stops recive notify
>
> As i see, i need to create goroutine in xs_watch(worker), that runs worker 
> function with read, then some data appeared, goroutine read and do some 
> stuff, xs_unwatch destroy groutine and stops watching... Right? 
>
>
>
> -- 
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.to...@selfip.ru 
> jabber: va...@selfip.ru 
>
>

-- 
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] Interface{} constrains on specific types

['Thomas Bushnell, BSG' via golang-nuts]

The trick is to do this:

Decl special_interface

and then special_interface requires an unexported interface which you
implement in the specific (new) types that you can store in the thing.

On Fri, Jun 24, 2016 at 3:10 PM 'Mihai B' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>  I'm developing a json schema generator (json schema from Go ast and the
> other way around). There is a keyword "oneOf" which requires  exactly one
> schema to be valid in this keyword's value. In Go I translate it by using
> an empty interface{}. The issue is that when I convert the interface{} to
> json schema I can only say that the object can be of any type even if I
> know that it can hold only a small subset.
>  Therefore I'm wondering if placing some constrains on the types that
> could be implemented by the interface would be a good idea. For example
> instead of `type interface{}` which implements any type we could define the
> types it can implement (e.g.  type  X interface{T1, T2, T3} ). This way we
> don't have a totally black box so it improves the documentation/semantics
> and we avoid specific bugs using static analysis. Currently the practice
> seems to be documenting the types in pure comments[0] which cannot be
> analysed statically. Another option that I'm considering now is to use the
> empty interface but with specific tags [1] and use an external tool. This
> might have been proposed before but I can't find it on the mailing list.
> What do you think?
>
> [0]  https://golang.org/pkg/go/ast/#Object
> [1]
>
> type Object struct {
> Name string   // declared 
> name
> Decl interface{} 
> `interface:"Field,FuncDecl,LabeledStmt,external.Scope" //
>
> }
>
> --
> 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] Interface{} constrains on specific types

['Mihai B' via golang-nuts]

 I'm developing a json schema generator (json schema from Go ast and the 
other way around). There is a keyword "oneOf" which requires  exactly one 
schema to be valid in this keyword's value. In Go I translate it by using 
an empty interface{}. The issue is that when I convert the interface{} to 
json schema I can only say that the object can be of any type even if I 
know that it can hold only a small subset.
 Therefore I'm wondering if placing some constrains on the types that could 
be implemented by the interface would be a good idea. For example instead 
of `type interface{}` which implements any type we could define the types 
it can implement (e.g.  type  X interface{T1, T2, T3} ). This way we don't 
have a totally black box so it improves the documentation/semantics and we 
avoid specific bugs using static analysis. Currently the practice seems to 
be documenting the types in pure comments[0] which cannot be analysed 
statically. Another option that I'm considering now is to use the empty 
interface but with specific tags [1] and use an external tool. This might 
have been proposed before but I can't find it on the mailing list. What do 
you think?

[0]  https://golang.org/pkg/go/ast/#Object 
[1]  

type Object struct {
Name string   // declared 
name
Decl interface{} `interface:"Field,FuncDecl,LabeledStmt,external.Scope" 
//
   
}

-- 
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] How to be safe in Go?

[Justin Israel]

On Sat, 25 Jun 2016, 6:27 AM Nick Pavlica  wrote:

>
>
> On Thursday, June 23, 2016 at 6:44:22 PM UTC-6, Caleb Spare wrote:
>>
>> > To see if the the
>> > race detector would find this potential bug for me, I ran the code with
>> the
>> > mutex(s) commented out with the  -race flag on and didn't get a
>> warning.
>>
>> Did you make some concurrent requests? The race detector only tells
>> you about races that happen, so you need to excercise the concurrent
>> code paths in some way (possibly in a test or by selectively turning
>> on -race in a production-like environment).
>>
>
>   I just accessed the endpoint from multiple browsers, but no formal tests.
>
>
>>
>> A couple of general thoughts:
>>
>> (1) The primary way to know whether a library you're using will call
>> your code concurrently from multiple goroutines is via documentation.
>> The net/http documentation, for instance, explains that Serve creates
>> a goroutine for each connection. Any other library you use should
>> clearly explain this if it's the case.
>>
>
>   That makes sense, but seems to be a little fragile.  For example, if the
> lib wasn't originally concurrent, then is changed, it would be easy to get
> into a bad situation.  It makes me want to just wrap every variable in a
> Mutex to be safe.  I'm guessing that the pattern is to keep Go programs as
> small as possible so you can track all the corner cases effectively in your
> own mental model.
>

I feel like it shouldn't necessarily matter if the lib will call your
handlers concurrently or not. The focus should be on the fact that you are
wanting to share global state within the body of that function. Shouldn't
the answer be that you should avoid mutating global state without proper
synchronization? I don't feel like you should need to run a tool to find
out if it is calling your code concurrently. Rather just use best practices
to write safer code in the first place.


>
>> (2) net/http and other server packages are a slightly unusual case --
>> there are many libraries that exist, but most don't call your code
>> concurrently. (Even packages that invoke provided callbacks are
>> themselves a minority.) If I use a package that, say, interfaces with
>> a database or implements a graph algorithm, it would be quite strange
>> if it used concurrently-invoked callbacks.
>>
>
> As I ponder this; I wounder if some tooling could be added to the compiler
> or an outside utility that would scan all the used libraries, and notify
> you that the libraries/functions are concurrent.
>
> For example:
>
> 
> go run --chk_concurrent  mylib.go
>
> Notice: "net/http" calls concurrent operations on the Handle function.
>
> 
>
> Thanks again for the feedback!
> --Nick
>
> --
> 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] How to be safe in Go?

[Nick Pavlica]

On Thursday, June 23, 2016 at 6:44:22 PM UTC-6, Caleb Spare wrote:
>
> > To see if the the 
> > race detector would find this potential bug for me, I ran the code with 
> the 
> > mutex(s) commented out with the  -race flag on and didn't get a warning. 
>
> Did you make some concurrent requests? The race detector only tells 
> you about races that happen, so you need to excercise the concurrent 
> code paths in some way (possibly in a test or by selectively turning 
> on -race in a production-like environment). 
>

  I just accessed the endpoint from multiple browsers, but no formal tests.
 

>
> A couple of general thoughts: 
>
> (1) The primary way to know whether a library you're using will call 
> your code concurrently from multiple goroutines is via documentation. 
> The net/http documentation, for instance, explains that Serve creates 
> a goroutine for each connection. Any other library you use should 
> clearly explain this if it's the case. 
>

  That makes sense, but seems to be a little fragile.  For example, if the 
lib wasn't originally concurrent, then is changed, it would be easy to get 
into a bad situation.  It makes me want to just wrap every variable in a 
Mutex to be safe.  I'm guessing that the pattern is to keep Go programs as 
small as possible so you can track all the corner cases effectively in your 
own mental model. 


> (2) net/http and other server packages are a slightly unusual case -- 
> there are many libraries that exist, but most don't call your code 
> concurrently. (Even packages that invoke provided callbacks are 
> themselves a minority.) If I use a package that, say, interfaces with 
> a database or implements a graph algorithm, it would be quite strange 
> if it used concurrently-invoked callbacks. 
>

As I ponder this; I wounder if some tooling could be added to the compiler 
or an outside utility that would scan all the used libraries, and notify 
you that the libraries/functions are concurrent. 

For example:

go run --chk_concurrent  mylib.go

Notice: "net/http" calls concurrent operations on the Handle function.


Thanks again for the feedback!
--Nick

-- 
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] Custom syscall.Sockaddr

[Ian Lance Taylor]

On Fri, Jun 24, 2016 at 8:05 AM,   wrote:
>
> I am trying to set up an interface from Go to SocketCAN
> (https://www.kernel.org/doc/Documentation/networking/can.txt).  This
> implements the linux socket interface, however it is a completely separate
> socket type from the regular AF_INET or AF_UNIX socket types.
>
> The sockaddr struct for SocketCAN looks like this:
>
> struct sockaddr_can {
> sa_family_t can_family;
> int can_ifindex;
> union {
> /* transport protocol class address info (e.g. ISOTP) */
> struct { canid_t rx_id, tx_id; } tp;
>
> /* reserved for future CAN protocols address information */
> } can_addr;
> };
>
>
> Since the union only has one possible entry right now, this is easy enough
> to write in Go
>
> type CanID uint32
>
> type sockaddrCan struct {
>Family  uint16
>IfIndex int32
>TpRxId  CanID
>TpTxId  CanID
> }
>
>
> Everything is straight forward so far, but now if I want to pass this to
> different syscall functions ( syscall.Bind, syscall.Connect, etc.) I have to
> implement the syscall.Sockaddr interface, however looking in the code I see
> this:
>
> type Sockaddr interface {
> sockaddr() (ptr unsafe.Pointer, len _Socklen, err error) // lowercase;
> only we can define Sockaddrs
> }
>
>
> So, finally the questions:
>
> Why is this interface private? It says that it is, but provides no
> rationale.
> Does this mean that I have to reimplement all the functions syscall
> functions using raw syscall.Syscall?  Or is there some clever way around
> this so I can use the syscall package to make a Sockaddr type that is not
> already defined.

If this is going to be a standard thing in future Linux kernels, I
suggest that you add support for it to the golang.org/x/sys/unix
package.

I don't actually know the answer to why Sockaddr has a private method.
I agree that it doesn't seem strictly necessary.

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] Shuffle Items in a Slice

[dc0d]

Thanks Val for explanation & clarification;

On Friday, June 24, 2016 at 5:24:30 PM UTC+4:30, Val wrote:
>
> The playground caches everything, so running multiple times the same 
> program will just serve the previously generated output.
>
> Also in the playground everything is frozen at some point in the past : 
> the clock, the randomness sources, and you can't make outgoing requests to 
> import randomness from the network.
>
> On Friday, June 24, 2016 at 2:47:13 PM UTC+2, dc0d wrote:
>  
>
>> Better be something wrong with playground! :)
>>
>>

-- 
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: can't get Content-Type and Content-Disposition to force browser to display "file->save..." dialog in the web browser

[David Marceau]

The core problem was:
w.Header().Set("Content-Disposition","attachment;filename=" + 
strOutputFileOfJournalctl)
Should actually be:
w.Header().Add("Content-Disposition","attachment;filename=" + 
strOutputFileOfJournalctl)

I preferred to put the above line before the serveFile.

That's all. Thanks to everyone who dropped by.

On Friday, June 24, 2016 at 9:44:00 AM UTC-4, David Marceau wrote:
>
> Here is what is in my import.  Maybe I should be looking in goji instead 
> of net/http?
>
 

>
> import (
> "fmt"
> "net"
> "time"
> "strconv"
> "strings"
> "os"
> "encoding/json"
> "net/http"
> "crypto/tls"
> "crypto/rand"
> "github.com/gorilla/mux"
> "github.com/goji/httpauth"
> "github.com/zfjagann/golang-ring"
> "github.com/kabukky/httpscerts"
> "reflect"
> "io"
> "io/ioutil"
> "path/filepath"
> "html/template"
> "os/exec"
> )
>
> On Friday, June 24, 2016 at 9:40:29 AM UTC-4, David Marceau wrote:
>>
>> I tried to repeat the same ordering as the iris infrastructure within the 
>> function, but it still behaves not as expected.  It does not show the 
>> file->save... dialog.  It shows the file within the browser as a web page.
>>
>> func blah (w http.ResponseWriter, r *http.Request) {
>> strOutputFileOfJournalctl = "journalctlLog.json"
>> w.Header().Set("Content-Type","application/octet-stream")  //forces 
>> the save as dialog
>>
>> strSomeStringInJsonFormat := "{ Blah: 'blah value' }"
>> myOutput := []byte(strSomeStringInJsonFormat)
>>
>> //ATTEMPT #1
>> //w.Write(myOutput) //displays in web browser page
>> //ATTEMPT #4
>> //w.Header().Set("Content-Disposition","attachment;filename=" + 
>> strOutputFileOfJournalctl)
>>
>>
>>
>> //ATTEMPT #3
>> //w.Header().Add("Content-Length", strconv.Itoa( len(myOutput) ) )
>> //w.Write(myOutput) //displays in web browser page
>> //w.Header().Set("Content-Disposition","attachment;filename=" + 
>> strOutputFileOfJournalctl)
>>
>>
>>
>> //ATTEMPT #2
>> w.Header().Add("Content-Length", strconv.Itoa(len(myOutput)) )
>> tmpFile, _ := ioutil.TempFile(os.TempDir(), "OurGeneratedCustomLog")
>> defer os.Remove(tmpFile.Name())
>> tmpFile.Write(myOutput)
>> tmpFile.Close()
>> http.ServeFile(w, r, tmpFile.Name())
>> //ATTEMPT #5
>> w.Header().Set("Content-Disposition","attachment;filename=" + "\"" + 
>> strOutputFileOfJournalctl + "\"")
>> }
>>
>>
>> On Friday, June 24, 2016 at 7:06:59 AM UTC-4, David Marceau wrote:
>>>
>>> Again, I want to clarify the file does arrive in the browser, but I want 
>>> to ensure the "file->save..." dialog appears in the web browser when it 
>>> arrives.  I found some older code I wrote a couple of years ago that was 
>>> behaving as expected:
>>> w.Header().Set("Content-Type", "application/octet-stream")
>>> w.Header().Set("Content-Disposition", "attachment; filename=" + 
>>> myBasePdf + ".pdf")
>>> http.ServeFile(w, req, myGenPdfFileName)
>>>
>>>
>>> I acknowledge when I wrote this email I made a typo, but in my code I do 
>>> have the Itoa correctly.
>>> w.Header().Set("Content-Length", strconv.Itoa( len(myCmdOutput) ) )
>>> I never used that content-length field because I read somewhere that I 
>>> shouldn't.
>>>
>>> Last night I took a look at iris to see how they do it and found:
>>> https://github.com/kataras/iris/blob/master/context.go#L583
>>> err := ctx.ServeFile(filename, false) 
>>> if err != nil { 
>>> return err 
>>> } 
>>>
>>> ctx.RequestCtx.Response.Header.Set(contentDisposition, "
>>> attachment;filename="+destinationName)
>>>
>>> I am scratching my head since the header set content-disposition is 
>>> happening after the ServeFile which is different from what all the docs and 
>>> what I am used to seeing.  It seems calling these functions are 
>>> order-independant.  When does the connection actually send the file over 
>>> the connection?
>>>
>>> I believe the Iris send file also provides what I want as expected 
>>> behaviour, but I haven't tried it yet.  
>>>
>>> On Thursday, June 23, 2016 at 6:15:16 PM UTC-4, Val wrote:

 The commented line seems to have typo strconv.Ito

 Maybe the typo prevents proper recompilation, and server goes on with 
 old code?

>>>

-- 
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: [ANN] reform, a better ORM, reaches v1, moves to gopkg.in

[Tong Sun]

Thanks for open up and sharing you fourth milestone Alexey. I have the 
following questions:

- how to define the relations between multiple tables?
- how to deal with the case that a table has a composite primary key 
instead of just a single-field primary key?

The answers are better in the readme as well, IMO. 

On Wednesday, June 22, 2016 at 9:23:39 AM UTC-4, Alexey Palazhchenko wrote:
>
> Hi, 
>
> reform, an ORM based on non-empty interfaces, code generation, and 
> initialization-time reflection, reached version 1. Code moved to 
> https://github.com/go-reform/reform, and canonical import path now is 
> gopkg.in/reform.v1. Expect new releases to be tagged, with proper 
> changelogs, and SemVer-compatible. One can build an own library on top of 
> it without fear of compatibility breaking. 
>
> See https://github.com/go-reform/reform/blob/v1-stable/README.md for 
> details. 
>
> –-– 
> Alexey «AlekSi» Palazhchenko 
>
>

-- 
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: [ANN] Gomail v2: sending emails faster

[Bernard LEGAUT]

I recently switch from go 1.5.1 to go 1.6, and gomail seems to get in 
trouble. 

Anyone with the same issue ?

Thanks,





On Wednesday, September 2, 2015 at 8:55:26 AM UTC-3, Alexandre Cesaro wrote:
>
> Hi,
>
> I just released the second version of Gomail 
> .
>
> There are quite a few backward-incompatible changes 
>  since 
> Gomail v1 but it brings lots of good stuff:
>
>- A great focus was placed on performances. Gomail v2 is way more 
>efficient than Gomail v1 to send a large number of emails (see the 
>Daemon  
>or Newsletter 
> 
>examples).
>- The API is now clearer and way more flexible.
>- The documentation  improved 
>and many examples were added.
>- All existing issues have been closed.
>- The minimum Go version is now 1.2 instead of 1.3. No external 
>dependencies are used with Go 1.5.
>
> More info on Github: https://github.com/go-gomail/gomail
>

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

Fwd: [go-nuts] How to init a global map

[Tong Sun]

*(Thanks a lot for all your help Val!)*

One last question, which I wasn't able to find myself from
https://blog.golang.org/go-maps-in-action

Since a map is a pointer, for any function that take map as a parameter,
or function like,

 func (s set) Something(xxx)

Does it means the map values can be changed inside the function?

If yes, what's the proper way to declare it so as to make sure the values
cannot be changed inside the function?

Thanks, and sorry if the question seems too dumb.


-- Forwarded message --
From: Valentin Deleplace @gmail.com
Date: Fri, Jun 24, 2016 at 2:11 AM
Subject: Re: [go-nuts] How to init a global map
To: Tong Sun @gmail.com

No penalty, passing a map around never copies the values.
But a "pointer to a pointer" receiver is not strictly the same as a pointer
receiver.
Le 24 juin 2016 02:19, "Tong Sun" a écrit :

>
> On Thu, Jun 23, 2016 at 6:54 PM, Val  wrote:
>
> Even in OO style (e.g. java), you would not be able to write
>>  Set s = null;
>>  s.init( list(1,2,3) );
>>
>> This is (more or less) the same problem with value receiver... the
>> "constructor-like" idiom in go is a function NewSet, not a method :
>
>  https://play.golang.org/p/_n56yMhlRt
>
>
> * Now* I understand the reason behind such idiom in go. Yep, everything
> makes sense now.
>
> Thanks a lot for the clear explanation.
> That really helps.
>
> Hmm... wait,
>
> map is a reference type
>
>
> Does that means that, this function
>
> func (s set) Has(a string) bool { _, ok := s[a]; return ok }
>
> is exactly the same as the following?
>
> func (s *set) Has(a string) bool { _, ok := (*s)[a]; return ok }
>
> I.e., even the set is super super big, there is no pass-by-value penalty
> in the first version?
>
> Thx
>
>

-- 
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] Shuffle Items in a Slice

[Martin Geisler]

On Fri, Jun 24, 2016 at 1:05 PM, dc0d  wrote:
>
> Hi;
>
> To shuffle items in a slice I'm doing this:
>
> var res []Item
>
> //fill res logic
>
> shuffle := make(map[int]*Item)
> for k, v := range res {
>  shuffle[k] = 
> }
> res = nil
> for _, v := range shuffle {
>  res = append(res, *v)
> }
>
> Which inserts items into a map then ranges over that map. Ranging over a map 
> in Go returns the items in random order.
>
> 1 - I thought it's a cool trick!
> 2 - Is anything bad about doing this?

While iteration over a map is said to be random, it isn't specified
exactly how "random" the iteration is. The spec says

  https://golang.org/ref/spec#RangeClause
  The iteration order over maps is not specified and is not guaranteed
to be the same from one iteration to the next.

That is, the iteration order should not to be relied upon. A simple test like

  https://play.golang.org/p/czRE3pbMzc

shows this: the keys are printed in a scrambled order. When I run this
on my machine, I get a different order every time, but on the
playground the order seems to be fixed and I get "0 5 7 1 2 3 4 6 8 9"
every time. My guess would be that an external input is used to
initialize the hash function used behind the scene -- and on the
playground that input somehow has a fixed value.

Unless you're build a toy application, my advice would be to use a
real random generator to generate indexes into the map. Use these
indexes to swap elements and permute the array as Konstantin mentioned
(https://en.wikipedia.org/wiki/Fisher–Yates_shuffle).

-- 
Martin Geisler

-- 
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: Shuffle Items in a Slice

[Val]

2 implementations here : 
http://www.programming-idioms.org/idiom/10/shuffle-a-list/1564/go

As for the map iteration trick, the runtime doesn't guarantee to randomize 
anything, although it often tries to, so developers don't rely on some 
specific order. I've seen (in the past) some map iterations consistently 
not randomized at all. This behaviour may have evolved, but don't rely on 
it.


On Friday, June 24, 2016 at 1:05:49 PM UTC+2, dc0d wrote:
>
> Hi;
>
> To shuffle items in a slice I'm doing this:
>
> var res []Item
>
> //fill res logic
>
> shuffle := make(map[int]*Item)
> for k, v := range res {
>  shuffle[k] = 
> }
> res = nil
> for _, v := range shuffle {
>  res = append(res, *v)
> }
>
> Which inserts items into a map then ranges over that map. Ranging over a 
> map in Go returns the items in random order.
>
> 1 - I thought it's a cool trick!
> 2 - Is anything bad about doing this?
>

-- 
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: undefined: syscall.LoadLibrary

[Konstantin Khomoutov]

On Fri, 24 Jun 2016 03:22:23 -0700 (PDT)
Andrew Mezoni  wrote:

> >> So, how exactly does this method work with Linux shared libraries?
> 
> It does not work on Linux.
> On Linux you should use the methods:
> 
> dlclose, dlopen, dlmopen - open and close a shared object
> 
> http://man7.org/linux/man-pages/man3/dlopen.3.html

Note that these calls are provided by libc, not by the kernel (that's
why their manual pages are in section 3 BTW) so using them requires
using cgo -- contrary to syscall.LoadLibary() on Windows.

I don't know whether it's at all possible to have something like
dlopen() without touching libc on Linux (and other non-Windows
platforms) because that ultimately requires running the dynamic linker
program (well, at least that's my understanding).

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