[go-nuts] Re: Slice capacity changes

[18635789436zhjk]

I run the code and the two methods output the same results, all 8

在 2017年8月9日星期三 UTC+8上午8:57:07，sno写道：
>
> Hello,
>
> I was wondering if someone could help me understand what is going on in 
> the following piece of code.
>
> package main
>
> import (
> "fmt"
> "reflect"
> "unsafe"
> )
>
> func main() {
> a := []byte("1234567")
> printSliceDetails(a)
> }
>
> func printSliceDetails(a []byte) {
> sliceHeader := (*reflect.SliceHeader)(unsafe.Pointer())
> fmt.Printf("Backing array location: %v, data: %s, len: %d, cap: %d\n",
> sliceHeader.Data, string(a), len(a), cap(a))
>
> // fmt.Printf("Backing array location: %v, data: %s, len: %d, cap: %d\n",
> // sliceHeader, string(a), len(a), cap(a))
> }
>
>
> In the above code, the capacity prints 32. However, if you comment the 
> first print statement and remove the commenting on the second and run the 
> program again the capacity will only be 8. What is happening with 
> sliceHeader.Data to make its capacity grow like that?
>
> Thanks,
> Farley
>

-- 
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] Can warnings of race detector be ignored and toleranted?

[Dan Kortschak]

No.

https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-wha
t-could-possibly-go-wrong

On Tue, 2017-08-08 at 19:52 -0700, Cholerae Hu wrote:
> Some of my colleagues think that, in some cases, such as
> approximately 
> counting the sum total of requests, we don't need to know the
> accurate 
> value, so we can let several goroutines to access one variable
> without lock 
> or atomic operation to get the highest performance, and we can ignore
> the 
> warning of race detector in these cases. Is that true?
> 

-- 
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] Can warnings of race detector be ignored and toleranted?

[Cholerae Hu]

Some of my colleagues think that, in some cases, such as approximately 
counting the sum total of requests, we don't need to know the accurate 
value, so we can let several goroutines to access one variable without lock 
or atomic operation to get the highest performance, and we can ignore the 
warning of race detector in these cases. Is that true?

-- 
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] Slice capacity changes

[sno]

Hmm, interesting. However, wouldn't that mean that if I removed the 
function and did the following: https://play.golang.org/p/enI6UmYoFJ the 
escape analysis wouldn't happen?

On Wednesday, August 9, 2017 at 1:23:15 PM UTC+12, Marvin Renich wrote:
>
> * sno  [170808 20:57]: 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "reflect" 
> > "unsafe" 
> > ) 
> > 
> > func main() { 
> > a := []byte("1234567") 
> > printSliceDetails(a) 
> > } 
> > 
> > func printSliceDetails(a []byte) { 
> > sliceHeader := (*reflect.SliceHeader)(unsafe.Pointer()) 
> > fmt.Printf("Backing array location: %v, data: %s, len: %d, cap: %d\n", 
> > sliceHeader.Data, string(a), len(a), cap(a)) 
> > 
> > // fmt.Printf("Backing array location: %v, data: %s, len: %d, cap: 
> %d\n", 
> > // sliceHeader, string(a), len(a), cap(a)) 
> > } 
> > 
> > In the above code, the capacity prints 32. However, if you comment the 
> > first print statement and remove the commenting on the second and run 
> the 
> > program again the capacity will only be 8. What is happening with 
> > sliceHeader.Data to make its capacity grow like that? 
>
> I'm not an expert, but my guess is that the compiler is doing escape 
> analysis and allocating a on the heap in the first case and on the stack 
> in the second case (with different minimum allocation sizes). 
>
> Hopefully someone else can give a more authoritative answer. 
>
> ...Marvin 
>
>

-- 
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] Slice capacity changes

[Marvin Renich]

* sno  [170808 20:57]:
> package main
> 
> import (
> "fmt"
> "reflect"
> "unsafe"
> )
> 
> func main() {
> a := []byte("1234567")
> printSliceDetails(a)
> }
> 
> func printSliceDetails(a []byte) {
> sliceHeader := (*reflect.SliceHeader)(unsafe.Pointer())
> fmt.Printf("Backing array location: %v, data: %s, len: %d, cap: %d\n",
> sliceHeader.Data, string(a), len(a), cap(a))
> 
> // fmt.Printf("Backing array location: %v, data: %s, len: %d, cap: %d\n",
> // sliceHeader, string(a), len(a), cap(a))
> }
> 
> In the above code, the capacity prints 32. However, if you comment the 
> first print statement and remove the commenting on the second and run the 
> program again the capacity will only be 8. What is happening with 
> sliceHeader.Data to make its capacity grow like that?

I'm not an expert, but my guess is that the compiler is doing escape
analysis and allocating a on the heap in the first case and on the stack
in the second case (with different minimum allocation sizes).

Hopefully someone else can give a more authoritative answer.

...Marvin

-- 
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: Slice capacity changes

[sno]

Example at: https://play.golang.org/p/d7HBrbZGo4

-- 
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] [ANN] Edit - Acme command language

[roger peppe]

Hang by your pseudopod, write if you find a warm rich planet ripe for conquest.

