[go-nuts] Local mod version

[Pierre Curto]

Hello gophers,

Trying to locally get the same semver string as if downloading it from its 
git repo, and not succeeding. Any pointer?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/402525ef-f253-4671-8141-c2e6d09c8394n%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[pierre . curto]

> I did not add it since it was not the original question ^^
> But why can't we have the check and a switch?
>
>
Definitely can. Just didnt see it. My response was somewhat tangential to 
your question, sry. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b3bebee1-8fd3-4c61-ba09-9150f51f6767%40googlegroups.com.

[go-nuts] Re: stringer command and generated String() function

[pierre . curto]

The const/slice implementation should be faster as Jan said.

Note that there is also a blank function that fails at compile time if 
items have been added or changed and stringer has not been rerun since.
The const/slice implementation allows for that (useful!) check.


Le mardi 18 février 2020 07:42:41 UTC+1, Vincent Blanchon a écrit :
>
> Hello,
>
> I was wondering why the stringer command has been implemented that way:
>
> const _Pill_name = "PlaceboAspirinIbuprofen"
>
> var _Pill_index = [...]uint8{0, 7, 14, 23}
>
> func (i Pill) String() string {
>if i < 0 || i >= Pill(len(_Pill_index)-1) {
>   return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>}
>return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
> }
>
>
>
> When it could be simpler and faster with a simple enum:
>
> func (i Pill) String() string {
>switch i {
>case 0: return "Placebo"
>case 1: return "Aspirin"
>case 2: return "Ibuprofen"
>case 3: return "Paracetamol"
>default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>}
> }
>
>
> After running a benchmark with a higher number of values (20), the enum is 
> always faster. I also was surprised to see the binary is not bigger (maybe 
> it will be with more values).
>
> Does someone know what advantages the current design brings?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bff0982a-a80b-4153-b316-1576f65700c5%40googlegroups.com.

[go-nuts] map memory usage

[pierre . curto]

Hello,

Is there a better way to estimate the memory usage of a map, other than the 
following:
https://play.golang.org/p/MLSd84CJB3R

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d4a7a9fc-f303-4fbc-9b80-d58486e9a78d%40googlegroups.com.

[go-nuts] Re: Convert a charAtIndex of string to ASCII equivalent int value

[pierre . curto]

You can do something like this: https://play.golang.org/p/J7-N8_UDlL8

Le samedi 21 décembre 2019 17:23:28 UTC+1, Amarjeet Anand a écrit :
>
> Hi
> I have a set of strings(ASCII), that i want to assign to a string array(of 
> cap 128).
> The position of the string in the array is decided by the ASCII value of 
> the first char of the string.
> Like...
>
> strArr := [128]string{}
> strA := "A string"
> strB := "B string"
>
> strArr[65] = strA // since strA started with 'A' & ASCII('A') = 65
> strArr[66] = strB // since strB started with 'B' & ASCII('B') = 66
>
>
> There is one solution of using utf8.DecodeRuneInString, like ...
>
> r, _ := utf8.DecodeRuneInString(strA)
> strArr[r] = strA
>
>
> *Is it possible to time optimise this solution?*
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9db91410-3dbd-4514-a742-4da6deec9918%40googlegroups.com.

[go-nuts] Re: Workaround for missing RWMutex.Try*Lock()

[pierre . curto]

This may be of relevance to you:
https://pkg.go.dev/gvisor.dev/gvisor/pkg/tmutex?tab=doc


Le mercredi 4 décembre 2019 01:21:41 UTC+1, Liam a écrit :
>
> I have a problem that is trivially solved via
>
> door sync.RWMutex
>
> func Reader() T {
>if !door.TryRLock() { // missing in stdlib :-(
>   return busy
>}
>defer door.RUnlock()
>...
> }
>
> func Writer() {
>door.Lock()
>defer door.Unlock()
>...
> }
>
> How does one achieve this in 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/94c7a670-0a71-432a-aa19-035e1f4c9648%40googlegroups.com.

[go-nuts] Re: On the topic of try() and errors

[pierre . curto]

Interesting reasoning Michael...

Le mercredi 10 juillet 2019 01:46:03 UTC+2, Michael Jones a écrit :
>
> In the hope of elevating the discussion of late, I've made a little speech 
> as one might do at a lunchtime discussion with students or colleagues. 
> Maybe this will make sense to some kindred spirits here...
>
> Thoughts about facilitating error handling in Go(), and the try() proposal 
> in particular, have inspired a great deal of thought and sharing, with 
> heated disapproval by some and, it seems, general approval by many. In a 
> sense this is all premature--the proposal is a test and the good/bad 
> judgement will come over time.
>
> One aspect of the topic that seems to cause alarms is the fact it looks 
> like and in some ways acts like error-related try() features in C, C++, C#, 
> Java, JavaScript, and SQL. This invites presumption of harm through 
> similarity. The goal here is to offer *an entirely different way to think 
> about the issue*. In this alternate view, some aspects are more readily 
> understood and extensions and refinements more inviting. So, from here out, 
> it is not about errors.
>
> In 1969, C. A. R. Hoare, Mr. Quicksort and the father of the ideas in Go's 
> channels, was inspired to seek a logical, mathematical basis for computer 
> programming. He, Nicholas Wirth, Ole-Johan Dahl, and Edsger Dijkstra were 
> marching down this path and they all realized that *guarded computation* 
> was important; that statements of provable truth are the basis of rigor.
>
> [image: assert.002.jpeg]
> In my Fig. 1 here, you can see the problem, the result of math.Sqrt() is 
> valid or invalid depending on the status of x; x in the domain of 
> non-negative real numbers means Sqrt is good and x out of that domain means 
> the opposite. 
>
> As a starting point, Hoare and the others embraced AJT's call for 
> *assertions*, such as is shown in Fig 2. as is typical now and then. 
> Let's call it an *assertion statement*. (Hoare actually proposed a 
> keyword version, "assert ;" that would return with 
> prejudice if the bool was false.)
>
> We all know this. But, are other kinds of assertions interesting, beyond 
> statements? Here are two others, the *assertion expression* and the 
> *assertion 
> assignment,* along with Alan Turing's original 1949 appeal for 
> assertions: 
>
> [image: assert.003.jpeg]
> What I've shown here is not something I'm aware of being implemented 
> before, but both Fig. 3 and 4 show consistent specializations of assertion 
> statement to substatements; in the one case, to a function's arguments and 
> in the other, to the values being assigned. If we had these inline 
> assertions, we could call functions with range checking clear, local, and 
> concise, and assign return values with stated conditions known to have been 
> proven. To quote Turing, "...from which the correctness of the whole 
> program easily follows."
>
> There is a subtle shift here, from asserting that x>=0 which is specific, 
> to insisting that Sqrt() has not complained about a domain error, which is 
> specific in meaning but omits specifying what that range might be. 
> (AssertDomain(math.Log(x)) would have the same meaning but a different 
> domain.)
>
> Perhaps Figure 4 looks familiar to you. Compare to Fig. 5...
>
> [image: assert.004.jpeg]
> ...as you can see, we've come to the great debate, but along a different 
> path. If you can pretend that "try" did not have a decade of bitter 
> meanings from other languages and common misuse, then you can see try as 
> nothing more than an assertion assignment. In this view, disjoint from the 
> error type, we can also see that other "same meaning different detail" uses 
> could make sense, just like the Domain assertion of Fig 4. If I have test 
> for error value != nil, then why not test for non-error pointer value == 
> nil as in Fig. 6. Not only does this seem useful and thematically 
> consistent, it happens to already be in Go!
>
> Where you ask? Where has this nil-pointer-try been hiding? Right here:
> [image: assert.005.jpeg]
> So now we reach my destination: Go's "must" is an assertion at its heart. 
> That your program is executing means "it must have or else we'd not be 
> here." It is an extreme, fatal must. Assertions considered previously range 
> from the fatal-must of the assertion statement to the return-with-error of 
> the assertion assignment.
>
> Should "try" be "must"? Should musts take an optional error argument that 
> defines what is returned? Is there a beautiful way to unify compile-time 
> must, init-time must, and runtime must? I'll not comment as my goal here is 
> not to propose, rather to encourage each of us to offer insights that 
> convey the wisdom of those who came before us as well as learnings from our 
> own experience.
>
> Michael
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe 

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[pierre . curto]

