[go-nuts] Re: How to limit what the `go get` command is able to import

[paraiso . marc]

> Our internal packaging teams biggest worry is that we don't want someone 
to download something to their development laptop, compile the code into a 
standalone binary, then deploy that out to our container platforms.

That's not really a problem with Go but an organizational problem. 

You don't want people to download stuff from the internet? use a firewall 
disallowing people from accessing the internet. Anybody can go on github, 
click on a link and get a zip with some source code. How are you going to 
deal with that? it has nothing to do to with Go. Either you trust your 
developers with their intelligence, or you don't and you don't allow them 
to deploy anything on your container platforms without significant code 
review from an accredited developer who will be the only one authorized to 
deploy anything on your container platforms.


Le vendredi 2 mars 2018 11:59:13 UTC+6, Brendan O'Dwyer a écrit :
>
> Yes(technically) our deploys are controlled via gitlab. 
>
> Our internal packaging teams biggest worry is that we don't want someone 
> to download something to their development laptop, compile the code into a 
> standalone binary, then deploy that out to our container platforms.
>
> In our production environment this isn't even an issue because we can 
> can't even reach out to the internet in builds/deploys because its limited 
> to only internal locations. Their concern is that in development people 
> could `go get` packages that are not approved, then deploy those. While 
> that is super cool and awesome in open source worlds, unfortunately I work 
> for a bank that really likes to restrict and limit things so that they are 
> as secure as can be.
>
> On Wednesday, February 21, 2018 at 4:18:54 PM UTC-6, matthe...@gmail.com 
> wrote:
>>
>> Are the builds and deployment controlled? The command “go list” can be 
>> used to simplify parsing the imports in each package, so a script could 
>> check that every import is either an allowed standard library package or 
>> one matching your internal URL.
>>
>> Matt
>>
>> On Wednesday, February 21, 2018 at 11:37:35 AM UTC-6, Brendan O'Dwyer 
>> wrote:
>>>
>>> My company wants to start using go more, and traditionally when we use 
>>> java and python, when we package them for the developer laptops we override 
>>> settings and configs for the installs to point to our internal Artifactory 
>>> so that we don't have developers using packages that haven't been ok'd for 
>>> use. I was wondering if there was anyway to do this or configure go to 
>>> limit what its allowed to import from the open internet with the `go get` 
>>> command?
>>>
>>