On 8 August 2017 at 22:49, Rob Pike  wrote:
> Grep for conquest.
>
> -rob
>
>
> On Wed, Aug 9, 2017 at 6:58 AM, roger peppe  wrote:
>> On 8 August 2017 at 21:34, Michael Jones  wrote:
>>> The Four Horsemen of the Apocalypse, surely! It would be tempting fate to
>>> shade them or step on their brand.
>>
>> Ah, but of which apocalypse?
>>
>> --
>> 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] A humble request/challenge

[Michael Jones]

I remember a segmented wheel of Aitkin implementation. Maybe you can start
with that.

here are a few: https://golanglibs.com/top?q=sieve


On Tue, Aug 8, 2017 at 3:31 PM, Pierpaolo Bernardi 
wrote:

> Hello,
>
> > Here's a link to read and download the paper:
> >
> > https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ
>
> Downloading the paper requires a scribd account which costs money(*).
> Is the paper available for free somewhere else?
>
> (*) Or one can use the free month they offer, but misteriously to get
> a free month they require you give them your credit card number.
>
> Cheers!
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A humble request/challenge

[Jan Mercl]

On Wed, Aug 9, 2017 at 12:32 AM Pierpaolo Bernardi 
wrote:

> Downloading the paper requires a scribd account which costs money(*).
> Is the paper available for free somewhere else?

My 2-minute skimming smells quite crackpot-ish
 (#25). Or maybe it's a
download-fee scam?

Check also:
https://www.google.com/search?q=%22humble+request%22+%22The+Segmented+Sieve+of+Zakiya%22=%22humble+request%22+%22The+Segmented+Sieve+of+Zakiya%22

-- 

-j

-- 
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] A humble request/challenge

[Pierpaolo Bernardi]

Hello,

> Here's a link to read and download the paper:
>
> https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ

Downloading the paper requires a scribd account which costs money(*).
Is the paper available for free somewhere else?

(*) Or one can use the free month they offer, but misteriously to get
a free month they require you give them your credit card number.

Cheers!

-- 
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] [ANN] Edit - Acme command language

[Rob Pike]

Grep for conquest.

-rob


On Wed, Aug 9, 2017 at 6:58 AM, roger peppe  wrote:
> On 8 August 2017 at 21:34, Michael Jones  wrote:
>> The Four Horsemen of the Apocalypse, surely! It would be tempting fate to
>> shade them or step on their brand.
>
> Ah, but of which apocalypse?
>
> --
> 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] A humble request/challenge

[Jabari Zakiya]

Hi

I primarly use Ruby for math/science problems/projects because it's so easy 
to program in, and it allows me to think about how to solve problems 
without worrying about how to code it. I've also played around with Crystal 
(aka Ruby on steroids) but it's still young, and doesn't let me (currently) 
do what I want, or without a lot of hassles, and I've just recently started 
looking at Nim (less than a month at time of writing).

I heard about Go for sometime but never had any time/reason to learn it.  
But now maybe I have incentive to do so.

I developed a prime sieve called the *Sieve of Zakiya (SoZ)*, and it's 
companion the *Segmented Sieve of Zakiya (SSoZ)*. I wrote a paper, **The 
Segmented Sieve of Zakiya (SSoZ)** which describes its mathematical 
foundations and algorithm, and provide a working C++ implementation at the 
end of the paper (compiled, run, and verified), though I don't consider 
myself a C++ programmer, just funcitonal enough in it. It's a relatively 
short program.

Here's a link to read and download the paper:

https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ

My humble request/challenge is for a/some skilled Golanger(?) to translate 
the code into idiomatic Go to demonstrate the best way to code the 
algorithm in it.  Extra points if someone can do a true parallel version of 
the algorithm, which I attempted to do using OpemMP, but what I did didnt' 
seem to make the code faster than the serial version (see paper).

I assume coding this the *Go way* would look different than the C++ code, 
and be quite different than a direct translation into Go using the same 
(probably suboptimal) structure.

Ultimately, I'd like to publish the results of benchmarks in different 
languages doing the SSoZ in an updated paper.

If anyone would be willing to take up the challenge I'd be pleased to 
answer any questions the best I can.

Thanks in advance.

Jabari

-- 
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] Context should go away for Go 2

[Sam Whited]

On Mon, Aug 7, 2017, at 11:33, Uli Kunitz wrote:
> I assume here that the proposal is not to change io.Reader but to …

There is no proposal. This was briefly discussed in the contributors
summit, but the underlying issues are not necessarily well understood.
Blog posts like this one help us all understand those issues better.
Apologies if I made it sound like this was something that was going to
happen in the contributors summit post; everything at the summit was
just a discussion which, for the most part, avoided concrete solutions.

—Sam

-- 
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] [ANN] Edit - Acme command language

[roger peppe]

On 8 August 2017 at 21:34, Michael Jones  wrote:
> The Four Horsemen of the Apocalypse, surely! It would be tempting fate to
> shade them or step on their brand.

Ah, but of which apocalypse?

-- 
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] [ANN] Edit - Acme command language

[Michael Jones]

The Four Horsemen of the Apocalypse, surely! It would be tempting fate to
shade them or step on their brand.

On Tue, Aug 8, 2017 at 5:54 AM,  wrote:

> Thanks for suggesting the Reader(q0, q1 int64) io.RuneReader. I
> accidentally replied off list.
>
> I wasn't aware of up to four horsemen being involved. The man pages didn't
> prepare me for 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How to setup go-swagger for an existing project to generate API docs

[Dayana Mallasserry]