Indeed.

I think many people like the proposal but are not vocal about it. It is not 
perfect but it *does *bring value to the table if you read the proposal in 
its entirety and think about how you would use/could use it in a real life 
scenario.

I do *decorate *errors a lot, I do care about the *control flow* (I have 
been along time user of *defer *for error handling and find it not magical 
or ugly but fitting beautifully with the language), which are the main 
topics people are complaining about... And I think it actually works fine 
in those situations.

In fact, the try() approach has started growing on me as I write code now, 
I feel it would help in quite a few situations and simplify, not in a 
drastic way, but subtle and valuable one.

My 2c.

Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :

> I for one like the try proposal. It removes much of my gripes with the 
> verbosity of error handling.
>
> I think that it will become more readable than explicit error handling 
> quite fast. Note that it is still explicit, if you don't use the try 
> notation the error can be handled as it is now or ignored as it sometimes 
> is now.
>
> I have a feeling that there is a quite large "silent majority" that pretty 
> much agrees with me.
>
> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov  > wrote:
>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/473c9666-aef5-4d25-a2fe-5832ab76eb8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: io.Copy and Writer

[pierre . curto]

Hello,

Indeed, you need to flush the bufio.Writer for the remaining data to be 
sent accross.
Usually though, you do not need to buffer the input or output at all.
In which case, the code is straight forward:

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

If you do need to buffer though, I would do something along the lines of:
https://play.golang.org/p/e5xFL_nUdp5

or even

https://play.golang.org/p/3I1J_4zOKL4

I would stringly encourage you to *use* interfaces such as the io.Reader 
and io.Writer and *not* file descriptors. You will find that they are very 
easy to work with and make your code much easier to read, test and maintain 
in the long run.


HTH

Le mardi 21 mai 2019 09:03:32 UTC+2, Subramanian Sridharan a écrit :
>
> I had an issue where io.Copy did not copy the entire file contents.
>
> My code was something like:
>
> fReader := bufio.NewReader(sourcef)
> fWriter := bufio.NewWriter(destf)
> n, err := io.Copy(fWriter, fReader)
> if err != nil {
> fmt.Println("Error while copying:", err)
> return
> }
> fmt.Println("Copied", n, "bytes.")
>
> After searching a bit, I learnt that Writers should be flushed to ensure 
> that all of their contents has been written to the destination.
>
> I modified my code as:
>
> fReader := bufio.NewReader(sourcef)
> fWriter := bufio.NewWriter(destf)
> n, err := io.Copy(fWriter, fReader)
> if err != nil {
> fmt.Println("Error while copying:", err)
> return
> }
>
> // Flush the writer to write remaining bytes in the buffer.
> err = fWriter.Flush()
> if err != nil {
> fmt.Println("Error while flushing writer:", err)
> } else {
> fmt.Println("Flushed writer.")
> }
> fmt.Println("Copied", n, "bytes.")
>
> Now the entire file contents were copied successfully.
>
> But I have a couple questions in mind:
>
>1. On searching, I found out in Java, the writers are automatically 
>flushed when the corresponding file descriptor is closed. Even though I 
> had 
>deferred close statements on my source and destination files, the writer 
>was not flushed. Why is the behaviour not present in Go?
>2. I saw other usages of io.Copy in my organization's codebase and 
>they have used file descriptors directly in place of readers and writers. 
>Hence no need of flushing. Is there any particular reason why I should use 
>readers and writers and not the file descriptors directly?
>
> TIA.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/83a24007-df16-489d-b3cb-5fdd3f14bacd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] bool in go/ast.filterParamList

[pierre . curto]

Got it, thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/76ee9459-284e-40f5-93b6-2d57a4eaadea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] bool in go/ast.filterParamList

[pierre . curto]

Hello,

While studying the go/ast package, I stumbled upon the following: 
https://golang.org/src/go/ast/filter.go#L140


Unless I am missing something, shouldnt this just be: 
https://play.golang.org/p/uQJ3XtEcgWE ?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d452c063-bbe4-4099-82e6-dc26f985af30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Merging package files

[pierre . curto]

Hello,

I was wondering if there was an easy way to merge package files into a 
single one, like the bundle 
tool does but as a 
library.
My goal is to take a package, transform some of its types (change their 
name) and output a file which contains all the package code and the 
modified types.
This is to enable some kind of code generator from a well defined and 
tested package but using different types for the input.

I have also looked at go/ast.MergePackageFiles 
, astutil 
 and the new packages 
package but cannot find 
an easy way of doing so.

Any help appreciated!

Pierre

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/23b95d8d-8ecf-4f33-a643-c89c369731e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: module exports

[pierre . curto]

If you want to hide packages that you use only for your main package, then 
put them under the internal directory within your main package.
That way, they are still available from your main package (or any sub 
package) but not outside of it, including in godoc.

i.e.
  top/
 top.go
 internal/sub1
   sub1.go
 internal/sub2
  sub2.go

packages "sub1" and "sub2" are accessible from package "top" but not 
outside.
package "sub1" can access package "sub2" and vice-versa.

Le jeudi 8 novembre 2018 13:33:44 UTC+1, Glyn Normington a écrit :
>
> Packages are handy for hiding implementation details of a given package 
> from packages that use the given package. However, introducing a package 
> currently has a downside: the package's externals become visible outside 
> the module containing the package. If breaking changes are made to the 
> package, its module's major version must be bumped. It would be nice to 
> avoid this when a package is really intended to be an implementation detail 
> of a module. If the package could be *hidden* from users of the module, 
> breaking changes could then be made to the package without necessarily 
> impacting other modules.
>
> I'd be grateful for any pointers to previous discussions of this topic. 
> There was no mention of similar features being deemed out of scope in the 
> modules 
> wiki .
>

-- 
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] golang maps; using slice as a key

[pierre . curto]

You keep the reference of the loop index that points at the last array.
Either make a copy of it or use a slice of arrays.

https://play.golang.org/p/WcOHQ_wIKjx
https://play.golang.org/p/CToFC9w88M7


Le mercredi 23 mai 2018 09:59:53 UTC+2, Sankar a écrit :
>
> I extracted the confusing part alone, when appending to an array, the 
> items are different than the resultant array into a separate go program. 
>
> The Playground URL is: https://play.golang.org/p/BJM0H_rYNdb 
>
> If someone can explain the output I would be thankful. It feels like a bug 
> to me, but I am sure that I am only misunderstanding and it may not be a 
> bug.
>
> Thanks.
>
>
> 2018-05-23 11:45 GMT+05:30 Sankar P :
>
>> Use an array instead of a slice. An array has a fixed size and can be 
>>> used as a key to a map
>>>
>>> https://play.golang.org/p/xxxmrwpx08A
>>>
>>
>> This seem to not work. The arr is returning only duplicate elements in 
>> your playground url. 
>>
>> For example:
>>
>>var arr [][]int
>> for mem := range m {
>> fmt.Println("Appending: ", mem[:])
>> arr = append(arr, mem[:])
>> }
>> fmt.Println("Final arr is:", arr)
>>
>> the output is:
>>
>> Appending:  [-1 0 1]
>> Appending:  [-1 -1 2]
>> Final arr is: [[-1 -1 2] [-1 -1 2]]
>>
>> I am not really able to understand why the above code works so. The 
>> "Appending" and the "Final arr" statements have different values.
>>  
>> -- 
>> Sankar P
>> http://psankar.blogspot.com 
>>
>
>
>
> -- 
> Sankar P
> http://psankar.blogspot.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] Re: Parsing a CSV column with partially double-quotes in it