-- 
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: Write a program for Linux in Go lang which can run any command (of coder's choice) on another machine (privately or publicly accessible) and prints its output.

[paraiso . marc]

sounds like homework that should be done by the student, not the community. 

Le mardi 11 avril 2017 00:42:32 UTC+2, Owais Hashmi a écrit :
>
> Write a program for Linux in Go lang which can run any command (of coder's 
> choice) on another machine (privately or publicly accessible) and prints 
> its output.
>

-- 
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: Disadvantage of Go

[paraiso . marc]

>  Some time ago I collected a number of alternatives to using generics - 
see: https://appliedgo.net/generics

None of these alternatives really solve any real problem generics would 
solve. Generics are types, just like first class functions. Lamenting on 
the lack on generics is useless as well, Go will never have generics 
because of forward compatibility. 

But let's not pretend than there is an alternative to generics "people 
can't see" within Go. Go just wasn't built for code re-use in mind or 
writing abstractions at all due to the lack of polymorphism in the 
language. So people have to write specialized code when it comes to writing 
logic involving containers, that's the only truth there is.

> If you have a particular problem and you think, "I do need generics to 
implement that!", then you might become blind for other solutions. 

It's not being blind to another solution, every other solution has 
drawbacks generics don't have. Code generation involve writing 
pre-processors and maintaining manifests, opting out of Go type system with 
interface{} everywhere is obviously problematic. That's not solving what 
generics are here for in languages such as Java C# or Haskell. Basically 
you are asking developers to pay a price the compiler doesn't want to pay. 
Let's not patronize people who see the obvious flaw in that logic.

Again while it is useless to complain, people are complaining for a good 
reason, it can be difficult to understand what led to the absence of 
generics at first place in Go design. People coming from 
C,Python,Javascript and Ruby might not care, people coming from Java, C# or 
Haskell will have harder time working around the lack of generics in Go 
because they are used to that feature to solve their problems. 

To the latter I'd say that if Go feels tedious for a task then use 
something else, really. Go wasn't designed to please people who like 
expressive static type systems. There are many alternatives such as D, 
Ocaml, ... 

Le samedi 14 janvier 2017 10:35:33 UTC+1, Christoph Berger a écrit :
>
> Hi Yu,
>
> Generics have their use cases, e.g. when designing general data containers 
> or in the context of numeric computation (matrix type of int, float, etc). 
> In other areas, however, their use may be overrated. 
>
> If you have a particular problem and you think, "I do need generics to 
> implement that!", then you might become blind for other solutions. 
>
> Some time ago I collected a number of alternatives to using generics - 
> see: https://appliedgo.net/generics
>
> Best,
> Christoph
>
>
> On Saturday, January 14, 2017 at 7:42:43 AM UTC+1, Yu Liu wrote:
>>
>> Agree.
>>
>> Only generics missing is disadvantage of Go.
>>
>> Yu
>>
>> On Friday, January 13, 2017 at 10:56:07 AM UTC-8, simon place wrote:
>>
>>> sorry but for me, excepting generics and maybe a float32 maths lib, 
>>> these are all just your problem.
>>>
>>> particularly wrong is the idea of native conversion of bools to/from 
>>> numbers, albeit widespread and long-standing, perpetuating these mistakes 
>>> just means preventing any development of languages.
>>>
>>

-- 
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: Proposal for a succinct error return syntax

[paraiso . marc]

But you're not going to get any new syntax accepted by the go team anyway, 
certainly not a new operator. You know that already. 

Le vendredi 6 janvier 2017 11:04:38 UTC+1, xjru a écrit :
>
> As I said, this syntax doesn't help, because it puts file into the scope 
> of the if block where we often don't want it. Reformatting it doesn't 
> change that.
>
>

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

[go-nuts] Re: Proposal for a succinct error return syntax

[paraiso . marc]

It would be simpler if Go fmt would let people write if statements on a 
single line :

if file,err := os.Open(fname) ; err!=nil { return err }  

Here, no need for new syntax and still readable while reducing the 
conditional noise. And everybody could be happy.

Le vendredi 6 janvier 2017 01:35:14 UTC+1, xjru a écrit :
>
> Here are some examples for valid error returns according to my proposal:
>
>
> file, err := os.Open(fname) ||| return err
>
> file, err := os.Open(fname) ||| panic(err)
>
> file, err := os.Open(fname) ||| return errors.Wrap(err, "too bad")
>
>
> The third example uses the Wrap function from github.com/pkg/errors. The 
> ||| operator is not important. It could be any operator, but the idea 
> behind the tripple bar is to signal a special kind of or. I can imagine 
> using the keyword "orr" instead.
>
> The semantics is pretty simple. If there is an (possibly multiple) 
> assignment whose last component conforms to the error interface, then it 
> may be followed by ||| and a single statement that must either return or 
> panic.
>
> You might argue that this isn't much longer:
>
> if file, err := os.Open(fname); err != nil {
> return err
> }
>
> However, this has the unfortunate side effect of putting file into the 
> scope of the if block. That's why we often have to use
>
> file, err := os.Open(fname)
> if err != nil {
> return err
> }
>
> I think my proposal has a couple of benefits.
>
>- It is perhaps not too magical (just a little bit because the 
>condition is implied by the ||| operator).
>- I doesn't obscure the clear view on the assignment statement itself 
>(unlike Rust's try! macro).
>- The keywords return or panic make it very clear what happens to 
>control flow (unlike Rust's try! macro).
>
> It does have the drawback that it is a unique special case for errors not 
> based on a more general language facility. It makes the language a little 
> bit more complex. But I think errors are frequent enough to deserve a 
> little bit of syntactic sugar.
>
> Apologies if this has been discussed to death.
>
>

-- 
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: Looking for Golang counterpart to 'params' in Python

[paraiso . marc]

>
> response = requests.request("GET", url, data=payload, headers=headers, 
> *params=params*)



if auth is a header then set the appropriate header :

https://golang.org/pkg/net/http/#Header.Set

if it is basic auth you need to implement then look at the spec : 

https://en.wikipedia.org/wiki/Basic_access_authentication

You didn't explain what you expect "auth" or "params" to be . 


Le mardi 13 décembre 2016 06:46:23 UTC+1, bet...@google.com a écrit :
>
> Hi,
>
> In Python, I can include params like this:
>
> =
>
> *params = {'auth': ''}*
>
> response = requests.request("GET", url, data=payload, headers=headers, 
> *params=params*)
>
> =
>
> Any pointers on how Golang does this?
>
> Thanks,
> Betsy
>

-- 
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: Should I return a value or pointer?

[paraiso . marc]

The first question you need to ask yourself is are you going to use errors 
as values ( if err == myerrors.ErrValue ) or errors as types ( if e,ok:= 
err.(*myerrors.ErrType ; ok ) 

Le samedi 10 décembre 2016 20:10:26 UTC+1, Jon a écrit :
>
> I would like to know what my default practice should be when returning 
> structs from functions. Should I return a value or a pointer? (Assume I 
> don't need the functionality of returning a pointer and my struct contains 
> at most one simple field so a vast copy isn't needed if I return a value.)
>
> A specific example could be the errors package 
>  with errors.New. 
>
> The New function is implemented by returning an errorString pointer: 
> 
>
> func New(text string) error {
> return {text}
> }
>
> Could it just as easily have been implemented by returning an errorString 
> value ? If so why was the pointer 
> return chosen over value return?
>
> func New(text string) error {
> return errorString{text}
> }
>
> Could it also have been implemented as below 
>  which looks even simpler?
>
> func New(text string) error {
> return errorString(text)
> }
> // errorString is a trivial implementation of error.
> type errorString string
>
> func (e errorString) Error() string {
> return string(e)
> }
>
> What was the thought process that went into the implementation of the 
> errors package? Were the latter two implementation options I suggest 
> considered? If so why were they disregarded? Performance? Coding standards? 
> Heap allocation benefits?
>

-- 
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: Extending objects / methods

[paraiso . marc]

>
> The declared type does not inherit any methods 
>  bound to the existing 
> type, but the method set  of an 
> interface type or of elements of a composite type remains unchanged:


https://golang.org/ref/spec#Type_declarations

You need to use another strategy like struct embedding which *may *or *may 
not* work depending to your use case

A field declared with a type but no explicit field name is an *anonymous 
> field*, also called an *embedded* field or an embedding of the type in 
> the struct. An embedded type must be specified as a type name T or as a 
> pointer to a non-interface type name *T, and T itself may not be a 
> pointer type. The unqualified type name acts as the field name.


type xadvanced struct {
*x
}
func(x *xadvanced)increment(){
   x.y ++
   fmt.Println(x.y)
}

I'd advise you do read the spec at least once, it's short and concise .


Le vendredi 2 décembre 2016 16:25:50 UTC+1, Slawomir Pryczek a écrit :
>
> Hi Guys,
>
> i want to make something like this
>
> type si struct {
>
> s *sync_task.Sync_task
>
> }
>
>
> func (this *si) Process() {
>
>
>... some code here ...
>
>this.Process();
>
> }
>
>
>
> Basically i want to extend object in another package... and this works. 
> Now i'd just want to extend it without creating "real" struct, code
>
> type x struct {
> y int
> }
> type xadvanced *x
>
> func (this *x) increment() {
> this.y++
> fmt.Println(this.y)
> }
>
> test2 := xadvanced()
> test2.increment() ---> ERROR
>
> https://play.golang.org/
>
> What im doing wrong and how to access methods of x object when having 
> pointer to xadvanced...
>

-- 
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: Run some extra setup on each test

[paraiso . marc]

You can use sub-tests 

https://blog.golang.org/subtests

if you need to pass some data to a subtest you can use closures like 

func(data Data) func ( t *testing.T) {
  return func( t *testing.T) {
  print(data)
   }
}

If you need a more traditional setup/teardown fixture based test runner, 
then you need to use something else like Go convey. Granted it means slower 
tests.

Le vendredi 2 décembre 2016 14:48:53 UTC+1, Jérôme LAFORGE a écrit :
>
> Hello all,
> Do you know an elegant workaround that allows to execute extra setup on 
> each test (kind of TestMain but for each test) ?
> If not, did you plan to add this kind of feature into next release of Go ?
>
> Thank in advance.
> BR
> Jérôme
>

-- 
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: Interface help

[paraiso . marc]

Just create a slice of GoNoGoer 

var evals []GoNoGoer 

now you DO NOT need a type assertion like that 

if ok := eval.(GoNoGoer); ok // REMOVE that line


Le mercredi 30 novembre 2016 17:59:07 UTC+1, sc28 a écrit :
>
> I'm trying to better understand how to properly use interfaces and created 
> this scenario:
>
> Let's say I have an 'evaluator' program, that over time will want to add 
> more and more evaluations of a Go-NoGo nature (Nasa?)
>
> Here's want I was trying:
>
> // My Go-NoGo interface - method should return true/false and an error is 
> false
> type GoNoGoer interface {
> Eval() (bool, error)
> }
>
>
> Here's a couple of concrete evaluation types:
> --
>
> type Evaluation1 struct {
> Data string
> }
>
> func (a *Evaluation1) Eval() (bool, error) {
> isOk := a.DoMyEvaluationWithTheData()
> if !isOk {
> return false, fmt.Errorf("evaluation failed because ...")
> }
> return true, nil
> }
>
> type Evaluation2 struct {
> SomeData string
> MoreData int64
> }
>
> func (a *Evaluation2) Eval() (bool, error) {
> isOk := a.DoMyEvaluationWithTheStructData()
> if !isOk {
> return false, fmt.Errorf("evaluation failed because ...")
> }
> return true, nil
> }
>
> --
>
> In main - iterate over all the evaluations and print the results of Eval() 
>
> func main() {
> one := Evaluation1{Data: "abcabcabc"}
> two := Evaluation2{SomeData: "xyzxyz", MoreDate: 128}
>
> var evals []interface{}<-- So I want a slice of evaluations 
> (all implemented as various structs)  - probably not correct to use 
> interface{}???
> evals = append(evals, one)
> evals = append(evals, two)
>
> // range over the slice, and if the object has implemented the Eval() 
> method execute it and print the results  (doesn't work)
> for _, eval := range evals {
> if ok := eval.(GoNoGoer); ok { <-- This also is wrong, I want to go 
> the other direction (from concrete to interface)
> isOk, err := eval.Eval()
> fmt.Println(ok, err)
> }
> }
> }
>
>
> I'd appreciate the slap across the head pointing out where I'm missing the 
> boat!
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Type statement in blocks vs global

[paraiso . marc]

I'm not sure what you mean. 

types that reference each others in a type declaration are allowed when 
declared globally , but not in a block ( ? ) 

i.e. :

declaring Foo and Bar outside main would work , declaring them inside main 
doesn't . I wanted to declare them inside an example function in order for 
them to show up in the docs since the latter only prints the body of 
example functions (func ExampleFoo ...) . So I was asking why it worked 
that way. Since a type can only be declared once in a scope, the order in 
which they are declared shouldn't matter ? so they could reference each 
others like in my code snippet. thanks. 

Le lundi 28 novembre 2016 11:54:39 UTC+1, Jan Mercl a écrit :
>
> On Mon, Nov 28, 2016 at 11:46 AM  
> wrote:
>
> > Is there an alternative aside from declaring types globally ? 
>
> Unfortunately, the problem to solve is not defined, only the solution 
> tried and failed is, so I don't know if this can help: 
> https://play.golang.org/p/9btAagXDpM
>
> -- 
>
> -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] Thinking OO virtual function in Go

[paraiso . marc]

interfaces only work on methods. 

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

Name, Age , ... are not methods they are fields.You need to make them part 
of Speaker interface by using methods instead of fields.

Le mardi 22 novembre 2016 23:03:54 UTC+1, Tong Sun a écrit :
>
>
>
> On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:
>
>> On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
>> > Hi,
>> >
>> > How to architect the OO's virtual function in Go?
>> >
>> > Please take a look at this (not working) Go program
>> > https://play.golang.org/p/qrBX6ScABp
>> >
>> > Please think of the "func Output()" as a very complicated function that 
>> I
>> > only want to define once at the base level, not to duplicate into each 
>> sub
>> > classes.
>> >
>> > How can I make it works so that the last output statement, instead of 
>> being,
>> >
>> > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>> >
>> >
>> > will be this instead:
>> >
>> > fmt.Printf("[%v] %s\n", k, v.Output())
>> >
>>
>> You define a function:
>>
>> func Output(s Shape) string {
>>return s.Name() + "'s area size is " + s.Area()
>> }
>>
>> Go uses interfaces for polymorphism.
>> Other OOP languages can use inheritance for polymorphism too, but Go
>> doesn't have inheritance.
>>
>
> Thanks Jesse. That works. 
>
> However I just realized that it is only part of my problem. 
>
> I have a huge list of common variables that I defined in my "base class", 
> changing it from a member function to a pure function causes almost every 
> single variable now undefined. 
>
> I can demonstrate the problem with this code
> https://play.golang.org/p/QjCtD9rGpa
>
> So, once again, thinking in OO, I'll define all of the common variables in 
> base class, and common functionalities in virtual functions. How to make 
> that idea work in Go?
>
> For the above specific code, how to easily make "func Output" works?
>
> 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: Rendering absolute URLs for a hypermedia API

[paraiso . marc]

With gorilla/mux you can use named routes :

r := mux.NewRouter() r.HandleFunc("/articles/{category}/{id:[0-9]+}", 
ArticleHandler). Name("article")
url, err := r.Get("article").URL("category", "technology", "id", "42")



Le lundi 14 novembre 2016 17:34:26 UTC+1, to...@hypr.nz a écrit :
>
> I believe I have done enough research (and attempts) that this should be 
> an easy answer: either it doesn't work that way or I've missed something 
> simple! Fingers crossed and thanks in advance.
>
> My goal is to render absolute URLs for my API—I can't get route libraries 
> (eg gorilla/mux) to do this even though they look to be able to do so.
>
> The first question, to render absolute URLs by reversing a route name, 
> which library should I really be using? I'm assuming one that hooks into 
> the http.Request, such as, gorilla/mux.
>
> Given I use gorilla/mux, how? I see in the source that it requires a Host 
> to be setting in the route registration but upon registration of a Host, it 
> never matches a route again. (I can't find a solution to this either which 
> suggests that I have something wrong in my thinking).
>
> I hope this is descriptive enough to know whether I am way off the mark or 
> need to provide more, detailed information.
>
> Thanks. Todd.
>

-- 
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: Partial Variable Assignment

[paraiso . marc]

No way, it only works in the same block :

https://golang.org/ref/spec#Short_variable_declarations

 the for statement creates a new block . 

Le samedi 12 novembre 2016 03:49:35 UTC+1, so.q...@gmail.com a écrit :
>
>
> I thought it was possible to do partial assignment where, if one variable 
> is already declared and a new one is not.
> https://stackoverflow.com/questions/39028645/golang-variable-assignment
>
> In the below example ok has been declared prior, but v has not. Trying to 
> run the below results in an error "undefined: v", but I thought this was 
> possible?
> https://play.golang.org/p/dlRpcFGsSM
>
> package main
>
> import (
> "fmt"
> )
>
> func Foo() (int,bool) {
> return 1,false
> }
>
> func main() {
> ok := true
> for ok {
> v,ok = Foo()// v,ok := Foo(), doesn't work either
> fmt.Println(v)
> }
> fmt.Println(ok)
> }
>
>
>
>

-- 
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: Survey on Software Architectures

[paraiso . marc]

I'm on page 5 of the survey and still didn't get any question regarding 
software modelling. I stopped answering these questions.

I'm not keen of survey methodology but I don't think most questions are 
relevant to the theme of the survey. I also think you should ask personal 
questions 
at the end of the survey instead of the beginning as I don't think my 
country of origin, age or education influences how you build questions 
about the core theme of that survey. It would yield much more results.

Le mardi 25 octobre 2016 16:31:07 UTC+2, ozkaya...@gmail.com a écrit :
>
> Dear All,
> We're conducting a survey on software architecture modelling whose link is 
> http://bit.ly/2bGpSN4
> The survey aims at better understanding the practical knowledge and 
> experience of practitioners on software architecture modelling languages.
> If you spend 3-7 mins to fill the  survey, we would be so grateful to you. 
> Indeed, we imperatively need participants to contribute our research on 
> software architectures.
> If you know any potential participants, would you mind me requesting you 
> to forward to survey to them?
> Best,Mert
>

-- 
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: interface as valid method receivers ?

[paraiso . marc]

> there is ambiguity as to what is called.

Sorry I meant there *NO *ambiguity as to what is called.

Le mardi 18 octobre 2016 20:12:17 UTC+2, parais...@gmail.com a écrit :
>
> Obviously in Go this is a compile time error :
>
> type Foo interface {}
>
>
> func (f Foo) DoSomething(){}
>
>
> I wonder if there is some technical limitations that make it undesirable 
> or hard to implement, or it's just that Go designers didn't think it is a 
> relevant feature.
>
> I personally think there is it could be handy in some situations, instead 
> of having to write a function without receiver, it could allow to attach 
> behavior to interfaces automatically 
> instead of the explicit :
>
> func DoSomething(f Foo){}
>
>
> what is your opinion on the matter ? Unfortunately I wasn't able to catch 
> anyone of the Go team during the recent conference in Paris to ask that 
> question.
>

-- 
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: interface as valid method receivers ?

[paraiso . marc]

Hey folks, what a great discussion.

To be clear, if something like that would exist, it should have obvious 
limitation, like any Go features regarding structs and interfaces.

It would be illegal to do that for instance :

type Foo interface {
Do()
}
func (f Foo)interface Do(){}

Now I don't think it would make code harder to read. If Foo is used as an 
argument :

func AcceptFoo(f Foo){
   f.Do() // Execute Foo.Do
}
If Do is not inside the Foo "contract" but a method of Foo, there is 
ambiguity as to what is called.

Even if a struct implementing Foo has a Do function of his own, AcceptFoo 
cannot know that
since it is not defined on the interface .

When it comes to methods on structs, nothing would change : 

type Bar struct {}
func(b Bar)Do()

bar := Bar{}

bar.Do() // execute Bar.Do()

// however 

var bar2 Foo = Bar{}

bar2.Do() // execute Foo.Do()


A strict behavior should be defined one way or another, but I think this 
one would be interesting. 

Anyway It was just a thought on the matter, no big deal. It would be a 
great way to encapsulate some behavior without exposing internals or using 
package level functions accepting interfaces thus leading to cleaner API 
for libraries. If you think about technical implications or some current Go 
features this idea might break, let me know.




Le mardi 18 octobre 2016 20:12:17 UTC+2, parais...@gmail.com a écrit :
>
> Obviously in Go this is a compile time error :
>
> type Foo interface {}
>
>
> func (f Foo) DoSomething(){}
>
>
> I wonder if there is some technical limitations that make it undesirable 
> or hard to implement, or it's just that Go designers didn't think it is a 
> relevant feature.
>
> I personally think there is it could be handy in some situations, instead 
> of having to write a function without receiver, it could allow to attach 
> behavior to interfaces automatically 
> instead of the explicit :
>
> func DoSomething(f Foo){}
>
>
> what is your opinion on the matter ? Unfortunately I wasn't able to catch 
> anyone of the Go team during the recent conference in Paris to ask that 
> question.
>

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

[go-nuts] interface as valid method receivers ?

[paraiso . marc]

Obviously in Go this is a compile time error :

type Foo interface {}


func (f Foo) DoSomething(){}


I wonder if there is some technical limitations that make it undesirable or 
hard to implement, or it's just that Go designers didn't think it is a 
relevant feature.

I personally think there is it could be handy in some situations, instead 
of having to write a function without receiver, it could allow to attach 
behavior to interfaces automatically 
instead of the explicit :

func DoSomething(f Foo){}


what is your opinion on the matter ? Unfortunately I wasn't able to catch 
anyone of the Go team during the recent conference in Paris to ask that 
question.

-- 
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] Reasons why `go get` is entirely quiet by default

[paraiso . marc]

Tools should be quiet by default. A package manager isn't supposed to 
return any result like grep or tail, aside from 0 . 

Le jeudi 13 octobre 2016 23:48:27 UTC+2, Nyah Check a écrit :
>
> Hi everyone,
>
> I don't know if someone may have talked of this here. But I just wish to 
> find out why `go get` is entirely quiet by default? Unlike other package 
> managers like npm or yarn. Someone asked this on the IRC channel today and 
> no one seemed to know why? I tweeted 
>  about this 
> today; still no response yet.
>
> Thanks,
> Nyah
>
> "The heaviest penalty for declining to rule is to be ruled by someone 
> inferior to yourself." --*Plato* 
>

-- 
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: [Open sourced] Workflow based REST Api framework - "florest"

[paraiso . marc]

Reading the doc , trying to reproduce the instructions :

 go get  -u github.com/jabong/florest-core/examples
package github.com/jabong/florest-core/examples: cannot find package 
"github.com/jabong/florest-core/examples" in any o


But that package isn't go gettable at first place anyway. 


Le mardi 27 septembre 2016 12:12:48 UTC+2, suba...@gmail.com a écrit :
>
> Hi All,
> Please check this https://github.com/jabong/florest-core.
>
> 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: Adding YAML to the stdlib

[paraiso . marc]

Anybody can write a spec and deem it a standard.

YAML is certainly not a common data serialization format. Adding a YAML 
parser is in my opinion the least of of Go's priorities when one can see 
all the packages pilling up @ /x/ namespace that should have been in the 
stdlib already. More tools supporting XML development might actually make 
more sense, like support for SAX,XML schema,SOAP, XSL,XPath and all these 
API a lot of entreprise developers still need to interact with. Because 
frankly working with XML in Go is a pain in the arse.

Le vendredi 23 septembre 2016 22:02:51 UTC+2, Zachary Gershman a écrit :
>
> Gustavo - it is not jus that YAML is well known, it is also widely used 
> (as I even mentioned). It is a *standard *even though some may not want 
> to consider it as such. If I can read xml in the stdlib why not yaml? And 
> it is widely supported now but are you committed to supporting it for as 
> long as golang is around?
>
> On Friday, September 23, 2016 at 11:28:27 AM UTC-7, Gustavo Niemeyer wrote:
>>
>> Hi Zachary,
>>
>> You have already seen the thread, but for the benefit of others, Zach's 
>> email comes from a thread raised and replied to yesterday on Twitter:
>>
>> https://twitter.com/jvehent/status/778687333956587522
>>
>> As I said there, the yaml spec is big, messy, and I wouldn't encourage 
>> having the package in the distribution of Go. Something being well known 
>> and appreciated is not a reason to have it in the standard library.
>>
>> Also, there's nothing unfair about maintaining go-yaml. This was 
>> developed years ago while porting the first projects of Canonical to Go, 
>> and is by now widely used there, and we remain committed to supporting it. 
>> I also receive regular fixes and contributions from the community, and 
>> nobody seems upset to do so.
>>
>> The most recent change was to replace the LGPL license by Apache, which 
>> was well received. I was able to negotiate that based on requested from the 
>> community, and were were able to do so due to the CLA that is requested for 
>> contributions (ironic that most people CLA's as evil, yet it was used to 
>> open permissions further).
>>
>>
>>
>> On Fri, Sep 23, 2016 at 2:53 PM, Zachary Gershman  
>> wrote:
>>
>>> Hey All,
>>>
>>> I wanted to get feedback here first before I move this over to the 
>>> golang-dev mailing list (or maybe we even just start a change-set).  YAML 
>>> as a spec is not the greatest and some would even describe it as "gross" 
>>> but most if not all config files are written in some form of YAML (see 
>>> kubernetes as a prime example).  YAML was not included in the stdlib and 
>>> luckily for all of us the awesome go-yaml 
>>>  emerged as the de facto standard for 
>>> a majority of developers.
>>>
>>> Now, inclusion into the stdlib must pass a high bar 
>>>  and not everything can / should 
>>> be included but I believe that when you have over 1300 packages 
>>>  depending on an outside 
>>> library, you should at least have the discussion openly about whether it 
>>> should be moved into the stdlib.
>>>
>>> Also, it is slightly unfair to have the expectation that the community 
>>> should support a significant format through independent OSS work.
>>>
>>
>>
>>
>> -- 
>>
>> gustavo @ http://niemeyer.net
>>
>

-- 
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 + and += operators for string but not slices?

[paraiso . marc]

The more contextual a PL's semantics is the harder it is to make sense of a 
program written in that PL (the inverse is also true, that's why we don't 
program lining zeros and ones ) ... The problem with what you are asking is 
why yet another special case for slices ? why not one for channels ? why 
not using minus too for slices ? or multiply if my slice represents a 
vector ? some languages handle that with operator overloading in user land, 
Go just doesn't allow that. Adding more semantics to the plus operator 
would be against the goals of the language IMHO.  

Le samedi 17 septembre 2016 04:31:52 UTC+2, oyi...@gmail.com a écrit :
>
> Context enables homonyms in spoken languages and overloaded or polymorphic 
> notation in mathematics. Types do the same in programming languages. The 
> rationale for + over join() or cat() for string is equally applicable to 
> slices. a ++ b wouldn't be an unreasonable replacement for append(a, b...) 
> and append([]T, ...T) can stay as is but who needs it when you have []T ++ 
> []T{...T}
>
>
> On Saturday, September 17, 2016 at 12:31:31 AM UTC+1, parais...@gmail.com 
> wrote:
>>
>> Because Go creators have a strong opinion about what + means. I would 
>> argue the languages that engage into these sort of things especially those 
>> who allow operator overloading are antithetic to Go goals, but that's an 
>> opinion., I didn't create Go, I don't agree with all its design choices but 
>> understand why they were made. Go is only sophisticated in the way it 
>> handles concurrency. 
>>
>> Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit :
>>>
>>> I have not been able to find an explanation. Does anyone care to explain 
>>> or point to relevant documentation?
>>>
>>

-- 
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 + and += operators for string but not slices?

[paraiso . marc]

Because Go creators have a strong opinion about what + means. I would argue 
the languages that engage into these sort of things especially those who 
allow operator overloading are antithetic to Go goals, but that's an 
opinion., I didn't create Go, I don't agree with all its design choices but 
understand why they were made. Go is only sophisticated in the way it 
handles concurrency. 

Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit :
>
> I have not been able to find an explanation. Does anyone care to explain 
> or point to relevant documentation?
>

-- 
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 package management committee

[paraiso . marc]

Congrats.

Please consider at least 2 use cases :

- library authors

- project authors

These 2 use cases are widely different and if the solution doesn't address 
both cases it will not be useful.

People using gb don't have the same use case and issues as people using 
glide.

Ultimately the problem can only be solved with a third party tool that is 
NOT go get, but it must be an official tool sanctioned by the Go team. Good 
luck.

Le vendredi 26 août 2016 20:45:26 UTC+2, Peter Bourgon a écrit :
>
> As a reminder, in July I started the Go Packaging Proposal doc[0] with 
> the goal “To produce, have accepted, and implement a complete proposal 
> which addresses the concern of package management.” Thanks to everyone 
> who’s signaled interest. That process involves creating a small 
> committee to drive the proposal from start to finish. 
>
> In forming the committee I’ve focused on three important points— 
>
> 1. First and foremost, that the design and discussion process, and 
> ultimate technical solution, should be driven by a data- and 
> user-needs-centric methodology. 
>
> 2. That the schedule outlined in the process doc should be adhered to 
> as closely as possible. That means design-complete by end September, 
> and proposal-complete by end October, so that any possible language or 
> tooling changes can make the 1 November feature freeze for Go 1.8. 
>
> 3. Each member should have or make time to devote to this process, so 
> that both points above are feasible :) 
>
> A committee size of four I believe most effectively balances a variety 
> of voice and opinion, and an ability to effectively decide and act. 
> After a great deal of consultation with, and feedback from, key 
> members of the Go language and package management/vendoring 
> communities, I'm happy to announce that Andrew Gerrand, Edward Muller, 
> Jessie Frazelle, and Sam Boyer have all agreed to serve on the package 
> management committee. 
>
> Andrew needs no introduction, as he's been leading the Go community 
> advocacy efforts from within the Go team since nearly the very 
> beginning. Andrew brings an unmatched perspective on the current state 
> and evolution of the Go language and tooling, and will be instrumental 
> in shepherding any possible language or tooling changes through the 
> proposal process. 
>
> Ed has been maintaining the godep project for the past two years, and 
> brings a pragmatic and user-centric perspective to the committee. 
>
> Jessie has been on the Go package management front lines for years, 
> originally with Docker and now with Kubernetes. I can't think of 
> anyone better to represent the needs of large Go projects and 
> organizations. 
>
> Sam may be best known in the Go community for his article "So you want 
> to write a package manager[1]." With his background and work on the Go 
> Package Solver, Sam brings theoretical depth and rigor to the 
> committee. 
>
> Keeping the committee small was absolutely essential, but it quickly 
> became apparent that several unquestionably qualified individuals, 
> whose efforts and experience would be critical to our success, would 
> be excluded. We decided that an advisory group, while not part of the 
> original Process doc, would enable the committee to remain small and 
> nimble, while leveraging the value, effort, and experience of a larger 
> group. The maintainers of popular package management tools Glide (Matt 
> Farina), govendor (Daniel Theophanes) and gb (Dave Cheney), as well as 
> Steve 'spf13' Francia (Hugo, Cobra) have all graciously agreed to 
> support in this role. Their job will be to help compile user and 
> domain research, and to represent user needs whenever the committee 
> needs input. Matt and Steve in particular have been hard at work on an 
> updated tool survey and user requirement doc; details forthcoming. 
> Both I and the committee are incredibly grateful to each of them for 
> their support. 
>
> I'll act as secretary, note-taker, and communications director for the 
> committee on an as-needed basis, to free them from the overhead. If 
> you have any questions about the process, please direct them to me. 
> And stay tuned for links to research and design Google Docs. 
>
> [0] 
> https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8
>  
> [1] 
> https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.iqtluxnrr
>  
>

-- 
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 can't convert []T to []T2 if T2 is a copy definition of T?

[paraiso . marc]

There are no subtypes in go, so no covariance or contravariance, which 
explained a lot of limitations of Go type system. The problem is that some 
level of covariance is hardcoded in the compiler (string to []byte ...) 
 which makes me think that go designers understand the value of it and know 
that there are cases where it is needed. It just the same problem as 
generics vs append. append is a generic function  of type 
append([]T,T...)[]T which behavior is hardcoded in the compiler instead of 
being generalized. Go designers understand the value of generics in that 
specific case without letting the user define their own functions with the 
exact same behavior.

https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)

All languages are opinionated, I think that adjective doesn't match Go 
features. Go is a language that is "restricted" but bear with me. 

The problem with being fine with that fact is that, while Go has these 
restrictions, Go allows a lot of dynamic behavior at runtime through 
reflection (with a speed cost, though caching definitely helps) which is a 
paradox for a statically typed language. The temptation of using reflection 
to work around language restrictions becomes huge every time one is 
confronted to these limitations.

It would be interesting to know if allowing(or not) reflection in userland 
was debated among Go designers at some point.

Regards.

-- 
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: Database design pattern

[paraiso . marc]

I find your question strange because, unless you have a specific 
architectural problem , which you don't, AFAIK, you shouldn't try to force 
patterns in your code. Write code that is testable then refactor if needed. 
Don't try to force a specific pattern just because "patterns". 

Now if you are looking for patterns for the sake of patterns Microsoft has 
extensive documentation of enterprise patterns : 

https://msdn.microsoft.com/en-us/library/ff648419.aspx

as well as Martin Fowler :

http://martinfowler.com/eaaCatalog/index.html

Something that would be useful for everybody next time is you actually 
coming with a piece of code that works then asking for ways to refactor 
that piece of code. 

Le vendredi 19 août 2016 16:08:04 UTC+2, Asit Dhal a écrit :
>
> Hi All,
>
> I need to build an application that accesses a small database(sqlite or 
> may be mysql in production).
>
> My database operations are very small, like
> 1. Insert
> 2. Read
> 3. Search
>
> Insert is one time, and most of the time new records will be added in a 
> batch. 
>
> Can someone suggest me some application design pattern(a tutorial or 
> github repo) for small database access ?
>
>
> Warm Regards,
> Asit Dhal
> http://bit.ly/193ASIT
>

-- 
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: IDE for GOLANG

[paraiso . marc]

Liteide is the best editor for Go :

https://sourceforge.net/projects/liteide/

Le mardi 2 août 2016 14:25:21 UTC+2, kritika...@indiamart.com a écrit :
>
> Hi, 
> is there IDE for creating a web service in GOLANG by using Revel framework 
>  which follows MVC architecture.
>
> i am using Ubuntu ..
>
>
>
> *Watch our latest TV Commercial #IndiaKiKhoj 
> *
>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[paraiso . marc]

I guess the difference is that a builtin COULD be compile-time type safe. 
It could reject anything that is not a slice or an array, the same way 
append is type safe.

Le mercredi 3 août 2016 17:51:44 UTC+2, Thomas Bushnell, BSG a écrit :
>
> On Wed, Aug 3, 2016 at 7:36 AM T L  
> wrote:
>
>> Often, I need converting a []T to []interface{} to use the []interface as 
>> a variable length parameter.
>> But converting a []T for []interface{} in a for loop is neither clean nor 
>> efficient.
>>
>
> If there was a builtin that did it, it would simply need to do the same 
> loop. The memory representation is not the same.
>
> Thomas
>  
>

-- 
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] liteide x30.2 released

[paraiso . marc]

Nice Ctrl+P to navigate between files work well , it's like to be able to 
navigate between Symbols too. With a drop down menu .

Le mardi 12 juillet 2016 09:09:15 UTC+2, visualfc a écrit :
>
> Hi, all
>
> LiteIDE x30.2 released, This version bug fix and build test for Go1.7 rc1
>
>
> ### 2016.7.12 Ver X30.2
> * LiteApp
> * add new vs-dard css, thanks [tupunco](https://github.com/tupunco)
> * fix and re-implement editor list menu
> * QuickOpen
> * QuickOpenFile skip same folder and same files
> * QuickOpneFile add current editor local files
>

-- 
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: New Context method in http.Request, what can we do with it?

[paraiso . marc]

Don't you think it would be better to use context to hold session values 
rather than using global variables like github.com/gorilla/sessions does ? 

Le lundi 11 juillet 2016 00:43:05 UTC+2, Matt Silverlock a écrit :
>
> Use it to pass connection/request-scoped values: that is, values that 
> could only exist once you have a request. authentication tokens, user 
> details, connection IDs: things that can't be known/generated before the 
> connection has been received.
>
> e.g. gorilla/mux (https://github.com/gorilla/mux) uses it to pass 
> route-matching information back to the user (i.e. for /user/:name, the 
> :name value). Don't use context to pass app-level dependencies, as it makes 
> testing, reasoning and debugging hard.
>
>
>
> On Thursday, July 7, 2016 at 4:03:18 PM UTC-7, Tyler Compton wrote:
>>
>> I'm really excited to see context.Context become a first class citizen in 
>> Go 1.7. After using context, it feels like a natural way to write Go 
>> network code and it fits naturally in the standard library. I'm trying to 
>> figure out how I can improve existing code with the new features that come 
>> with it.
>>
>> In Go 1.7, requests now can contain a context, and the context can be 
>> changed. This seems really cool, but I don't know what exactly I can do 
>> that I can't do before, other than what the documentation specifically 
>> outlines: "For outgoing client requests, the context controls cancelation."
>>
>> Is there anything else we will be able to do that I should be looking 
>> into? What are your plans?
>>
>

-- 
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] liteide x30 released

[paraiso . marc]

Great news, I love liteide which is for me the best Go IDE, no question. I 
love the embedded Go Playground too, quite handy when it comes to try new 
stuff in Go.

Le lundi 4 juillet 2016 03:52:29 UTC+2, visualfc a écrit :
>
> Hi, all
> liteide x30 released!
> This version bug fix, support go1.7, add fakevim mode (thanks jsuppe 
> https://github.com/jsuppe) , add quick open files (ctrl+p) and quick open 
> editor (ctrl+alt+p) actions.
>
> LiteIDE Source code : https://github.com/visualfc/liteide
> Gotools Source code : https://github.com/visualfc/gotools
> Binary downloads : http://sourceforge.net/projects/liteide/files
> Latest downloads : http://git.oschina.net/visualfc/liteide/attach_files
>
> ### 2016.7.2 Ver X30
> * LiteIDE
> * add new QuickOpen plugin
> * add new FakeVim plugin, thanks for [jsuppe](
> https://github.com/jsuppe)
> * add custom env LITEIDE_TOOL_PATH/LITEIDE_PLUGIN_PATH/LITEIDE_RES_PATH
> * LiteApp
> * action tooltip shortcut show native text
> * option keyboard map show native text
> * QuickOpen
> * quick open files action CTRL+P
> * quick open editor action CTRL+ALT+P
> * quick go to line action CTRL+L
> * quick open help
> * FakeVim
> * editor add vim style mode editing
> * LiteEditor
> * add goto line start/end action
> * add goto doc start/end action
> * add goto previous/next line action
> * add goto previous/next charater action
> * add goto previous/next word action
> * change '' braces only go source
> * fix codecompleter number first
> * MacOS fix move line up/down shortcut command+shift+up/down
> * GolangEdit
> * CTRL+mouse navigate preview source info
> * LiteFind
> * MacOS fix edit replace shortcut command+shift+F
> * Welcome
> * fix doc css style
> * gotools
> * types fix limit parser
> * types simple field info
>  
>

-- 
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.7 Beta 2 is released

[paraiso . marc]

Thanks, is there a way to know what to expect in later versions ( 
1.8,1.9,1.10 and so forth ... ) ? 

Le vendredi 17 juin 2016 01:15:18 UTC+2, Chris Broadfoot a écrit :
>
> Hello gophers,
>
> We have just released go1.7beta2, a beta version of Go 1.7.
> It is cut from the master branch at the revision tagged go1.7beta2.
>
> Please help us by testing your Go programs with the release, and report 
> any problems using the issue tracker:
> https://golang.org/issue/new
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.7beta2
>
> To find out what has changed in Go 1.7, read the draft release notes:
> https://tip.golang.org/doc/go1.7
>
> Documentation for Go 1.7 is available at:
> https://tip.golang.org/
>
> Our goal is to release the final version of Go 1.7 on the 1st of August.
>
> Cheers,
> Chris
>

-- 
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: Testing best practice: passing and failing test

[paraiso . marc]

By the way, Go 1.7 support subtests :

https://tip.golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks

Which is one of the nicest additions to Go 1.7 

Le jeudi 16 juin 2016 16:04:11 UTC+2, Rayland a écrit :
>
> Let's say I have some piece of code like this:
>
> type Foo struct {
> }
>
> func (this *Foo) Do() {
> }
>
>
> If I want to test that method Foo will pass in a certain scenario and fail 
> in another scenario should I have a test for each scenario or should I have 
> all scenarios tested in a method TestFoo_Do()?
>
>
>
>

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

[go-nuts] Re: Currying in Go

[paraiso . marc]

What is the point of doing that in a language that doesn't support auto 
currying ? There is none. You are not currying anything by the way, you 
just wrote 3 closures. 

Le vendredi 17 juin 2016 00:00:43 UTC+2, Zauberkraut a écrit :
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. 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.