Has anyone set up swagger for an existing golang project ? 

-- 
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] Context should go away for Go 2

[Piero de Salvia]

I agree with Dave Cheney and Michal Strba that Context should not be used 
for storage of any kind and only serve the purpose of cancelation.

In effect, the original purpose of Context, I think, was avoiding cascading 
failure in chains of  *network* calls, where the result of one call would 
be used as argument to the next call. In effect, a kill switch on the whole 
chain.

A deeper analysis of this feature makes me think that this is not so much 
about goroutines (hence not so much about thread local storage) as much as 
network failures.

And finally, I think the last thing anybody wants is to pollute the whole 
stdlib with Contexts. 

To me, given these requirements, context should become embedded in all 
network functions, just like a timeout is. 

Only difference, when creating a network function (client or server) one 
would (optionally) call SetContextName("MyContext") on it (I think the 
namespace suggestion from plan 9 is excellent), so a chain of network calls 
would belong to the same named context.

So when code owning that chain of network calls would need to cancel (in 
effect kill) the chain, it would just call a lib function called Cancel(ctx 
string) and the whole chain of calls would be killed: every network 
functions must obey a Cancel() call.

As far as extending it to Reader, it does not make sense to me. The reason 
why there is a Context today is that failures in chained network calls are 
difficult to detect and correct, because of inherent network 
characteristics. That is not a general case for a Reader.


On Monday, August 7, 2017 at 3:40:05 PM UTC+2, Michal Strba wrote:
>
> Hi everyone!
>
> I've written a blog post called 'Context should go away for Go 2':
>
> https://faiface.github.io/post/context-should-go-away-go2/
>
> The post is about the cancelation problem in Go, how context package 
> solves it, why context package is bad anyway, and that Go 2 should do 
> something about it. Hope you enjoy reading ;)
>
> PS: I'm not sure if this post is acceptable for an experience report. If 
> you think it is / isn't, let me know.
>
> Michal Štrba
>

-- 
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] chaining contexts, best practices question

[Josh Humphries]

I noticed the Go doc for context.Context includes the following snippet:

Do not store Contexts inside a struct type; instead, pass a Context
> explicitly to each function that needs it.


I think one potential reason for going against this advice is maintaining
context chain relationships in servers. In a server object, it seems
reasonable to provide a context when starting the server (which is valid
for the lifetime the server is serving) and the server to then store that
context in a struct. The reason it would be stored is that it could be used
to create child contexts when handling incoming data from the socket (or
whatever the server does).

The reason I would do this is two-fold:

   1. It is convenient and IMO elegant (particularly, but not exclusively,
   in test code) to be able to simply cancel a top-level context and have that
   respected throughout the chain, resulting in the server stopping and
   tearing itself down.
   2. It is a natural place for server-scoped contextual data. For example,
   we use a log library that allows log writer configuration to be stored in
   context. We could configure the log writer once for the server and have it
   then correctly applied to every action taken by the server, including
   request dispatches.

Does this seem like a reasonable approach, or are there other possibly
better practices for addressing these issues?

Obviously we must do things differently for HTTP and GRPC servers since
those libraries do not expose a way to provide a "parent context" for the
whole server. In those cases, we provide a method for registering HTTP
handlers that will wrap an incoming handler with one that decorates the
request context (for bullet #2 above; and we can use interceptors for
GRPC). For bullet #1, we have to implement our own cancellation propagation
-- like a goroutine that will stop the server(s) when the root context gets
cancelled.

I'm curious how others tackle these kinds of concerns.


*Josh Humphries*
jh...@bluegosling.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

[Daniel Theophanes]

I'm personally reasonably happy with Context as-is. Bit if you are looking
for a better solution, I completly agree with "as.utf8": the solution won't
be found in TLS/GLS (goroutine local storage) but in some other
contextual/namespace/arena type thing that is larger then a single
goroutine, is still cooperative, and can expose properties that allow
transporting it over the network as Context allows today.

On Mon, Aug 7, 2017 at 10:46 PM  wrote:

> Threads are the structural and functional loci of execution on some
> operating systems, data stored in a box accessible to each thread makes
> sense when you obey the constraint that the things in that box are to be
> used for that thread exclusively.
>
> Goroutines are different, they function like threads but have different
> structure. Structurally, they are not intended to preserve state accessible
> to the user. Goroutines are light, and I suspect that the idiom of
> goroutine local storage is incompatible to the design of the language:
> anonymous loci of flow control communicating through channels as conduits.
>
> If I could wish for an idiom taken from operating systems, TLS/GLS
> wouldn't be my first choice. I see namespaces serving a similar role on
> Plan9. The ability to share a namespace with the child or parent process.
> Namespaces include the environment and allow the caller too configure what
> resources a process has access to upon execution. Such an addition would
> also violate the unwritten rule of anonymous processes, but context is
> already doing that. The difference is that context is based on what is
> being executed (what function is called) and not where (which goroutine).
> Contexts are like function namespaces. They even have a map of arbitrary
> key-values.
>
> The exercise is to find a way to make this feel natural to the language,
> and apply such an approach to functions instead of processes, threads, or
> goroutines.
>
> --
> 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/eEDlXAVW9vU/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: Go 1.9 Release Candidate 2 is released

[Ian Lance Taylor]

On Mon, Aug 7, 2017 at 10:38 PM, ifreelance Asia
 wrote:
>
> Will there be any Performance Improvement for RegEx in Golang - It is one of
> the most hyped and relevant issue.

No particular improvements are expected.  Let's take any discussion of
this to a separate thread, not the rc2 announcement thread.  Thanks.

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] [ANN] Edit - Acme command language

[as . utf8]

Thanks for suggesting the Reader(q0, q1 int64) io.RuneReader. I accidentally 
replied off list. 

I wasn't aware of up to four horsemen being involved. The man pages didn't 
prepare me for 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.

[go-nuts] Re: Go 1.9 Release Candidate 2 is released

[ifreelance Asia]

Will there be any *Performance Improvement for RegEx in Golang* - It is one 
of the most hyped and relevant issue.

One of the reference : 
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go=node 
( Regex-redux ) and more 

-- 
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] How to secure variables in memory?

[Awn Umar]

Seems like this is what you're looking for:

Project page: https://github.com/awnumar/memguard
Explanation: https://cryptolosophy.io/memory-security-go/

-- 
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] "find" for Slices like "append"

[roger peppe]

On 8 August 2017 at 08:15,  wrote:

>
>> The Go philosophy is explicitly *not* to give you everything you want.
>> It *is* to give you everything you need to build everything you want,
>> like Lego.
>>
>
> Yeah right, when men still where real men and programmed their own device
> drivers...
>
> Or take a car, give me parts & tools and I am ready to give you a ride in
> say a year?
>
>
>> Every language is different. Any developer worth their salt won't dismiss
>> a tool out-of-hand for such a trivial reason.
>>
>
> No nobody would. But trivial things add up and then people run away or
> never sign up.
>
> I have learnt to never not listen to your (potential) users.
>
> If a new project comes on board of the Go train, people already have to
> wrap their heads around new (admittedly interesting) concepts, they have to
> accept "err != nil" spaghetti, distinction between Array and Slices, make
> and new, and so on.
>
> Personally I got really interested when I died around your standard
> library which I really like and it seems to give us exactly what we need,
> not too much, not too little.
>
>>
>> Also, consider the fact that in Python, the same loop is happening. Go
>> just doesn't hide that from the developer, making it easier for us to
>> reason about things like performance. You can write your own "find"
>> function in seconds if you want one.
>>
>
> It just looks awkward:
>
> contains := false
> for _, n := range excluded_numbers {
>   if byte(m) == n {
> contains = true
>   }
> }
> if !contains {
>...
>
> Seriously? 2017?
>

I'd usually write that as as separate function:

func isExcluded(ns []byte, m byte) bool {
 for _, n := range ns {
  if  n == m {
   return true
  }
 }
 return false
}

For that *particular* case, you could always use
bytes.Index(excluded_numbers, byte(m)) >= 0
though.

Yes, it feels a little tedious sometimes, but if you
add up the number of times you actually have to do this,
it's generally not too much. There's a trade-off going
on here.

  cheers,
rog.


> Martin
>
>
>> --
>> ☕
>>
> --
> 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] Re: Generics are overrated.

[Jan Mercl]

On Tue, Aug 8, 2017 at 1:37 PM Haddock  wrote:

> Currently Java developers would not change to Go.

Never enough of good news.

-- 

-j

-- 
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: Go channels overused and hyped?

[Dave Cheney]

Channels are always going to be more expensive than using a lock if all your 
doing is timing the cost of the lock vs a channel; aka hello world of channels. 
Channels are there to send values between goroutines representing work to do, 
in which case that work has to be significantly more than the cost of the 
transmission otherwise it's easier to just do the work yourself. 

-- 
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: Generics are overrated.

[Haddock]

In my opinion generics added to Go would make Go really take off. Currently 
Java developers would not change to Go. With Go having generics this would 
change and more people would consider Go also when not coming from 
Java/C#/etc.

-- 
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: Go channels overused and hyped?

[Haddock]

CSP style concurrency in Go is the killer feature in Go. It makes 
concurrent programming so much easier. To understand this you need to have 
done some years of concurrent programming using asynchronous calls, 
threads, locks, semaphores and all that stuff. I have done that and I can 
say that CSP style programming in Go with the use of channels makes 
concurrent programming much much easier. Much easier to get things right 
from the beginning, much easier to fix things. I have actually spent years 
fixing other people's and my mistakes causing race conditions and 
deadlocks. People who have not experienced this have no considerable 
experience in concurrent programming and don't know what they are talking 
about. 

You have to mention that green threads (aka goroutines) are not preemptive, 
though. This is what you have to pay for what you get for the ease of 
concurrent programming using CSP. For many applications this is a very good 
trade-off. All the server-side applications written in Go confirm this.


Am Dienstag, 8. August 2017 08:01:12 UTC+2 schrieb snmed:
>
> Hi Gophers
>
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> "
>  
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
>
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
>
> Cheers snmed
>

-- 
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] [ANN] Edit - Acme command language

[roger peppe]

On 8 August 2017 at 12:04, Rob Pike  wrote:
> When I wrote that (1985?), I was misinformed about the Four Horsemen.

Which particular Four Horsemen would those be?

-- 
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] [ANN] Edit - Acme command language

[Rob Pike]

When I wrote that (1985?), I was misinformed about the Four Horsemen.
Also now "u-" is redo.

-rob


