[go-nuts] Need some help on my basic "Backup size" calculator

[gioflux]

Hi there,

I'm very new to Golang, and quite honestly haven't coded in a long time so 
bear with me if this is an very basic question.

I'm trying to build a basic backup program, which will take a path (string) 
and then calculate the total "backup size" of the entire backup (and all 
the child folders, etc).

I found out by starting to write the basics of the program that 
ioutil.ReadDir does not recursively go deeper into child folders so the 
code I will show you is only calculating the size for any files in the root 
only.

I already have an idea on how to fix it but I have a much deeper question: 
would using nested structs be a good idea?

I'm basically defining the program like so:

type Backup struct {
Files
Directories
byteSize int64
humanSize string
}

type Directories struct {
name string
containsBytes float64
constainsFiles int64
}

type Files struct {
parent Directories
name string
byteSize int64
humanSize string
}

Do I need to make "Directories" and "Files" be a slice / map or something 
for my purposes? I am a little confused here and I don't know how I could 
make my struct (which holds multiple values) be an array/slice, how would 
that work?

What if I wanted to "search" for a file or folder later on my program? 

My code that works for top-level folder 
calculation: 
https://gist.github.com/TheLinuxGuy/2dd8ed958d14c491bf86e2f5f3d4688d

Thanks!
Giovanni

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[Egon]

On Monday, 5 June 2017 06:59:46 UTC+3, utyug...@mail.com wrote:
>
>
>
> On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote:
>>
>> I think you are missing the point of my comment.
>>
>> I'm all for generics, but I also can survive without them without much of 
>> a problem. (I'm even maintaining 
>> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4
>>  
>> to understand the problem better)
>>
>
> create a custom container type that I can use with any type out-of-the-box.
>
> for example: iset := make(Set[int],9); sset := make(Set[string],9); pset 
> := make(Set[Person]);
>
> right now, my solution is to rewrite the source with go generate calling a 
> tool i wrote which grew out from a great talk from robert griesemer. The 
> video: https://www.youtube.com/watch?v=vLxX3yZmw5Q
>
> This solution has nearly twice the performance increase over maps with 
> almost every type used so far. Now I could have just written the 500 lines 
> of code over and over again for every type needed until the end of time(or 
> copy and paste and edit until the end of time), or I could use empty 
> interfaces which throws type safety out the window, but I chose to write a 
> tool, and when go generate came to be I chose to use that tool like a 
> simple script executed within a '//go:generate go run..' tag.
>
>
> Over time golang(I do this now to annoy the zealots) provided the 
> tools(reflection, /go packages, go generate) that made creating custom 
> generic type safe containers easier. These things weren't always this easy, 
> and these things could be easier.
>
> And I am serious about create a custom container type that I can use with 
> any type out-of-the-box. Please indulge me, how would you solve this 
> problem. Provide a solution for a simple type-safe container type Set that 
> takes any type, with a simple api of 
> insert,remove,contain,union,difference,intersection, 
> complement,superset,subset.
>

I would use copy-paste. That action to specialize and clean-up API is 
pretty trivial, it might take me 3min (probably less), but it isn't a 
problem. I often spend more time on tweaking CSS or figuring out what the 
customer needs. Copy-pasteing code is annoying, but it's trivial low-effort 
work... so it's not a problem. *There of course are probably domains where 
this 3min might be a problem*. Then you might use a reflect/interface based 
solution and create a type-safe wrapper. Or use code-generation.

3min writing code, isn't a problem for me.

There's also a subtle problem here, I consider 
"insert,remove,contain,union,difference,intersection,complement,superset,subset"
 
API somewhat unclear... it loses domain knowledge and may provide more 
functions than strictyl necessary... this of course it depends on the 
context.