[pierre . curto]

Because this is invalid csv.
Should be:
This\t"""is"" no"\tfun

If you still need to parse it, then write your own parser that handles it, 
for instance using a bufio.Reader.

Le jeudi 28 septembre 2017 22:56:27 UTC+2, Lantos István a écrit :
>
>
> I want to parse the following CSV structure. The column separators are 
> tabs:
>
> *package main*
>
> *import (*
> *"encoding/csv"*
> *"fmt"*
> *"log"*
> *"strings"*
> *)*
>
> *func main() {*
> *in := `This"is" notfun`*
> *r := csv.NewReader(strings.NewReader(in))*
> *r.Comma = '\t'*
>
> *records, err := r.ReadAll()*
> *if err != nil {*
> *log.Fatal(err)*
> *}*
>
> *fmt.Print(records)*
> *}*
>
> Google Playground 
>
> There is a tab after *This* and before *fun*. Between *"is"* and* not* 
> there is only a space. This should be one column. I  setted the column 
> separator with* r.Comma ="\t"*, but for some reason I'm getting the 
> following error:
>
> *line 1, column 8: extraneous " in field*
>
> Is there a way to achieve what I want?
>
>

-- 
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: Struct overloading method issue

[pierre . curto]

Maybe I misunderstood your need, but I would just call the A method 
directly like below.


type A struct{}

func (a *A) private() {}
func (a *A) Public() {
   a.private()
}

type B struct {A}

func (b *B) private() {
   b.A.private()
}

bi := B{}
b.Public() //calls the A.Private



Le vendredi 1 septembre 2017 16:50:52 UTC+2, BeaT Adrian a écrit :
>
> Hello, I ran into a strange scenario and I wanted to know if there is a 
> better solution for it
>
> type A struct{}
>
> func (a *A) private() {}
> func (a *A) Public() {
>a.private()
> }
>
> type B struct {A}
>
> func (b *B) private() {}
>
> bi := B{}
> b.Public() //calls the A.Private
>
>
>
> I just want to rewrite a small part of the algorithm.
> As a workaround I used composition, but in a weird way
> type A struct {
>  private
> }
>
> func (a *A) Public() {
>if a.private == nil {
>  //set private for A
>}
>a.private
> }
> type B struct {A}
> func (b *B) Public() {
>  if b.private == nil {
>   //set private for B
>  }
> }
>
>  
>
> Other solutions I tried were not effective (how to detect in inner A 
> function that it's a B now, and should use other algorithm).
>
> Thanks!
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: API patterns for a function with a single argument that is rarely needed

[pierre . curto]

Hello,

I personally like the variadic version, which is very well described here 

 and here 
.


Le vendredi 7 juillet 2017 17:18:14 UTC+2, Sam Whited a écrit :
>
> Hi all, 
>
> I have an API that I'm not satisfied with and wanted to see what 
> others do. I have a function in my API, the details don't really 
> matter so let's call it Foo and say it returns type Bar (the return 
> type we can't mess with): 
>
> Foo() Bar 
>
> Most of the time we have all the information we need to compute Foo() 
> and return Bar. However, on rare occasions, the thing Foo is doing 
> does not have enough information and the users application needs to 
> provide logic for computing that info, or fetching it from a database, 
> etc. So I need to let the user provide some logic for getting that 
> info (let's assume it's a string): 
>
> Foo(f func() (string, error)) Bar 
>
> Normally this would be a fine, simple API. However, f is almost never 
> needed. This means that  of the time when they 
> actually call Foo (let's say it's in the baz package), they'll be 
> writing: 
>
> bar := baz.Foo(nil) 
>
> This isn't terrible; but it doesn't feel great to introduce a random 
> nil with no information about what it is into the users code just so 
> that a fraction of the time they can put a callback there. 
>
> Other atlernatives might be to use a variadic function and take 
> multiple callback funcs (so that having one at all is optional): 
>
> Foo(f ...func() (string, error)) Bar 
>
> Now the user can write: 
>
> bar := baz.Foo() 
> bar := baz.Foo(func() (string, error) {…}) 
>
> That feels dirty because we appear to be telling the user that 
> multiple callbacks are acceptable by encoding that into the function 
> signature (even though it doesn't make sense and only the first one 
> would ever be used). 
>
> We might also provide a Foo() function and a FooCallback(f func() 
> (string, error)) function, but this doesn't really provide us any 
> benefit over saving us typing three characters most of the time and 
> means we have a bigger API surface to keep track of (and it just looks 
> ugly in the docs, there are other Foo like functions and none of them 
> will have an alternative implementation; it also makes it easier for 
> the user to mix them up and use the wrong one when info is or is not 
> needed, etc.) 
>
> Thoughts? Is requiring the (nil) argument 90% of the time not so bad? 
> Is there an obvious benefit to doing it another way I'm not noticing, 
> or another pattern I'm ignoring? It's so rare that the callback is 
> needed (but it will be needed sometimes and there's nothing I can do 
> about that; so I can't just get rid of it entirely), that all the 
> options here just feel poor. 
>
> Thanks, 
> 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.

[go-nuts] Re: golang regex question

[pierre . curto]

Hello,

Try something like this:
https://play.golang.org/p/xSEX1CAcQE

Le vendredi 2 juin 2017 16:26:24 UTC+2, Sankar a écrit :
>
> I have a go string
>
> dbConnStr1 := "user=someone password=something host=superduperhost 
> sslmode=something"
>
> the k=v pair in this string may be in any order, for example:
>
> dbConnStr2 := "host=superduperhost user=someone password=something"
>
>
> Notice the difference in the key order and also the missing "sslmode" key 
> in the second instance.
>
> Also, it is possible that instead of whitespace, the individual k,v pairs 
> may be separated by newline too.
>
> It is safe to assume that the values may not contain '=' as a content.
>
> Given all these constraints:
>
> Now I want to extract the unique keys and their corresponding values from 
> the given string, using regexp. If it will help, I can give a list of all 
> the possible keys that may come (username, password, host, sslmode), but I 
> would ideally like a regex solution that works with any list of keys and 
> values.
>
> How to do this ? I understand that it may be possible with 
> regexp.FindStringSubmatch but not able to wrap my head around writing the 
> regexp.
>
> P.s: I know that instead of using regexp, I can write strings.Split call 
> and do it normally, but I want a regexp based solution.
>
> Any help ?
>
> Thanks.
>
> PS: I have asked the same question in stackoverflow too and if you want to 
> answer there, please see: 
> https://stackoverflow.com/questions/44321199/golang-extract-unique-key-value-from-a-key-value-pair-string-using-regex
>
>

-- 
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: Concurrent access to map

[pierre . curto]

Hello,

Once you have written out your values to the map, you can read them 
concurrently and safely. If you need to write again to it (insert or 
delete), then you must ensure it is done safely.

Note that, from what I can see in tip, in 1.9 there will be a safe 
concurrent map: https://tip.golang.org/pkg/sync/#Map.

Le mardi 16 mai 2017 07:10:56 UTC+2, Yan Tang a écrit :
>
> Hi,
>
> I am aware of golang map is not safe for concurrent access, especially 
> when there is at least one writer.
>
> However, I want to know that if the map has been pre-populated, and 
> different coroutines access (read/write) different key/value pair, is it 
> safe to do so?  There is no deletion or adding keys after the 
> initialization.
>
> I think it should be safe (having been doing this in C++ quite frequently) 
> but just want to double check.  Thanks.
>
> Yan
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why a []interface{} containing 2 different interface should use function like this?

[pierre . curto]

Since S1 and S2 satisfy the Stringl interface just use that for your slice 
type and you get something like (note that you do not need to specify the 
variables types if you initialize them like you did).

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

Le vendredi 5 mai 2017 13:35:42 UTC+2, eZio Pan a écrit :
>
> Hi, I'm a newbie in Golang. I get stuck in a problem that I can't 
> understand why. I wish someone could help me out. Thanks!
>
> There are 2 struct type *S1* and *S2*. Both of them implement interface 
> type *StringI*.
> I write a function called *run* which use *StringI* interface as input, 
> and run all method *StringI* signatured.
>
> Then I write a test file, in which I declare a **S1* variable as *s1*, 
> and a **S2* variable as *s2*.
> I create a slice *[]interface{}{s1,s2}*, the I use for loop to get item 
> in it.
>
> But when I use *run*(*LoopedItem*), I got an error 
>
> *cannot use item (type interface {}) as type StringI in argument to run*
>
> And I use fmt.Printf("%T", *LoopedItem*), Golang does print right type -- 
> **S1* and **S2*
>
> Then I try type switch
>
> switch *LoopedItem*.(type){
> case *S1:
> run(*LoopedItem*.(*S1))
> case *S2:
> run(*LoopedItem*.(*S2))
> }
>
> Everything goes on well.
>
>
> *I wonder why I can't use *LoopedItem* (as StringI interface) as run 
> function's argument,but *LoopedItem*.(*TypePointer*) (as struct type 
> pointer) to the run function.*
>
>
>
> Here is the source code
>
>
>  firstInter.go 
>
> /*my first interface*/
> package firstInter
>
> import (
> "fmt"
> "strconv"
> )
>
> // interface with Get() and Push() method
> type StringI interface {
> Get() string
> Push(string)
> String() string
> }
>
> // type S1, store a int value
> type S1 struct {
> I int
> }
>
> // S1's Get method 
> // return the int value it stored
> func (s *S1) Get() string {
> return strconv.Itoa(s.I)
> }
>
> // S1's Push method
> // put new value into S1
> func (s *S1) Push(a string) {
> num, err := strconv.Atoi(a)
> if err == nil {
> s.I = num
> }
> }
>
> // S1's String method
> // for fmt
> func (s *S1) String() string {
> return strconv.Itoa(s.I)
> }
>
> // type S2, store a string value
> type S2 struct {
> S string
> }
>
> // S2's Get method 
> // return the string value it stored
> func (s *S2) Get() string {
> return s.S
> }
>
> // S2's Push method
> // put new value into S2
> func (s *S2) Push(a string) {
> s.S = a
> }
>
> // S2's String method
> // for fmt
> func (s *S2) String() string {
> return s.S
> }
>
> // function to run every method
> // StringI interface signatured
> func run(tI StringI) {
> fmt.Printf("%v\n", tI.Get())
> tI.Push("3")
> fmt.Printf("%v\n", tI.Get())
> }
>
>
>  firstInter_test.go 
>
> // firstInter package Unit Testing
> package firstInter
>
> import (
> //"fmt"
> )
>
> var tI StringI
>
> var s1 *S1 = {1}
> var s2 *S2 = {"???"}
> var l []interface{} = []interface{}{s1, s2}
>
> func Example_InterFace() {
> for _, item := range l {
> // something wrong here
> // run(item)
> // fmt.Printf("%T\n", item)
> switch item.(type) {
> case *S1:
> run(item.(*S1))
> case *S2:
> run(item.(*S2))
> }
> }
> // Output:
> // 1
> // 3
> // ???
> // 3
> }
>
>

-- 
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: bug or not?

[pierre . curto]

RHS = right hand side
LHS = left hand side

Le mercredi 3 mai 2017 14:53:40 UTC+2, mhh...@gmail.com a écrit :
>
> similarly, it is possible to rewrite len, or a package id. 
>
> I got caught some times about that, 
> since then i take care about that.
>
> but yeah, feels weird.
>
> btw, what means RHS / LHS in ast package and in the comment by cznic ?
> many times i read it and wonder..
>
> On Wednesday, May 3, 2017 at 2:32:47 PM UTC+2, T L wrote:
>>
>> https://github.com/golang/go/issues/20219
>>
>>
>>

-- 
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: encoding/json: unexpected behaviour when unmarshalling into struct with interface{} field

[pierre . curto]

Hello,

My guess:
If you dont pass in a pointer, then you pass a value.
What would be the point of updating the value that you will never see and 
that will get discarded?
Hence it returns a map that provides the unmarshaled values so at least you 
have something to work with.

Le mardi 2 mai 2017 20:59:52 UTC+2, Brian Stengaard a écrit :
>
> Hey Gophers,
>
> When unmarshalling JSON into a struct with a blank interface (interface{}) 
> I get a surprising result:
>
> If I set the field to a pointer to a T value before unmarshalling, the 
> data is filled out on the T value as expected. (See I2 in the playground 
> example.)
>
> If I set the field to a T value before unmarshalling, field will be set to 
> a map[string]interface{} when returning, I was expecting a T value. 
>
> Since the field is not nil I would expect json.Unmarshal to just fill in 
> the fields on the data structure provided, not override the field value. 
>
> What am I missing? 
>
> Example: https://play.golang.org/p/O-55nj0h44 why is I1 a 
> map[string]interface{} when I already gave it a T value?
>
>

-- 
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: Oracle db and panics on interrupt

[pierre . curto]

Hello,

Thanks a lot indeed, I did not know about those.

I still get crashes on OSX besides the variables being read by the OCI libs 
(traces shows they are).

The other thing is that when this happens, the process goes into an 
infinite loop spitting "fatal: morestack on g0" for ever, and kill -9 is 
the only to put it out of misery. Is *that* expected although I know that 
custom signal handlers break cgo? Shouldnt it just panic and exit?


Le jeudi 27 avril 2017 21:07:35 UTC+2, Tamás Gulácsi a écrit :
>
>
> 2017. április 27., csütörtök 18:18:19 UTC+2 időpontban Didier Spezia a 
> következőt írta:
>>
>>
>> I'm not sure it can help with the problem, but starting with Oracle 11, 
>> OCI installs some custom signal handlers (even catching segmentation 
>> faults).
>> They can be deactivated by setting options in the sqlnet.ora file.
>> Here, we run all our OCI clients with:
>>
>> DIAG_SIGHANDLER_ENABLED=FALSE
>> DIAG_ADR_ENABLED=FALSE
>> DIAG_DDE_ENABLED=FALSE
>>
>> Regards,
>> Didier.
>>
>>>
>>>
> Thanks a lot, Didier! 
>

-- 
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] Oracle db and panics on interrupt

[pierre . curto]

Hello,

I am unsure where to log the following issue:
whenever I send an interrupt signal to a go process running an Oracle 
query, it panics with either "fatal: morestack on g0" or "fatal error: 
runtime: stack split at bad time".

A sample code reproducing the issue is here 
. Of course an Oracle instance and 
libs are required for it to work.

Should it be reported to the maintainers of the Oracle package or the Go 
team?
It seems to me it should be the later, but I want to make sure.

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

[pierre . curto]

This looks really interesting...

I also saw a similar idea with a different 
approach: https://github.com/elliotchance/c2go.

Le vendredi 21 avril 2017 16:38:38 UTC+2, Andy Balholm a écrit :
>
> As near as I can tell, this is an intermediate step in a project whose 
> ultimate goal is to compile sqlite into Go—asm.go (a style like asm.js), 
> apparently. 
>
> Andy

-- 
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: How to set value to empty interface{}

[pierre . curto]

In Go, everything is passed by value, including interfaces (empty or not).
A quick overview 
at http://goinbigdata.com/golang-pass-by-pointer-vs-pass-by-value/.

So, you cannot change the value pointed to by an interface unless you 
"unbox" it: https://play.golang.org/p/uzccweBdzV

Further reading:
to understand interfaces inner workings: 
https://research.swtch.com/interfaces, even though I think that the 
interface value is now always a pointer.


Le mardi 11 avril 2017 16:15:38 UTC+2, Th3x0d3r a écrit :
>
> It works this way, but need to use 
> the GetMessage interface value 
>

-- 
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: How to set value to empty interface{}

[pierre . curto]

Either pass around the pointer to your struct or use a dedicated interface 
to alter the struct contents.
Examples of each here  and there 
.

Le mardi 11 avril 2017 15:22:41 UTC+2, Th3x0d3r a écrit :
>
> Hey there !
>
> How can i set the value of an interface{} parameter from other interface{} 
> source
>
> Playground : https://play.golang.org/p/utwO2Ru4Eq
>
> Output expected:
>
> Val 1: &{XML}
> Val 2: &{XML}
>
>
> Thanks 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Best way to save users input data that could be used later?

[pierre . curto]

Hello,

You keep appending json objects to your file, which produces invalid json 
after the first item.
You either need to produce valid json, for instance by putting your items 
into an array, or use a streaming json parser that parses items 
individually.
I have changed your example to perform the last option and here it 
is: https://play.golang.org/p/n6fWA8bTAb.

Note that you should probably return errors instead of bailing out right 
away, but it all depends on what you are trying to do.

P.

Le lundi 20 mars 2017 23:27:15 UTC+1, Paulius Daubaris a écrit :
>
> Hello, I am writing this application, where I can store some reminders for 
> myself in CLI to not forget something important.
>
> My question is how can I save my input data or lets say what's the best 
> way to do so? I've tried JSON, but it didnt work out, primarily because I 
> cant really figure it out. Anyhow if JSON is the way to go, I've been stuck 
> and it got me really frustrated.
>
> Example:
>
> The function which creates new reminder:
>
> func newReminder() {
> checkFile() //Simple check if file is not in the directory it creates 
> one
>
> var text string
> date := time.Now()
> dateString := date.String()
> file, err := os.OpenFile("rem.json", os.O_RDWR|os.O_APPEND, 
> os.ModePerm)
>
> if err != nil {
> log.Fatal(err)
> }
>
> fmt.Print("Description: ")
>
> scanner := bufio.NewScanner(os.Stdin)
> if ok := scanner.Scan(); ok {
> text = scanner.Text()
> }
>
> reminder := {dateString[:19], text}
> newReminder, _ := json.Marshal()
>
> file.Write(newReminder)
> file.Close()
> }
>
> Here everything is working fine. I execute it with ./main -n, write new 
> reminder, display it and it goes well. Although when I add another reminder 
> and try to display it i get an error: invalid character '{' after 
> top-level value
> Its because when I cat out my json file it looks like this :
>
> {"Date":"2017-03-20 10:46:48","Description":"new"}{"Date":"2017-03-20 
> 10:46:51","Description":"new .go"}
>
> So basically it has no root node. So again, is there a way to wrap it up? If 
> the code is confusing here's the whole. https://play.golang.org/p/d0mlZw3ZH-
>
> Thanks in advance.
>  
>
>
>
>

-- 
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: Aren't package declarations (and per file imports) redundant?

[pierre . curto]

Besides what has been said, another use for the package declaration is 
being able to declare "main" programs that are ignored at build time but 
used by go generate within the package.

A good example of this is in the gob package:
https://golang.org/src/encoding/gob/dec_helpers.go is generated by 
running https://golang.org/src/encoding/gob/decgen.go invoked by go 
generate in https://golang.org/src/encoding/gob/decode.go.


Le samedi 18 mars 2017 12:49:57 UTC+1, Sunder Rajan Swaminathan a écrit :
>
> Before anyone flames, I love Go! There. Ok, now to the issue at hand -- 
>
> The toolchain already seems to understand the directory layout then why 
> bother littering the sources with package declaration? Also is there a 
> point to specifying imports at a file level? I mean doesn't the linker 
> bring in symbols at a package level anyway? My reason for brining this up 
> is I'm trying to generate a codebase using a custom built specification and 
> having to constantly tweak the imports and packages (in over 200 files) are 
> getting in my way of a smooth development. I'm sure others have had the 
> same problem.
>
> In the spirit of brining a solution and not just a problem, how about the 
> toolchain assume a package to be "main" if there's a main function therein. 
> Imports could be specified at the package level like in D or Rust in a 
> separate file.
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Variadic parameters to SQL-queries, specifically gopkg.in/rana/ora.V*

[pierre . curto]

Yes you can, use append:
https://golang.org/ref/spec#Appending_and_copying_slices

Le vendredi 24 février 2017 17:09:12 UTC+1, Trond Kandal a écrit :
>
> Thank You very much, Sir!
>
> That did the trick!
> I am not used to the small and subtle tricks of Go yet.
>
> Is there any way I can append parameters to the variable as I go, before
> passing it to the query?
>

-- 
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: Variadic parameters to SQL-queries, specifically gopkg.in/rana/ora.V*

[pierre . curto]

Do a:

rst, err := stmt.Qry(params...)



The 3 dots will expand the slice for the variadic function.


Le vendredi 24 février 2017 16:05:42 UTC+1, Trond Kandal a écrit :
>
> Thank Your for your answer, Sir!
>
> Hmmm...
> I do not seem to get it working
>
> sqlQry := "SELECT * FROM TIA_EMNEINFO WHERE EMNEKODE = :1"
>
> stmt, err := ses.Prep(sqlQuery,
> ora.OraI64, ora.OraS, ora.OraS, ora.OraS, ora.OraS, ora.OraS, ora.OraI64,
> ora.OraS, ora.OraI64, ora.L, ora.L, ora.OraI64)
>
> defer stmt.Close()
>
> if err != nil {
>
> ...
>
> }
>
> params = []interface{}{"BI101714"}
> rst, err := stmt.Qry(params)
>
> ...
>
>
> (The parameter is supposed to be a string)
>
>
> Then I get:
>
> error = Stmt.qryC Stmt.bind Invalid bind parameter. ([]interface{}) 
> ([BI101714]).
>
>
> By the way, how do I extend the params with more parameters as I
> collect the GET-parameters?
>
>

-- 
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] Reading an .ini file

[pierre . curto]

Hello,

When this thread came up I was working on an ini formatting tool, similar 
to (but way simpler than) gofmt, which required parsing and manipulating 
the contents of an ini file. As you have found out, there are a bunch of 
packages already doing that, but not in the spirit of simplicity that Go 
conveys, as well as what I wanted to do with comments for ini sections and 
keys.

So I went to write my own, and ended up 
with https://github.com/pierrec/go-ini, which solves all the pain points I 
had.

Feel free to provide any feedback!

Le mardi 17 janvier 2017 09:42:42 UTC+1, Konstantin Khomoutov a écrit :
>
> On Sat, 14 Jan 2017 09:43:54 -0800 (PST) 
> Nathan Kerr  wrote: 
>
> > Using a newer package might help. 
> > 
> > https://github.com/go-ini/ini looks to be under active development 
> > and is written by the author of https://github.com/Unknwon/goconfig, 
> > which also reads ini files but is now in bug fix only mode. 
>
> This library is a classical case of overengeenering beyold all 
> repair/recognition (OEBAR, if you want).  Like, "OK, let's cram 
> everything I learned about programming in Go so far into this library 
> and try to make it fly" mentality.  Check the dreaded BlockMode 
> variable for just one glaring example.  I think such libraries 
> represent the clear antithesis to the very ideas which make Go what it 
> is, and should be avoided. 
>

-- 
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: Idiomatic way to reference custom error codes

[pierre . curto]

Le jeudi 26 janvier 2017 07:42:55 UTC+1, JohnGB a écrit :
>
> Thanks Pierre, that looks like a simple and quite clean implementation.  
> Although it's easier to use an iota for the numbering, does that open up 
> any issues with keeping the documentation up to date?  I know it's easier 
> to program and extend, but it's also less obvious when codes change.
>

It's up to you. If you expect the codes to change a lot, then just list 
them as constants.
 

>
> Is there a reason why you've used:
>
> var customHTTPErrorRegistry = map[errCode]customHTTPError{
> 1: {http.StatusOK, "OK"},
> }
>
> instead of say:
>
> var customHTTPErrorRegistry = map[errCode]customHTTPError{
> OK: {http.StatusOK, "OK"},
> }
>
>
No. The second option is better I think.
 

>
> On 25 January 2017 at 19:02,  wrote:
>
>> Maybe use a map along the lines of: https://play.golang.org/p/YDF4q6cTyX 
>> ?
>>
>> Le mercredi 25 janvier 2017 18:16:33 UTC+1, JohnGB a écrit :
>>>
>>> I have an HTTP API written in Go, and to give more fine grained 
>>> responses to the client app, we return our own error codes along with the 
>>> standard HTTP status codes  Along a similar line to what Twitter does 
>>> with its error codes 
>>> .  The correct 
>>> HTTP status code can always be determined from our internal error code, so 
>>> any HTTP handler that wants to return an error response, only has to call 
>>> our error response function, and pass in our custom error code, and from 
>>> that we can determine the error message and http response that we should 
>>> give in the HTTP response.  What I am not sure about, is the best way to 
>>> structure this.
>>>
>>> One option is to define our error codes as constants with iota.  
>>> Something like:
>>>
>>> const (
>>>   OK  int = iota + 1   
>>> 
>>>   ErrBadRequest   
>>>   ErrRecipientNotExist
>>>   ...
>>> )
>>>
>>> And then have some sort of switch lookup to return the HTTP response and 
>>> the error message to return.  Something like:
>>>
>>> func inspectStatusCode(errCode int) (httpStatus int, errorMsg string) {
>>>   switch errCode {
>>>   case OK:
>>> return http.StatusOK, "OK"
>>>   case ErrBadRequest:
>>> return http.StatusBadRequest, "Poorly formatted request"
>>>   case ErrRecipientNotExist:
>>> return http.StatusNotFound, "The entity does not exist"
>>>   ...
>>>   }
>>>   ...
>>> }
>>>
>>> This method allows me to not have to directly specify an int value for 
>>> each response.
>>>
>>> Alternatively I could define a struct that contains all of the data 
>>> directly, but with an explicit response code.  Something like:
>>>
>>> type response struct {
>>>   code int
>>>   message string
>>>   httpStatus int
>>> }
>>>
>>> And then have a large number of global variables to reference the 
>>> response.  Something like:
>>>
>>> var (
>>>   ErrBadRequest = errResp{
>>> code: 10,
>>> message: "Poorly formatted request",
>>> httpStatus: http.StatusBadRequest,
>>>   }
>>>   ...
>>> )
>>>
>>> Only here I don't like that I'm using global variables, rather than 
>>> constants, and I don't like that I have to specify each error code directly 
>>> (but then I'll have to do that in the documentation anyway).
>>>
>>> Is there a better way of handling this than one of these two methods?  
>>> Otherwise I'd love to get feedback on the two methods that I've described.
>>>
>>> -- 
>> 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/VzDfhN4GtIY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@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: Idiomatic way to reference custom error codes

[pierre . curto]

Maybe use a map along the lines of: https://play.golang.org/p/YDF4q6cTyX ?

Le mercredi 25 janvier 2017 18:16:33 UTC+1, JohnGB a écrit :
>
> I have an HTTP API written in Go, and to give more fine grained responses 
> to the client app, we return our own error codes along with the standard 
> HTTP status codes  Along a similar line to what Twitter does with its 
> error codes .  The 
> correct HTTP status code can always be determined from our internal error 
> code, so any HTTP handler that wants to return an error response, only has 
> to call our error response function, and pass in our custom error code, and 
> from that we can determine the error message and http response that we 
> should give in the HTTP response.  What I am not sure about, is the best 
> way to structure this.
>
> One option is to define our error codes as constants with iota.  Something 
> like:
>
> const (
>   OK  int = iota + 1 
>   
>   ErrBadRequest   
>   ErrRecipientNotExist
>   ...
> )
>
> And then have some sort of switch lookup to return the HTTP response and 
> the error message to return.  Something like:
>
> func inspectStatusCode(errCode int) (httpStatus int, errorMsg string) {
>   switch errCode {
>   case OK:
> return http.StatusOK, "OK"
>   case ErrBadRequest:
> return http.StatusBadRequest, "Poorly formatted request"
>   case ErrRecipientNotExist:
> return http.StatusNotFound, "The entity does not exist"
>   ...
>   }
>   ...
> }
>
> This method allows me to not have to directly specify an int value for 
> each response.
>
> Alternatively I could define a struct that contains all of the data 
> directly, but with an explicit response code.  Something like:
>
> type response struct {
>   code int
>   message string
>   httpStatus int
> }
>
> And then have a large number of global variables to reference the 
> response.  Something like:
>
> var (
>   ErrBadRequest = errResp{
> code: 10,
> message: "Poorly formatted request",
> httpStatus: http.StatusBadRequest,
>   }
>   ...
> )
>
> Only here I don't like that I'm using global variables, rather than 
> constants, and I don't like that I have to specify each error code directly 
> (but then I'll have to do that in the documentation anyway).
>
> Is there a better way of handling this than one of these two methods? 
>  Otherwise I'd love to get feedback on the two methods that I've described.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is src modified when concatenating slices with dst = append(dst, src[:i])

[pierre . curto]

Hello and welcome to Go!

It will all make sense after reading this:
https://blog.golang.org/go-slices-usage-and-internals

I leave you to find the solution once you have read the article :).

Hint:
It indeed has to do with the backing array of the slice.
In step1 you are creating a new slice for dst but it shares the same array 
as src.


Le dimanche 20 novembre 2016 06:56:18 UTC+1, Bogdan Katyński a écrit :
>
> Hello Group,
>
> I'm very new to GoLang and this is my first post to the group so first of 
> all hello all :)
>
> I just came across a strange thing which I'm failing to understand: 
> https://play.golang.org/p/BOCsJqIw63
>
> I don't understand why in Step2, the src slice is changed to [1 2 3 4 1 6 
> 7 8]
>
> I suppose it has something to do with the "underlying" array that is 
> backing both src and dst slices but why doesn't src change in Step1 and 
> Step3 only in Step2?
>
> For more context: I'm working on a naive solution to this task: 
> https://www.hackerrank.com/challenges/array-and-simple-queries
>
> All help appreciated,
> Bogdan
>
>

-- 
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: Exported singleton in vendor is initialized on every call

[pierre . curto]

Hello,

You shadow your DB global variable in the DB, err := gorm.Open() call.
Do something like this instead:
var err error
DB, err = gorm.Open()



Le lundi 14 novembre 2016 09:54:40 UTC+1, Rayland a écrit :
>
> Greetings fellow gophers,
>
> I have a library in my vendor folder that looks like this:
>
> package gorm
>
> import (
>"fmt"
>"github.com/jinzhu/gorm"
>_ "github.com/jinzhu/gorm/dialects/mysql"
>conf "github.com/spf13/viper"
>"math/rand"
>"time"
> )
>
> var DB *gorm.DB
>
> func GetDB() (*gorm.DB, error) {
>if DB != nil {
>   return DB, nil
>}
>
>DB_NAME := conf.GetString("db.sql.mysql.dbname")
>DB_USERNAME := conf.GetString("db.sql.mysql.username")
>DB_PASSWORD := conf.GetString("db.sql.mysql.password")
>DB_IPS := conf.GetStringSlice("db.sql.mysql.ips")
>ipsNr := len(DB_IPS)
>
>rand.Seed(int64(time.Now().Nanosecond()))
>
>connString := 
> fmt.Sprintf("%s:%s@tcp(%s)/%s?charset=latin1=True",
>   DB_USERNAME,
>   DB_PASSWORD,
>   DB_IPS[rand.Intn(ipsNr)],
>   DB_NAME,
>)
>
>DB, err := gorm.Open("mysql", connString)
>if err != nil {
>   return nil, err
>}
>
>return DB, nil
> }
>
>
> And every time I use GetDB() I get a new database connection instead of 
> getting the one already initialized. 
>
> When I do the same thing outside the vendor folder it works as intended.
>
> What's the catch here?
>
>
> Thank you  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON parser

[pierre . curto]

Then you need to provide sample data...

Le jeudi 10 novembre 2016 18:33:10 UTC+1, Sergio Hunter a écrit :
>
> I agree with you) But what do i do with this, It's exactly the same error.
>
> четверг, 10 ноября 2016 г., 19:05:12 UTC+2 пользователь 
> pierre...@gmail.com написал:
>>
>> We will get there but is is hard hitting your target when shooting in the 
>> dark :).
>>
>> Remove white spaces:
>> https://play.golang.org/p/_LktUPDhYW
>>
>> Le jeudi 10 novembre 2016 17:52:21 UTC+1, Sergio Hunter a écrit :
>>>
>>> Thanks for your help. 
>>> Do you know what it means? 
>>> 2016/11/10 18:46:21 invalid character '\u0085' looking for beginning of 
>>> value
>>> exit status 1
>>>
>>>
>>> четверг, 10 ноября 2016 г., 18:32:40 UTC+2 пользователь 
>>> pierre...@gmail.com написал:

 Sorry, I did not test it. This one passes the playground build (up to 
 the mysql driver not being found):
 https://play.golang.org/p/_WfTMOd-s6

 Le jeudi 10 novembre 2016 17:13:19 UTC+1, Sergio Hunter a écrit :
>
> The compiler generates an error
>
> Test.go:71: undefined: o
> Test.go:85: cannot use nil as type Object in return argument
>
>
>
>
>
> четверг, 10 ноября 2016 г., 17:56:58 UTC+2 пользователь 
> pierre...@gmail.com написал:
>>
>> Ok, then something along those lines:
>> https://play.golang.org/p/dMPQIrEdNN
>>
>> Le jeudi 10 novembre 2016 16:36:21 UTC+1, Sergio Hunter a écrit :
>>>
>>> Thanks so much for your answer. 
>>> I'll try to explain what I need. I have a field "data",inside field 
>>> has compress rows and text data(json), I need decompress data, but my 
>>> code 
>>> begins to unpack the file to text and compiler generates an error.
>>> The logic is this: It reads "data" of the database, do 
>>> "json.NewDecoder", if "json.NewDecoder" did not work - will "err", then 
>>> if 
>>> there are "err" is necessary to decompress and do again 
>>> "json.NewDecoder". 
>>> I hope you are understand me, thanks.
>>>
>>> четверг, 10 ноября 2016 г., 13:03:28 UTC+2 пользователь Simon 
>>> Ritchie написал:

 I'm also not sure what you are trying to do.  However, I think I 
 can see a bug in your code.

 First you run a database query to get a list of values from a field 
 called data.  This could produce up to 10 values.

 Next you have a loop which runs through the values and discards 
 them.  At the end of the loop, you have the data field from the last 
 record, and you have thrown away all the others.  Is this what you 
 want?

 Finally, you unzip the last data field.

 So if your table contains 100 records, you will get 10 of them, 
 throw away the first 9 records and unzip the data from the last one.

 I hope this helps.



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON parser

[pierre . curto]

Sorry, I did not test it. This one passes the playground build (up to the 
mysql driver not being found):
https://play.golang.org/p/_WfTMOd-s6

Le jeudi 10 novembre 2016 17:13:19 UTC+1, Sergio Hunter a écrit :
>
> The compiler generates an error
>
> Test.go:71: undefined: o
> Test.go:85: cannot use nil as type Object in return argument
>
>
>
>
>
> четверг, 10 ноября 2016 г., 17:56:58 UTC+2 пользователь 
> pierre...@gmail.com написал:
>>
>> Ok, then something along those lines:
>> https://play.golang.org/p/dMPQIrEdNN
>>
>> Le jeudi 10 novembre 2016 16:36:21 UTC+1, Sergio Hunter a écrit :
>>>
>>> Thanks so much for your answer. 
>>> I'll try to explain what I need. I have a field "data",inside field has 
>>> compress rows and text data(json), I need decompress data, but my code 
>>> begins to unpack the file to text and compiler generates an error.
>>> The logic is this: It reads "data" of the database, do 
>>> "json.NewDecoder", if "json.NewDecoder" did not work - will "err", then if 
>>> there are "err" is necessary to decompress and do again "json.NewDecoder". 
>>> I hope you are understand me, thanks.
>>>
>>> четверг, 10 ноября 2016 г., 13:03:28 UTC+2 пользователь Simon Ritchie 
>>> написал:

 I'm also not sure what you are trying to do.  However, I think I can 
 see a bug in your code.

 First you run a database query to get a list of values from a field 
 called data.  This could produce up to 10 values.

 Next you have a loop which runs through the values and discards them. 
  At the end of the loop, you have the data field from the last record, and 
 you have thrown away all the others.  Is this what you want?

 Finally, you unzip the last data field.

 So if your table contains 100 records, you will get 10 of them, throw 
 away the first 9 records and unzip the data from the last one.

 I hope this helps.



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON parser

[pierre . curto]

Ok, then something along those lines:
https://play.golang.org/p/dMPQIrEdNN

Le jeudi 10 novembre 2016 16:36:21 UTC+1, Sergio Hunter a écrit :
>
> Thanks so much for your answer. 
> I'll try to explain what I need. I have a field "data",inside field has 
> compress rows and text data(json), I need decompress data, but my code 
> begins to unpack the file to text and compiler generates an error.
> The logic is this: It reads "data" of the database, do "json.NewDecoder", 
> if "json.NewDecoder" did not work - will "err", then if there are "err" is 
> necessary to decompress and do again "json.NewDecoder". 
> I hope you are understand me, thanks.
>
> четверг, 10 ноября 2016 г., 13:03:28 UTC+2 пользователь Simon Ritchie 
> написал:
>>
>> I'm also not sure what you are trying to do.  However, I think I can see 
>> a bug in your code.
>>
>> First you run a database query to get a list of values from a field 
>> called data.  This could produce up to 10 values.
>>
>> Next you have a loop which runs through the values and discards them.  At 
>> the end of the loop, you have the data field from the last record, and you 
>> have thrown away all the others.  Is this what you want?
>>
>> Finally, you unzip the last data field.
>>
>> So if your table contains 100 records, you will get 10 of them, throw 
>> away the first 9 records and unzip the data from the last one.
>>
>> I hope this helps.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON parser

[pierre . curto]

Hello,

I am sorry I am not sure I understood what you wanted to achieve, however, 
if you need to extract a json object from your sql rows, here is some code 
that should do it:
https://play.golang.org/p/92oFkprZfs

HTH

Pierre

Le mercredi 9 novembre 2016 22:36:42 UTC+1, Sergio Hunter a écrit :
>
> Please tell me how to properly finish the JSON parser, so when the line 
> did not fall unzip the code? That is, when you compile the code meets the 
> text rather than the archive, immediately falls. It is necessary to write 
> to skip the line with the text. When I start the first line unpacks it, and 
> then when it sees the text drops, so it is necessary to write to pass and 
> go on to unpack the archive. Sorry for my English. I hope you are 
> understood me)
>
> package main   import ( "database/sql" "log" _"
> github.com/go-sql-driver/mysql" "compress/zlib" "bytes" "os" "fmt" 
> "encoding/json" )   func main() { db, err := sql.Open("mysql", 
> "name:password@tcp(127.0.0.1:port)/database") if err != nil { panic(err.
> Error()) } defer db.Close()   rows, err := db.Query(`SELECT data FROM 
> user_stats ORDER BY created_at LIMIT 10`) if err != nil { log.Fatal(err) } 
> defer rows.Close()   var data []byte   for rows.Next() { err := rows.Scan(
> ) if err != nil { log.Fatal(err) }   r, err := zlib.NewReader(bytes.
> NewReader(data)) if err != nil { log.Panicf("Cannot read archive %v", err)
> ; } io.Copy(os.Stdout, r) r.Close() } }
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Multiple-reader single-writer map access - is this lockless workaround safe?

[pierre . curto]

You might be interested in this:
https://golang.org/pkg/sync/atomic/#Value


Le lundi 12 septembre 2016 17:04:39 UTC+2, sqweek E. a écrit :
>
> Ok so after getting away with using maps to share data between threads for 
> a lng time, I've finally seen the light and accepted that this is not 
> safe.
>
> In my case the threads in question are a painter thread and a 
> mouse/keyboard event processing thread. They want to share data because 
> obviously a mouse hitbox needs to match what is being drawn on the screen, 
> unless you're going for a ux that drives your users insane :)
>
> Anyway as I said it's not safe to concurrently read and write a map; 
> eventually this will result in a panic. Yet I'm stuck with a codebase that 
> does this all over the place. So despite hating the thought of blocking 
> either thread I did what any honest java-for-dayjob coder would do and 
> resigned myself to hiding the maps behind an RWLock.
>
> Of course things are never that simple; adding locks to code that was not 
> designed with them in mind is a good way to introduce deadlocks 
> (particularly of the 
> recursive-read-lock-while-other-thread-is-acquiring-write-lock variety). I 
> made another change to address recursive lock acquisition, realised I 
> missed a couple of shared maps and suddenly locking code was strewn all 
> over my program; I got to the point of acquiring a read-lock every time the 
> mouse moved before giving up in disgust. I thought about using an actual 
> concurrent map, but giving up the builtin map's ease of use and 
> well-typedness didn't thrill me. After some thought I came up with an 
> alternative approach...
>
> TLDR; My shared structures are *mostly* read-only, in the sense that read 
> operations are much more common than writes. I decided I can afford to 
> change the writes so instead of updating the maps in place, they (a) take a 
> copy of the current map (b) update the copy and (c) replace the reference 
> to the original map (held in a struct field) with the updated copy.
>
> I was pretty chuffed with this approach. It's clearly not the most 
> efficient but it allowed me to solve the panic without risking deadlock. 
> I'd be surprised if I'm the first person to come up with it, but I haven't 
> seen it mentioned - the majority of advice seems to be "use an RWLock" or 
> "use a concurrent map".
>
> I'm interested in understanding how safe/portable the approach is. I'm no 
> expert on ARM/memory barriers but my understanding is that without an 
> explicit sync/channel operation there's no guarantee another thread will 
> see a change (in this case, the new map instance). In my case I have a 
> channel based notification mechanism running alongside to wake up the 
> painter thread when something changes, I'm just not sure what memory 
> changes that is guaranteed to communicate.
>
> I also just wanted to share the approach and see how other people feel 
> about it. It reminds me a bit of a double-buffering - writing to the 
> backbuffer and then swapping it into action.
>
> -sqweek
>

-- 
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: Confused about defer

[pierre . curto]

To me this works as expected.

In both your versions, the return statement in Recover() is not even 
reached since the call to f panics. You recover from the panic in your 
defer statement and assign the err variable your error value.

Since in your first version, that variable is not returned, you do not see 
it outside of your Recover() function.
In your second version, the err variable is declared in your function 
signature, so it does get returned, hence why you see it.

Le vendredi 26 août 2016 09:11:19 UTC+2, dc0d a écrit :
>
> There deferred function here has not any return value - to get discarded. 
> It rather assigns a value to the *closure* *err* variable.
>
> Since a defer statement "*invokes a function whose execution is deferred 
> to the moment the surrounding function returns*", so I expected the *err* 
> variable should have a value just before the return statement executes.
>
> The *err* variable is just a closure. Still I'm confused why the first 
> version does not behave as expected - because the actual function *is not 
> invoked yet* at the position of defer statement but just it's parameters. 
> "*Instead, deferred functions are invoked immediately before the 
> surrounding function returns*".
>
> Why this is not behaving as expected?
>
> On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>>
>> I put your code snippet in the playground for easier sharing: 
>> https://play.golang.org/p/ZvuNwjS7ZF
>>
>> I think the spec has the answer you're looking for regarding how named 
>> result parameters are handled during a panic.
>> https://golang.org/ref/spec#Defer_statements
>>
>> Specifically the sentence:
>>
>>> If the deferred function has any return values, they are discarded when 
>>> the function completes. (See also the section on handling panics 
>>> .)
>>>
>>
>> Also,
>>
>>> If the function's signature 
>>>  declares result parameters, the function body's statement list must 
>>> end in a terminating statement 
>>> .
>>>
>> https://golang.org/ref/spec#Function_declarations
>>
>> And the panic is the 'terminating statement'
>>
>> Hope this helps,
>> Vasko.
>>
>> On Thursday, August 25, 2016 at 4:19:17 PM UTC-6, dc0d wrote:
>>>
>>> Assuming we have this test:
>>>
>>> func TestRecover(t *testing.T) {
>>>  f := func() (interface{}, error) {
>>>  panic(`TEST`)
>>>  }
>>>  r, e := Recover(f)
>>>  t.Log(r, e)
>>> }
>>>
>>> And two versions of *Recover* function.
>>>
>>> Version 1:
>>> func Recover(f func() (interface{}, error)) (interface{}, error) {
>>>  var result interface{}
>>>  var err error
>>>
>>>  defer func() {
>>>  if e := recover(); e != nil {
>>>  err = errors.Error(fmt.Sprintf("%v", e))
>>>  }
>>>  }()
>>>
>>>  result, err = f()
>>>
>>>  return result, err
>>> }
>>>
>>>
>>> Version 2:
>>> func Recover(f func() (interface{}, error)) (res interface{}, err error) 
>>> {
>>>  defer func() {
>>>  if e := recover(); e != nil {
>>>  err = errors.Error(fmt.Sprintf("%v", e))
>>>  }
>>>  }()
>>>
>>>  res, err = f()
>>>
>>>  return res, err
>>> }
>>>
>>>
>>> *Question:* Why the output of test for Version 1 is * * (*not 
>>> expected/wrong*) but for Version 2 is * TEST* (*as 
>>> expected/correct*)?
>>>
>>> - Go 1.7, Ubuntu 14.04 x64
>>>
>>

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