On Tue, Aug 8, 2017 at 8:59 PM, roger peppe  wrote:
> It's nice to see this, but it would be nicer still if it
> was amenable to representations that weren't
> just a slice of bytes (for example disk or network
> backed files, or just something which made insertions
> not O(n)). It seems like it might be possible
> to use Regexp.FindReader* to avoid duplicating
> the stdlib's regexp package.
>
> On 8 August 2017 at 11:10,   wrote:
>> I'm sure this has been done already, but I thought I'd share my
>> implementation of this here for anyone interested in using structural
>> regular expressions in Go. It doesn't cover 100% of what Edit does in Acme,
>> but its close enough that I can use the example program as a substitute to
>> sed on Windows.
>>
>> github.com/as/edit
>>
>> Reference
>>
>> http://doc.cat-v.org/bell_labs/sam_lang_tutorial/
>>
>> --
>> 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.

-- 
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: Go channels overused and hyped?

[Konstantin Khomoutov]

On Tue, Aug 08, 2017 at 03:39:42AM -0700, snmed wrote:

> > There are trade-offs.
> >
> > Channels are easy to use for simple things, but complicated for complected 
> > things.
> >
> > Locking data-structures can easily introduce data-races (see The Little 
> > Book of Semaphores http://greenteapress.com/wp/semaphores/).
[...]
> Thank you for your reply, I myself used channel as a semaphore, i'm not 
> sure if that is a appropriate use case for channels.
[...]

Channels are quite good to implement simple counting semaphores (those
which have more than a single token / permit to provide): the length of
the channel used in this way is the quantity of permits the semaphore
has, a send to such channel is acquisition of a permit, and receiving
from it returning of the acquired permit back to the semaphore.

Acquisition hence naturally blocks if the semaphore has no free permits
and blocks the requesting goroutine until a free permit becomes
available.

You can easily combine this with a timer to get a counting semaphore
with a timeout.

-- 
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] [ANN] Edit - Acme command language

[roger peppe]

It's nice to see this, but it would be nicer still if it
was amenable to representations that weren't
just a slice of bytes (for example disk or network
backed files, or just something which made insertions
not O(n)). It seems like it might be possible
to use Regexp.FindReader* to avoid duplicating
the stdlib's regexp package.

On 8 August 2017 at 11:10,   wrote:
> I'm sure this has been done already, but I thought I'd share my
> implementation of this here for anyone interested in using structural
> regular expressions in Go. It doesn't cover 100% of what Edit does in Acme,
> but its close enough that I can use the example program as a substitute to
> sed on Windows.
>
> github.com/as/edit
>
> Reference
>
> http://doc.cat-v.org/bell_labs/sam_lang_tutorial/
>
> --
> 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] Re: Go channels overused and hyped?

[snmed]

Hi Dave

Thank you for your comment, I will read your talk on my way back home later 
and I'm sure i get some better insight in go concurrency.
But his argument about better performance of mutex over channels is still 
valid, maybe you have covered that in your talk, i will see later.

Cheers snmed


Am Dienstag, 8. August 2017 09:51:08 UTC+2 schrieb Dave Cheney:
>
> Everyone overused channels and goroutines at first. Why wouldn't you? 
> That's why you probably decided to try Go in the first place.
>
> I have a talk in Singapore a few months ago trying to explore this idea. 
> It sort of went in a different direction, but the conclusion might be 
> interesting for you.
>
> https://dave.cheney.net/paste/concurrency-made-easy.pdf
>
>

-- 
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: Go channels overused and hyped?

[snmed]

Hi Egon

Thank you for your reply, I myself used channel as a semaphore, i'm not 
sure if that is a appropriate use case for channels.

Anyhow your opionion is very welcome
 

Am Dienstag, 8. August 2017 09:26:35 UTC+2 schrieb Egon:
>
> There are trade-offs.
>
> Channels are easy to use for simple things, but complicated for complected 
> things.
>
> Locking data-structures can easily introduce data-races (see The Little 
> Book of Semaphores http://greenteapress.com/wp/semaphores/).
>
> The Game/Player example looks weird to me; there's one piece missing -- 
> without it, the full complexity is not seen.
>
> With regards to callbacks (context.Done) specifically, in one case you 
> control the goroutine it gets executed in, in the other not.
>
> Not closing the waiting channel inside context leaking goroutine is 
> moot... when you forget to invoke the callbacks, you will leak as well when 
> you have resource releasing in the callback.
>
> Channels are quite good for producer-consumer things, but tend to get very 
> complicated for dispatches.
>
> *tl;dr; channels and locking have trade-offs, instead of hopping on the 
> bandwagon, understand the trade-offs and pick the one that is most suitable 
> in a certain situation.*
>
> + Egon
>
> On Tuesday, 8 August 2017 09:01:12 UTC+3, snmed wrote:
>>
>> Hi Gophers
>>
>> I stumbled over a nice and very interesting Blog entry "Go channels are 
>> bad and you should feel bad 
>> "
>>  
>> , I would like to hear some opinions about that article
>> from seasoned go developers. Because I just used go for a couple of 
>> months for my private web projects and rarely get in touch with channels.
>>
>> By the way, that article is not a rant and the author likes go very much 
>> as far as I can conclude from the article.
>>
>> Cheers snmed
>>
>

-- 
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: Go channels overused and hyped?

[as . utf8]

Author did a range over channel without select, making cancellation 
impossible without closing the channel or the process. However, author 
challenges user to solve cancellation problems with no selection, even 
saying he awaits for the user to accomplish this. So author will stop 
waiting when notified, or call them back, to say it's been done. Because it 
is not possible, we presume author is still blocked waiting on his 
completion signal, or worse, polling to see any completed the impossible.

In practice, the callback needs to live somewhere in memory. The select 
statement not so much; it could have provided cancellation by broadcasting 
through a "done" channel. For one reason or another, the author didn't do 
this and ranged through the channel instead.

On Monday, August 7, 2017 at 11:01:12 PM UTC-7, snmed wrote:
>
> Hi Gophers
>
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> "
>  
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
>
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
>
> Cheers snmed
>

-- 
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] "find" for Slices like "append"