Also, where will this set be used? Set data-structures have a ton of 
different trade-offs. I really don't know how to write a really good 
general purpose Set. 
(see https://github.com/golang/go/wiki/HowToAsk#the-story-of-a-bad-question)

I've seen you provide solutions in the past, so I would like to see your 
> solution to this not-much-of-a-problem.
>
 
>
>>
>> The issue I was trying to highlight was that you are proposing solutions 
>> to a problem, but other people don't know what your exact problem is. Hence 
>> my 3 lines version are equivalent in their result and value, because the 
>> problem is missing.
>>
>> Similarly, when we don't have a concrete problem we could over-engineer 
>> the generics or alternatively solve the wrong problems.
>>
>> For example, when the solution you propose only solves 5% of the problems 
>> that generics needs to solve... or vice-versa... a generics solution 100x 
>> simpler would solve 99% of the cases... then what is the value of the 
>> proposed solution?
>>
>> So, which of the 147 different generics approaches/implementations works 
>> better for Go and why? (I'm also counting the ones that aren't known yet :D)
>>
>> When you would use a real-world example and problem, it would be possible 
>> to argue that one approach is better than the other... without one, this 
>> discussion doesn't lead to anywhere.
>>
>> + Egon
>>
>> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote:
>>>
>>> given the fact that actually everybody disagrees on that idea, 
>>> or even something similar according to some feedback.
>>>
>>> I want to put the question differently.
>>>
>>> My mean is to say that golang is a basis to build upon in general that 
>>> is better
>>> than other existing solutions.
>>>
>>> imho, golang is governed by its compatibility requirement,
>>> and, an extremely vertical approach,
>>> which blocks every possible update to the dogma: 
>>> is it go 1.0 compatible ?
>>>
>>> And because its vertical, is it to my taste ?
>>>
>>> The go 1.0 compatibility requirement makes everybody very happy.
>>>
>>> Still, I dont believe the language is considered as finalized by a 
>>> majority of users.
>>> Some will 

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[utyughjgut]

Why such a vicious attack? This type of behavior against those exploring 
generics in golang(i call Go this to spite the zealots) is a scourge gone 
uncheck for too long. No need for comments to be speckled with demeaning 
overtone.

On Friday, June 2, 2017 at 4:17:54 AM UTC-4, Florin Pățan wrote:
>
> Since everyone thinks it but nobody bothers to reply to it: this whole 
> thing you propose can be currently done with a for loop, which not only is 
> explicit about what it doing, but it also lets you control if you want to 
> exit early from it and so on. Complicating the whole language because 
> something is cool (yet looks like a really complex thing that you need to 
> think about while reading the code) is in no one's benefit. Stop trying to 
> avoid a couple of extra rows of for {} (where the third row is literally 
> just an "}")  and start embracing the fact that you can understand the code 
> by looking at it and not apply any complex mental acrobatics to figure out 
> what those three lines of code are doing. Your future self/person after you 
> will thank you for 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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[utyughjgut]

On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote:
>
> I think you are missing the point of my comment.
>
> I'm all for generics, but I also can survive without them without much of 
> a problem. (I'm even maintaining 
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4
>  
> to understand the problem better)
>

create a custom container type that I can use with any type out-of-the-box.

for example: iset := make(Set[int],9); sset := make(Set[string],9); pset := 
make(Set[Person]);

right now, my solution is to rewrite the source with go generate calling a 
tool i wrote which grew out from a great talk from robert griesemer. The 
video: https://www.youtube.com/watch?v=vLxX3yZmw5Q

This solution has nearly twice the performance increase over maps with 
almost every type used so far. Now I could have just written the 500 lines 
of code over and over again for every type needed until the end of time(or 
copy and paste and edit until the end of time), or I could use empty 
interfaces which throws type safety out the window, but I chose to write a 
tool, and when go generate came to be I chose to use that tool like a 
simple script executed within a '//go:generate go run..' tag.


Over time golang(I do this now to annoy the zealots) provided the 
tools(reflection, /go packages, go generate) that made creating custom 
generic type safe containers easier. These things weren't always this easy, 
and these things could be easier.

And I am serious about create a custom container type that I can use with 
any type out-of-the-box. Please indulge me, how would you solve this 
problem. Provide a solution for a simple type-safe container type Set that 
takes any type, with a simple api of 
insert,remove,contain,union,difference,intersection, 
complement,superset,subset.

I've seen you provide solutions in the past, so I would like to see your 
solution to this not-much-of-a-problem.
 

>
> The issue I was trying to highlight was that you are proposing solutions 
> to a problem, but other people don't know what your exact problem is. Hence 
> my 3 lines version are equivalent in their result and value, because the 
> problem is missing.
>
> Similarly, when we don't have a concrete problem we could over-engineer 
> the generics or alternatively solve the wrong problems.
>
> For example, when the solution you propose only solves 5% of the problems 
> that generics needs to solve... or vice-versa... a generics solution 100x 
> simpler would solve 99% of the cases... then what is the value of the 
> proposed solution?
>
> So, which of the 147 different generics approaches/implementations works 
> better for Go and why? (I'm also counting the ones that aren't known yet :D)
>
> When you would use a real-world example and problem, it would be possible 
> to argue that one approach is better than the other... without one, this 
> discussion doesn't lead to anywhere.
>
> + Egon
>
> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote:
>>
>> given the fact that actually everybody disagrees on that idea, 
>> or even something similar according to some feedback.
>>
>> I want to put the question differently.
>>
>> My mean is to say that golang is a basis to build upon in general that is 
>> better
>> than other existing solutions.
>>
>> imho, golang is governed by its compatibility requirement,
>> and, an extremely vertical approach,
>> which blocks every possible update to the dogma: 
>> is it go 1.0 compatible ?
>>
>> And because its vertical, is it to my taste ?
>>
>> The go 1.0 compatibility requirement makes everybody very happy.
>>
>> Still, I dont believe the language is considered as finalized by a 
>> majority of users.
>> Some will say it misses generics, some other (..) will try different 
>> approach.
>>
>> Why should it be that much of frictions ?
>>
>> Why can t we evaluate a solution where multiple vision co exists ?
>> Handle the change.
>>
>> Aint there existing case of such kind of symbiosis which benefits each 
>> other on the long term ?
>>
>> A solution where the go 1.0 requirement is kept valuable, 
>> and a new language target where this requirement has been removed.
>> A transpiler to go 1.0 compatible code ? 
>> So both can exist ?
>>
>> my 2 cents, 
>> that close and negative answer i got,
>> is not helpful nor inclusive,
>> its like take or leave attitude,
>>
>> it d just be more inclusive to say that 
>> it is ok to make a transpiler/or whatever it should be/ implementing your 
>> idea, 
>> check that resource for further implementation come back here for 
>> questions.
>>
>> Other consideration, 
>> the idea that golang 1.0 is used to build a different language target 
>> that compiles back to go1.0, 
>> looks cool.
>>
>> On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote:
>>>
>>> for the fun, with early return,
>>>
>>> https://play.golang.org/p/I9AORKOYQm
>>>
>>> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:

[go-nuts] Re: "cannot allocate memory" problem

[Dmitry Mishin]

I figured it. My exec.Command's were leaving a bunch of zombie processes. 
Had to do cmd.Wait() on them to exit cleanly.

On Thursday, June 1, 2017 at 9:25:51 PM UTC-7, Dmitry Mishin wrote:
>
> I have the same impression...
>
> Added a 300 msec sleep before each folder read task. Will see how it goes, 
> maybe that will let the OS recover whatever resources it's missing...
>
> Thanks for your help!
>
> On Thursday, June 1, 2017 at 8:09:14 PM UTC-7, Dave Cheney wrote:
>>
>> Imo this is not a problem with the amount of memory in use inside you go 
>> program, but Linux's incorrect accounting.
>
>

-- 
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] gob's interpreted machine

[Ian Lance Taylor]

On Sat, Jun 3, 2017 at 9:10 AM, Santhosh Ram Manohar
 wrote:
> From https://blog.golang.org/gobs-of-data
>
> "The first time you encode a value of a given type, the gob package builds a
> little interpreted machine specific to that data type. It uses reflection on
> the type to construct that machine, but once the machine is built it does
> not depend on reflection."
>
> Is there any detailed info on how this interpreted machine is built and used
> ?

See the "Encoding Details" section in https://golang.org/pkg/encoding/gob .

Ian

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

[go-nuts] Re: CORS error when using Gorilla Mux

[Oren]

update: to only allow ajax requests from my domains I modify the code:

w.Header().Set("Access-Control-Allow-Origin", "https://foo.my-domain.com;)
w.Header().Set("Access-Control-Allow-Origin", "https://bar.my-domain.com;)
w.Header().Set("Access-Control-Allow-Origin", "http://localhost:8080)




On Sunday, June 4, 2017 at 7:54:17 AM UTC-7, Oren wrote:
>
> Any ideas why I get '403: forbidden' when making CORS request to my web 
> service? 
> https://github.com/oren/doc-api/blob/dc332507e3a9c5f36a2de6430ec6bf811ffcbd4e/cmd/web/server.go#L90
>
> I am using gorilla mux:
> ```
> corsObj := handlers.AllowedOrigins([]string{"*"})
> log.Fatal(http.ListenAndServe(":3000", handlers.CORS(corsObj)(r)))
> ```
>
> Here are more details from the chrome dev tools console:
>
> General:
> Request URL:http://localhost:3000/adminlogin
> Request Method:OPTIONS
> Status Code:403 Forbidden
> Remote Address:[::1]:3000
> Referrer Policy:no-referrer-when-downgrade
>
> Request Headers:
> Accept:*/*
> Accept-Encoding:gzip, deflate, sdch, br
> Accept-Language:en-US,en;q=0.8
> Access-Control-Request-Headers:content-type
> Access-Control-Request-Method:POST
> Connection:keep-alive
> DNT:1
> Host:localhost:3000
> Origin:http://localhost:8080
> Referer:http://localhost:8080/login
>
> 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: How to compare two network addresses (stringifyed or not) for equality?

['Константин Иванов' via golang-nuts]

Ah, hell. Sorry, sorry, sorry. "[::]" is just ipv6 version of "0.0.0.0". 
Okay. Hah, and I can to use "[::0:0:1]:9090" or "[::0:1]:9090" or 
"[::1]:9090" and it will work. Hah, thank you man! Thank for you time.

воскресенье, 4 июня 2017 г., 18:32:42 UTC+3 пользователь Silviu Capota Mera 
написал:
>
> Hi
>
> I think you wanted return ahost == bhost (instead of aport == bport) 
> inside the addrCmp function, right ? Because the client is always assigned 
> a random port for a TCP connection 
>
> And of course, you will have to compare at nc (net.Conn) level, not at 
> listener level, especially when listening on a generic [::]
>
> e.g.
> go func() {
> for {
> nc, err := l.Accept()
> if err != nil {
> log.Fatal("accept fatal: ", err)
> }
> // This is the address you need to compare with
> connectionSpecificAddr := nc.LocalAddr().String()
> connRemoteAddr := nc.RemoteAddr().String()
> fmt.Println("Listener local addr: ", connectionSpecificAddr)
> fmt.Println("Listener remote addr: ", connRemoteAddr)
> fmt.Println(addrCmp(connectionSpecificAddr, connRemoteAddr))
>
> }
> }()
>
> Cheers,
> Silviu
>
>
>
> On Saturday, 3 June 2017 23:29:24 UTC-4, Константин Иванов wrote:
>>
>> Here is a code:
>>
>> package main
>>
>> import (
>> "fmt"
>> "log"
>> "net"
>> )
>>
>> func main() {
>>
>> l, err := net.Listen("tcp", "[::]:9090")
>> if err != nil {
>> log.Fatal(err)
>> }
>> defer l.Close()
>>
>> go func() {
>> for {
>> l.Accept()
>> }
>> }()
>>
>> c, err := net.Dial("tcp", "[::]:9090")
>> if err != nil {
>> log.Fatal(err)
>> }
>> defer c.Close()
>>
>> fmt.Println(l.Addr().String())
>> fmt.Println(c.RemoteAddr().String())
>>
>> fmt.Println(addrCmp(l.Addr().String(), c.RemoteAddr().String()))
>> }
>>
>> func addrCmp(a, b string) bool {
>> if ahost, aport, err := net.SplitHostPort(a); err == nil {
>> if bhost, bport, err := net.SplitHostPort(b); err == nil {
>> if net.ParseIP(ahost).Equal(net.ParseIP(bhost)) {
>> return aport == bport
>> }
>> }
>> }
>> return false
>> }
>>
>> Output is:
>>
>> [::]:9090
>> [::1]:9090
>> false
>>
>> Is there an easy way to compare two net.Addr or two strings that 
>> represents network addresses?
>>
>

-- 
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: CORS error when using Gorilla Mux

[Oren]

I solved with the following:

package main


import (
 "log"
 "net/http"


 "github.com/gorilla/mux"
)


func corsMiddleware(next http.Handler) http.Handler {
 return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 log.Println("Executing middleware", r.Method)


 if r.Method == "OPTIONS" {
 w.Header().Set("Access-Control-Allow-Origin", "*")
 w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PATCH, PUT, 
DELETE, OPTIONS")
 w.Header().Set("Access-Control-Allow-Headers:", "Origin, Content-Type, 
X-Auth-Token, Authorization")
 w.Header().Set("Content-Type", "application/json")
 return
 }


 next.ServeHTTP(w, r)
 log.Println("Executing middleware again")
 })
}


func adminLogin(w http.ResponseWriter, r *http.Request) {
 log.Println("Executing adminLogin")
 w.Write([]byte("adminLogin"))
}


func allClinics(w http.ResponseWriter, r *http.Request) {
 log.Println("Executing allClinics")
 w.Write([]byte("allClinics"))
}


func main() {
 r := mux.NewRouter()
 r.HandleFunc("/adminlogin", adminLogin).Methods("POST")
 r.HandleFunc("/clinics", allClinics).Methods("GET")
 log.Fatal(http.ListenAndServe(":3000", corsMiddleware(r)))
}


// curl localhost:3000/clinics -v
// curl -X POST localhost:3000/adminlogin -v




On Sunday, June 4, 2017 at 7:54:17 AM UTC-7, Oren wrote:
>
> Any ideas why I get '403: forbidden' when making CORS request to my web 
> service? 
> https://github.com/oren/doc-api/blob/dc332507e3a9c5f36a2de6430ec6bf811ffcbd4e/cmd/web/server.go#L90
>
> I am using gorilla mux:
> ```
> corsObj := handlers.AllowedOrigins([]string{"*"})
> log.Fatal(http.ListenAndServe(":3000", handlers.CORS(corsObj)(r)))
> ```
>
> Here are more details from the chrome dev tools console:
>
> General:
> Request URL:http://localhost:3000/adminlogin
> Request Method:OPTIONS
> Status Code:403 Forbidden
> Remote Address:[::1]:3000
> Referrer Policy:no-referrer-when-downgrade
>
> Request Headers:
> Accept:*/*
> Accept-Encoding:gzip, deflate, sdch, br
> Accept-Language:en-US,en;q=0.8
> Access-Control-Request-Headers:content-type
> Access-Control-Request-Method:POST
> Connection:keep-alive
> DNT:1
> Host:localhost:3000
> Origin:http://localhost:8080
> Referer:http://localhost:8080/login
>
> 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: Newbie How to read unmarshall a varient struct in Json

[Amnon Baron Cohen]

Thanks for bringing the article to my attention.
The final section "*Encoding and decoding generics*" was exactly what I was 
looking for.


On Sunday, 4 June 2017 12:53:42 UTC+1, Jon Calhoun wrote:
>
> See the last section of this article where it talks about generics - 
> https://blog.gopheracademy.com/advent-2016/advanced-encoding-decoding/
>
> It isn't exactly what you are doing but the same idea should work in your 
> use case. The encoding/decoding code becomes longer but it makes using the 
> data simpler. 
>

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

Re: [go-nuts] CGO & Plugins

[Ian Lance Taylor]

On Sun, Jun 4, 2017 at 3:01 AM, dc0d  wrote:
>
> Some clarifications on future of plugins would be nice though.

To be honest I thought plugins would have fewer problems than they
would up having.  And in any case the API seems fine, so any reworking
can preserve the API.

I think the future of plugins is that someone needs to take a step
back and think through all the issues that have been discovered and
figure out whether, and how, they can be addressed.  That person is
not going to be me.

Ian

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

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

given the fact that actually everybody disagrees on that idea, 
or even something similar according to some feedback.

I want to put the question differently.

My mean is to say that golang is a basis to build upon in general that is 
better
than other existing solutions.

imho, golang is governed by its compatibility requirement,
and, an extremely vertical approach,
which blocks every possible update to the dogma: 
is it go 1.0 compatible ?

And because its vertical, is it to my taste ?

The go 1.0 compatibility requirement makes everybody very happy.

Still, I dont believe the language is considered as finalized by a majority 
of users.
Some will say it misses generics, some other (..) will try different 
approach.

Why should it be that much of frictions ?

Why can t we evaluate a solution where multiple vision co exists ?
Handle the change.

Aint there existing case of such kind of symbiosis which benefits each 
other on the long term ?

A solution where the go 1.0 requirement is kept valuable, 
and a new language target where this requirement has been removed.
A transpiler to go 1.0 compatible code ? 
So both can exist ?

my 2 cents, 
that close and negative answer i got,
is not helpful nor inclusive,
its like take or leave attitude,

it d just be more inclusive to say that 
it is ok to make a transpiler/or whatever it should be/ implementing your 
idea, 
check that resource for further implementation come back here for questions.

Other consideration, 
the idea that golang 1.0 is used to build a different language target that 
compiles back to go1.0, 
looks cool.

On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote:
>
> for the fun, with early return,
>
> https://play.golang.org/p/I9AORKOYQm
>
> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:
>>
>> > Generics enable more than just replacing loops. For example, they can 
>> enable libraries of generic algorithms to be used with any type of array. 
>> Here's an example:
>>
>> in my demonstration every type got this kind of method,
>> the problem become how do you jump from Type A to type B.
>> in []A to []B or A -> B
>>
>> indeed it works on the item level, no more on the collections.
>>
>> This question is solved in two ways,
>> - interface definitions (not interface value)
>> - static conversion, which always resumes to 
>> func(in-type) out-type
>>
>> and some alternatives for convenience (producer/consumer)
>> func (func(in-type) out-type
>> func (in-type) func() out-type
>> func (func(in-type) func() out-type
>> // this is unfinished explanation it should include error management to 
>> be handled more completely. see please previous conv() fn introduced 
>> earlier to statically re decorate a func signature.
>>
>> So far the sum/reduce things operation,
>> i left them as exercise to the stream declarer
>> and did not consider them as core.
>> Take become => filter (func(10 elements))
>> Map is map
>> Sort is All(fn sorter) []out
>> Reduce is a map operation, preceded by a conv if it reduces to a 
>> different type.
>>
>>
>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
>> wrote:
>>>
>>> Generics enable more than just replacing loops. For example, they can 
>>> enable libraries of generic algorithms to be used with any type of array. 
>>> Here's an example:
>>>
>>> foo := GetArray()
>>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>>
>>> That is simple to understand and in one line of code. Imagine the 
>>> acrobatics (and lines of code) needed to do this using Go's loops!
>>>
>>> You can read my full article on why Go needs generics here: 
>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>>
>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:

 Since everyone thinks it but nobody bothers to reply to it: this whole 
 thing you propose can be currently done with a for loop, which not only is 
 explicit about what it doing, but it also lets you control if you want to 
 exit early from it and so on. Complicating the whole language because 
 something is cool (yet looks like a really complex thing that you need to 
 think about while reading the code) is in no one's benefit. Stop trying to 
 avoid a couple of extra rows of for {} (where the third row is literally 
 just an "}")  and start embracing the fact that you can understand the 
 code 
 by looking at it and not apply any complex mental acrobatics to figure out 
 what those three lines of code are doing. Your future self/person after 
 you 
 will thank you for 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] Newbie How to read unmarshall a varient struct in Json

[Jon Calhoun]

See the last section of this article where it talks about generics - 
https://blog.gopheracademy.com/advent-2016/advanced-encoding-decoding/

It isn't exactly what you are doing but the same idea should work in your use 
case. The encoding/decoding code becomes longer but it makes using the data 
simpler. 

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

I feel much better with this, 
than its counter part,
but what s the point, this is so much about a personal opinion.

func (p PackageInfo) DeepEmbeddeds(structName string) (ret StringSlice) {
strut := p.GetStruct(structName)
if strut.GetName() == structName {
e := strut.Embeddeds()
e.Filter(p.IsInterface).Each(ret.Append)
e.Filter(p.IsStruct).Each(func(s string) {
p.DeepEmbeddeds(s).Each(ret.Append)
})
}
return 
}

Ain t exactly what i want, 
still can t convert with ease,
but so much clearer.

If you put performance issue aside,
i feel like the only argument opposed so far 
is a about 
- a somehow more complex code,
- a subjective matter of taste.

for 1, take a look at SO and newbies questions
about chan, you should have some fun.
fun² I remember some trying to build very similar constructs on top of chan.

for 2,
2.1 YOLO, i want better structure to program faster, i might not be doing 
the right thing because i ain t yet understood the language correctly, yet, 
i want to benefit the whole environment provided by it, ultimately, that i 
m right or wrong, does not matter in the immediate terms of getting 
productive, i m only looking for ways to program faster by reducing all 
those additional constructs.

In other words, 
I want to trade *write speed* Vs *write clarity*.

See also that unwinding such constructs, when its not non sense, is trivial.
Thus, if you do a performance analysis and you find that construct in a hot 
path, you can tell, 
lets unwind it.

2.2 blah, if google wants to try to rule the world
with its internal guideline book, 
well it look likes it might keep trying,
users will still look for this kind of structure, i believe.

Down that path, the question does not become,
what s acceptable for my guidelines book,
but,
how i can best handle user needs, 
provides what s needed to avoid a disaster with the tools given by the 
language.

Anyway, if golang is to be successful (I mean like java), 
i don t doubt that down the road 
it will come to something similar, 
with generics, or not.

gettin' the pop corn : )

On Saturday, June 3, 2017 at 6:35:49 PM UTC+2, Egon wrote:
>
> On Saturday, 3 June 2017 13:11:04 UTC+3, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> yes generics / not generics.
>>
>> That is, in what i proposed, only the consumer is enhanced, thus generics 
>> are not required anymore on the declarer, except for this conv method, 
>> indeed.
>>
>> also as the declarer can rely on more powerful tool on the consumer, 
>> it needs to declare less to able more.
>>
>> That being said,
>>
>> Can you take a look to that, genericity less, it works
>>
>> https://gist.github.com/mh-cbon/2062efef48e246592bdb0665f0ab8547
>>
>> IMHO, its simple, it does what i need, it helps me to avoid obvious 
>> gotchas,  after many attempt i feel satisfy, 
>> please critic it.
>>
>
> I think this version is much clearer: https://play.golang.org/p/9DfxObeDj3 
> :P
>  
>
>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
>> wrote:
>>>
>>> Generics enable more than just replacing loops. For example, they can 
>>> enable libraries of generic algorithms to be used with any type of array. 
>>> Here's an example:
>>>
>>> foo := GetArray()
>>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>>
>>> That is simple to understand and in one line of code. Imagine the 
>>> acrobatics (and lines of code) needed to do this using Go's loops!
>>>
>>> You can read my full article on why Go needs generics here: 
>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>>
>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:

 Since everyone thinks it but nobody bothers to reply to it: this whole 
 thing you propose can be currently done with a for loop, which not only is 
 explicit about what it doing, but it also lets you control if you want to 
 exit early from it and so on. Complicating the whole language because 
 something is cool (yet looks like a really complex thing that you need to 
 think about while reading the code) is in no one's benefit. Stop trying to 
 avoid a couple of extra rows of for {} (where the third row is literally 
 just an "}")  and start embracing the fact that you can understand the 
 code 
 by looking at it and not apply any complex mental acrobatics to figure out 
 what those three lines of code are doing. Your future self/person after 
 you 
 will thank you for 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.

Re: [go-nuts] Re: How to parallelize text/template long running functions?

[Simon Ritchie]

I was puzzled by something you said earlier:

> The template is the only entity that knows exactly which data from the 
data set is needed.

You've just given a bit more information, but I still don't quite 
understand.

You have some C code that you don't control and it's producing some 
information.  You have some Go which is executing a template. You say that 
the template has access to some data that the rest of the Go application 
doesn't have. 

A template is really just a function expressed in a rather opaque 
language.  The Go application invokes this function by calling the execute 
method, passing a destination and some data.  The function glues together 
the text in the template and the data, creates a piece of text and sends it 
to the destination.   While it is doing that, it can call other functions, 
so if it has a piece of data that the rest of the application doesn't have, 
it can call a function to hand it back. 

Fundamentally, the template is part of your Go application, it's just 
expressed in a cranky language that was only ever designed to describe how 
to render some text.  So I don't understand how your template can be 
holding a piece of data that the rest of the application can't get at.

That cranky language is the reason why lots of people think what you are 
doing is a bad idea.  The conventional wisdom is that a template should be 
very simple.  You should do as much processing as possible in Go before you 
call the template, and pass the results to the template as data.  Your 
application will be much easier to maintain if you do that.

Put simply, if your template code can get hold of some data, I don't 
understand why your Go code can't get hold of the same data, given that the 
template code and the Go are part of the same application.

If this is an HTTP client/server system, the template produces an HTTP 
response, perhaps some HTML, and sends to a web browser to be rendered.  
The web browser could be holding some data that the application doesn't 
have, but that's not the template, it's the client, and there are lots of 
ways to get data from a client to a server.

Can you explain the problem you have in a bit more detail?

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

Re: [go-nuts] CGO & Plugins

[dc0d]

Thanks for the post! I don't think those caveats could be a setback.

Some clarifications on future of plugins would be nice though.

On Saturday, June 3, 2017 at 6:32:22 PM UTC+4:30, Nick Groenen wrote:
>
> On 2017-06-02  19:24:40, Michael Brown wrote: 
> >Do you have any references on the stability of the current plugin system 
> >that I can use for reference? I'm building a system now that I 
> contemplate 
> >using with some plugins and I'd like to know up front the challenges. 
>
> I wrote a blogpost on plugins earlier this year. The "caveats" section 
> has some remarks and references you might find interesting in this 
> context. 
>
> You can find it at 
> https://nick.groenen.me/posts/2017/01/09/plugins-in-go-18/ 
>
> -- 
> Nick Groenen 
> https://nick.groenen.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.