[Christoph Berger]

May I ask why you turned to Go in the first place?

Your taunting remarks seem to indicate that you were forced moving to Go; 
but on the other hand, earlier you indicated that you need to sell Go (or 
rather, the lack of a feature in Go) to your team, so it seems you are the 
driving force behind moving to Go. 

In the latter case, if Go does not fulfill your expectations (and given you 
still have free choice), then have you thought about choosing a language 
with the features you need instead? I am sure no one here would seriously 
recommend Go as a "one-size-fits-all" language. Go does not have generics 
nor exceptions, so if you want these features badly, then Go isn't for you.


On Tuesday, August 8, 2017 at 9:15:05 AM UTC+2, marti...@programmfabrik.de 
wrote:
>
>
>> The Go philosophy is explicitly *not* to give you everything you want.  
>> It *is* to give you everything you need to build everything you want, 
>> like Lego.
>>
>
> Yeah right, when men still where real men and programmed their own device 
> drivers...
>
> Or take a car, give me parts & tools and I am ready to give you a ride in 
> say a year? 
>
>
>> Every language is different. Any developer worth their salt won't dismiss 
>> a tool out-of-hand for such a trivial reason.
>>
>
> No nobody would. But trivial things add up and then people run away or 
> never sign up.
>
> I have learnt to never not listen to your (potential) users.
>
> If a new project comes on board of the Go train, people already have to 
> wrap their heads around new (admittedly interesting) concepts, they have to 
> accept "err != nil" spaghetti, distinction between Array and Slices, make 
> and new, and so on.
>
> Personally I got really interested when I died around your standard 
> library which I really like and it seems to give us exactly what we need, 
> not too much, not too little.
>
>>
>> Also, consider the fact that in Python, the same loop is happening. Go 
>> just doesn't hide that from the developer, making it easier for us to 
>> reason about things like performance. You can write your own "find" 
>> function in seconds if you want one.
>>
>
> It just looks awkward:
>
> contains := false
> for _, n := range excluded_numbers {
>   if byte(m) == n {
> contains = true
>   }
> }
> if !contains {
>...
>
> Seriously? 2017?
>
> Martin
>
>  
>> -- 
>> ☕
>>
>

-- 
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] [CGO] how to pass a 2d slice to C?

[jianzhangbjz]

Awesome! Thanks again for your kindly help. :) And I updated the code, it 
works! 

在 2017年8月8日星期二 UTC+8下午3:51:10，Konstantin Khomoutov写道：
>
> On Mon, Aug 07, 2017 at 08:20:01PM -0700, jianzh...@gmail.com 
>  wrote: 
>
> [...] 
> > > > > > golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
> > > > > >levelmatrix := make([][]C.int, len(golevelmatrix)) 
> > > > > >for i, _ := range golevelmatrix { 
> > > > > >levelmatrix[i] = make([]C.int, len(golevelmatrix[i])) 
> > > > > >for j, _ := range golevelmatrix[i] { 
> > > > > >levelmatrix[i][j] = C.int(golevelmatrix[i][j]) 
> > > > > >} 
> > > > > >} 
> > > [...] 
> > > 
> > > I'd like to reiterate more precisely: your client is expecting a 
> > > multi-dimensional array which, in C, would be a contiguous region of 
> > > memory.  The Go's [][]C.int is a slice of individual []C.int slices. 
> > > Hence when you pass [0][0] to your C client, it receives 
> the 
> > > address of the first element of the first slice, and the only valid 
> > > region of memory to access via that pointer is that element and all 
> the 
> > > element following it up to (but not including) the length of the first 
> > > slice. 
> [...] 
> > But, if I can not change the C client, how to implement it? the C client 
> as 
> > the following. As described on the above, I have to change the ` int** 
> >  _levelmatrix` argument, right? 
> > bool test_settopologyresource(bsagomodule* _self, char* _nodename, 
> >int _resourceindex, char** _nameunits, int** _levelmatrix) { 
> >printf("\n set topology resource-> node:%s, resource index:%d", 
> _nodename 
> > , _resourceindex); 
> >bool result = settopologyresource(_self->client, _nodename, 
> > _resourceindex, _nameunits, _levelmatrix); 
> >return result; 
> > } 
>
> Ah, I see. 
>
> So, do I understand correctly that your C side is actually expecting 
> an "array of arrays" (or "jagged array" as some call them)? 
> That would explain the int** type your function expects. 
>
> If yes, this is doable without changing the C side -- by C.malloc()'ing 
> each member array and storing the pointer to it in the main array: 
>
>   package main 
>   
>   import "unsafe" 
>   
>   /* 
>   extern int crunch_matrix(int **a); 
>   */ 
>   import "C" 
>   
>   func main() { 
>   golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
>   
>   matrix := make([]*C.int, len(golevelmatrix)) 
>   for i, row := range golevelmatrix { 
>   p := (*C.int)(C.malloc(C.size_t(C.sizeof_int * 
> len(row 
>   matrix[i] = p 
>   
>   pa := (*[1 << 30]C.int)(unsafe.Pointer(p)) 
>   for j, v := range row { 
>   (*pa)[j] = C.int(v) 
>   } 
>   } 
>   C.crunch_matrix([0]) 
>   } 
>
> Here, for each row of the source matrix we allocate an array of C.int of 
> the source row's size, and place a pointer to it into the destination 
> slice. 
>
> To fill the allocated row array with the source values without jumping 
> through the hoops of direct pointer arithmetics, we type-convert the 
> value of "p" (which has type *C.int) to the type *[1 << 30]C.int which 
> is a pointer to a very long array of C.int (read more on this in the 
> section "Turning C arrays into Go slices" in [1]). 
>
> Note two problems with this approach. 
>
> First, I made no effort to free the memory obtained by calls to 
> C.malloc().  That's mostly for brewity, but see below. 
>
> Second, as the code stands now, as soon as we allocate an array for the 
> target row, the information of its size is lost.  We can safely pass the 
> pointer to it to C.free (because C.malloc stores a special block of 
> information along with each block it allocates which contains the length 
> of that block) but I fail to see how your C side is aware of the length 
> of each row array.  On the Go side, the matrix is a slice of slices, and 
> since a Go slice is fully self-aware, that's OK but in C, an array is 
> merely a pointer, and it carries no information of the length of the 
> memory block pointed to by that pointer. 
>
> Hence, unless I fail to spot where you encode this information in 
> the arguments supplied to test_settopologyresource(), this might 
> indicate a problem with your design of your C side: you might need to 
> either use a custom type for the rows of your C matrix (a struct 
> containing a pointer and a size, for instance) or operate on full square 
> matrices as in my first example. 
>
> 1. https://github.com/golang/go/wiki/cgo 
>
>

-- 
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] [ANN] Edit - Acme command language

[as . utf8]

I'm sure this has been done already, but I thought I'd share my 
implementation of this here for anyone interested in using structural 
regular expressions in Go. It doesn't cover 100% of what Edit does in Acme, 
but its close enough that I can use the example program 
 as a substitute 
to sed on Windows.

github.com/as/edit

Reference

http://doc.cat-v.org/bell_labs/sam_lang_tutorial/

-- 
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] "find" for Slices like "append"

[Jan Mercl]

On Tue, Aug 8, 2017 at 9:06 AM  wrote:

> Sort.Search is nice, but then the list has to be sorted.

Then it's a simple for range loop.

> So why not come up with
>
> func findFirst(slice interface{}, matches func(i int
) bool
)

I hope this never happens, but the standard approach is to fill a
'proposal: foo' at the issue tracker.


-- 

-j

-- 
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] Go channels overused and hyped?

[Dave Cheney]

Everyone overused channels and goroutines at first. Why wouldn't you? That's 
why you probably decided to try Go in the first place.

I have a talk in Singapore a few months ago trying to explore this idea. It 
sort of went in a different direction, but the conclusion might be interesting 
for you.

https://dave.cheney.net/paste/concurrency-made-easy.pdf

-- 
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] [CGO] how to pass a 2d slice to C?

[Konstantin Khomoutov]

On Mon, Aug 07, 2017 at 08:20:01PM -0700, jianzhang...@gmail.com wrote:

[...]
> > > > > golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
> > > > >levelmatrix := make([][]C.int, len(golevelmatrix)) 
> > > > >for i, _ := range golevelmatrix { 
> > > > >levelmatrix[i] = make([]C.int, len(golevelmatrix[i])) 
> > > > >for j, _ := range golevelmatrix[i] { 
> > > > >levelmatrix[i][j] = C.int(golevelmatrix[i][j]) 
> > > > >} 
> > > > >} 
> > [...] 
> >
> > I'd like to reiterate more precisely: your client is expecting a 
> > multi-dimensional array which, in C, would be a contiguous region of 
> > memory.  The Go's [][]C.int is a slice of individual []C.int slices. 
> > Hence when you pass [0][0] to your C client, it receives the 
> > address of the first element of the first slice, and the only valid 
> > region of memory to access via that pointer is that element and all the 
> > element following it up to (but not including) the length of the first 
> > slice. 
[...]
> But, if I can not change the C client, how to implement it? the C client as 
> the following. As described on the above, I have to change the ` int**
>  _levelmatrix` argument, right?
> bool test_settopologyresource(bsagomodule* _self, char* _nodename,
>int _resourceindex, char** _nameunits, int** _levelmatrix) {
>printf("\n set topology resource-> node:%s, resource index:%d", _nodename
> , _resourceindex);
>bool result = settopologyresource(_self->client, _nodename, 
> _resourceindex, _nameunits, _levelmatrix);
>return result;
> }

Ah, I see.

So, do I understand correctly that your C side is actually expecting
an "array of arrays" (or "jagged array" as some call them)?
That would explain the int** type your function expects.

If yes, this is doable without changing the C side -- by C.malloc()'ing
each member array and storing the pointer to it in the main array:

  package main
  
  import "unsafe"
  
  /*
  extern int crunch_matrix(int **a);
  */
  import "C"
  
  func main() {
golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}}
  
matrix := make([]*C.int, len(golevelmatrix))
for i, row := range golevelmatrix {
p := (*C.int)(C.malloc(C.size_t(C.sizeof_int * len(row
matrix[i] = p
  
pa := (*[1 << 30]C.int)(unsafe.Pointer(p))
for j, v := range row {
(*pa)[j] = C.int(v)
}
}
C.crunch_matrix([0])
  }

Here, for each row of the source matrix we allocate an array of C.int of
the source row's size, and place a pointer to it into the destination
slice.

To fill the allocated row array with the source values without jumping
through the hoops of direct pointer arithmetics, we type-convert the
value of "p" (which has type *C.int) to the type *[1 << 30]C.int which
is a pointer to a very long array of C.int (read more on this in the
section "Turning C arrays into Go slices" in [1]).

Note two problems with this approach.

First, I made no effort to free the memory obtained by calls to
C.malloc().  That's mostly for brewity, but see below.

Second, as the code stands now, as soon as we allocate an array for the
target row, the information of its size is lost.  We can safely pass the
pointer to it to C.free (because C.malloc stores a special block of
information along with each block it allocates which contains the length
of that block) but I fail to see how your C side is aware of the length
of each row array.  On the Go side, the matrix is a slice of slices, and
since a Go slice is fully self-aware, that's OK but in C, an array is
merely a pointer, and it carries no information of the length of the
memory block pointed to by that pointer.

Hence, unless I fail to spot where you encode this information in
the arguments supplied to test_settopologyresource(), this might
indicate a problem with your design of your C side: you might need to
either use a custom type for the rows of your C matrix (a struct
containing a pointer and a size, for instance) or operate on full square
matrices as in my first example.

1. https://github.com/golang/go/wiki/cgo

-- 
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: Go channels overused and hyped?

[Egon]

There are trade-offs.

Channels are easy to use for simple things, but complicated for complected 
things.

Locking data-structures can easily introduce data-races (see The Little 
Book of Semaphores http://greenteapress.com/wp/semaphores/).

The Game/Player example looks weird to me; there's one piece missing -- 
without it, the full complexity is not seen.

With regards to callbacks (context.Done) specifically, in one case you 
control the goroutine it gets executed in, in the other not.

Not closing the waiting channel inside context leaking goroutine is moot... 
when you forget to invoke the callbacks, you will leak as well when you 
have resource releasing in the callback.

Channels are quite good for producer-consumer things, but tend to get very 
complicated for dispatches.

*tl;dr; channels and locking have trade-offs, instead of hopping on the 
bandwagon, understand the trade-offs and pick the one that is most suitable 
in a certain situation.*

+ Egon

On Tuesday, 8 August 2017 09:01:12 UTC+3, snmed wrote:
>
> Hi Gophers
>
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> "
>  
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
>
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
>
> Cheers snmed
>

-- 
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] "find" for Slices like "append"

[martin . rode]

>
>
> The Go philosophy is explicitly *not* to give you everything you want.  
> It *is* to give you everything you need to build everything you want, 
> like Lego.
>

Yeah right, when men still where real men and programmed their own device 
drivers...

Or take a car, give me parts & tools and I am ready to give you a ride in 
say a year? 


> Every language is different. Any developer worth their salt won't dismiss 
> a tool out-of-hand for such a trivial reason.
>

No nobody would. But trivial things add up and then people run away or 
never sign up.

I have learnt to never not listen to your (potential) users.

If a new project comes on board of the Go train, people already have to 
wrap their heads around new (admittedly interesting) concepts, they have to 
accept "err != nil" spaghetti, distinction between Array and Slices, make 
and new, and so on.

Personally I got really interested when I died around your standard library 
which I really like and it seems to give us exactly what we need, not too 
much, not too little.

>
> Also, consider the fact that in Python, the same loop is happening. Go 
> just doesn't hide that from the developer, making it easier for us to 
> reason about things like performance. You can write your own "find" 
> function in seconds if you want one.
>

It just looks awkward:

contains := false
for _, n := range excluded_numbers {
  if byte(m) == n {
contains = true
  }
}
if !contains {
   ...

Seriously? 2017?

Martin

 
> -- 
> ☕
>

-- 
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] "find" for Slices like "append"

[martin . rode]

Sort.Search is nice, but then the list has to be sorted. Wasnt there a 
lenghty discussion on how awkward sorting is compared to other languages, 
and then in 1.8. finally someone implemented 

func Slice(slice interface{}, less func(i, j int 
) bool 
)

which already makes it easier to Sort a slice.

So why not come up with

func findFirst(slice interface{}, matches func(i int 
) bool 
)

or so?

-- 
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] Go channels overused and hyped?

[snmed]

Hi Gophers

I stumbled over a nice and very interesting Blog entry "Go channels are bad 
and you should feel bad 
"
 
, I would like to hear some opinions about that article
from seasoned go developers. Because I just used go for a couple of months 
for my private web projects and rarely get in touch with channels.

By the way, that article is not a rant and the author likes go very much as 
far as I can conclude from the article.

Cheers snmed

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