Re: [go-nuts] [ANN] Edit - Acme command language

[as . utf8]

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

I wasn't aware of up to four horsemen being involved. The man pages didn't 
prepare me for this.

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

[go-nuts] Re: Go channels overused and hyped?

[as . utf8]

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

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

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

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

[go-nuts] [ANN] Edit - Acme command language

[as . utf8]

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

github.com/as/edit

Reference

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

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

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

[as . utf8]

Threads are the structural and functional loci of execution on some operating 
systems, data stored in a box accessible to each thread makes sense when you 
obey the constraint that the things in that box are to be used for that thread 
exclusively. 

Goroutines are different, they function like threads but have different 
structure. Structurally, they are not intended to preserve state accessible to 
the user. Goroutines are light, and I suspect that the idiom of goroutine local 
storage is incompatible to the design of the language: anonymous loci of flow 
control communicating through channels as conduits. 

If I could wish for an idiom taken from operating systems, TLS/GLS wouldn't be 
my first choice. I see namespaces serving a similar role on Plan9. The ability 
to share a namespace with the child or parent process. Namespaces include the 
environment and allow the caller too configure what resources a process has 
access to upon execution. Such an addition would also violate the unwritten 
rule of anonymous processes, but context is already doing that. The difference 
is that context is based on what is being executed (what function is called) 
and not where (which goroutine). Contexts are like function namespaces. They 
even have a map of arbitrary key-values. 

The exercise is to find a way to make this feel natural to the language, and 
apply such an approach to functions instead of processes, threads, or 
goroutines.

-- 
You received this message because you are subscribed to 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] [Blog] Context should go away for Go 2

[as . utf8]

I also dont want to see context everywhere. At the same time, I don't want it 
to be obfuscated in a confusing way. 

ctx is an unfortunate initialism and context.Context package stuttering doesn't 
help. 

I suppose you could stuff a pointer on the stack pointing to a potential 
context and then provide a built-in to access this structure. But that already 
sounds confusing and easy to ignore, and you've added a few bytes of overhead 
to each function call by providing an auxillary argument to every function and 
method.

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

[go-nuts] Re: Generics are overrated.

[as . utf8]

I'm hesitant to accept generics due to the fear of *overloaded operators *being 
the next big deal*. *C# even has *properties (user-defined methods 
dispatched upon an assignment operation)*. 

-- 
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: gitcreepy – get GitHub users' previous email addresses from all their historical commits!

[as . utf8]

This information is actually stored in the git commits themselves. There is 
a zlib'd field that contains the author's name and email address for each 
commit in the repo. A complete transcript for every commit can be 
reconstructed from a git repo in this manner.

On Saturday, July 15, 2017 at 5:58:59 PM UTC-7, nosequeldeebee wrote:
>
> https://github.com/nosequeldeebee/gitcreepy
>
> It's stunning how much personal information you can get from Github users 
> through its developer APIs. In addition to profile information, a list of 
> every email address they've used in historical public commits can be 
> extracted. Many users sign up for Github with their personal email 
> addresses and only obfuscate them after they've made public commits, 
> which imprints them in the public record!
>

-- 
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: Is x/exp/shiny dead?

[as . utf8]

It's not ready for general use, but it certainly isn't dead. I think a lack 
of examples for some of the more-complex widgets is probably where it needs 
the most help, but considering that only one person is working on it the 
result is a very impressive addition to the Go ecosystem. I've not used the 
widgets much, and ended up porting/reimplementing 
 Plan 9's libframe due to my inability to 
understand how to get editable text on the screen. This was over a year 
ago, so things may have changed. I agree with the general consensus, 
standard widgets are the biggest obstacle for exp/shiny, but those require 
effort to be ported, and maybe copying what already exists isn't the best 
approach either.

On Monday, July 31, 2017 at 1:25:02 PM UTC-7, fazal wrote:
>
> It was one of the things I was looking forward to, but I see almost no 
> activity there, which makes me sad. 
>
> Is it because it is mature enough for general use? There is a road-map for 
> widgets but non are complete. I really hope it is not abandoned because Go 
> really needs a GUI library that is idiomatic. 
>
> 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: Disadvantage of Go

[as . utf8]

To sacrifice simplicity of readability for simpler writing is to have never 
been tasked with reading a 25kloc C# project and having to open 10 windows 
just for the object-oriented pyramid of generic abstract partial template 
class factories

 

On Thursday, January 12, 2017 at 11:44:10 PM UTC-8, hui zhang wrote:
>
> Disadvantage of Go
> 1  No Generic For Now
> That make user coding repeat code many times, even for basic type such as 
> int float bool
> It is not easy , even to make a generic min function.
> using interface will always check type casting.
> and for []interface{} in generic function, u can't do cast
>
> 2   Incomplete  Type  in Basic Lib
> Take math lib as an example,   math.Max math.Min are only for float64 , 
> you have do stupid conversion for other type.
>
> 3  No Default Value for struct.
> Consider multilayer struct.   A {B {C {D {E {F} } } } 
> to init A to a default value will be complicated.
> And how about  A[] slice
> And what if D E F are from third party lib ?  
> You have to dig into 3rd party code just for its default value. 
> For It may have none zero default value.
>
> 4 Can not Cycle import.
> package A B can not import each other at the same time. 
> While other language can.
> It seems not a big deal just put the the common thing in a new package
> But when the package and project grow bigger, it just easy to say.
> This change will affect all caller.
>
> 5  Inconsistent type conversion 
> bool type are normal type just like int and float , 
> but u can't do below.  while other type can cast to others
> int(bool) bool(int) 
>
>
> 6  No multi casting expression
> func foo() (int16, int8)
> var i,j int32 = (int32,int32)(foo())
> Since go can't do this, why go provide multi return value.
>
> 7 No Ternary Expression
> hardly find a language without it except go
>
> 8 No Negative Index for slice 
> all other script language support a[-1] as a[len(a)-1]
>
>
> When programing in go 
> we have to do repeated type casting many times, due to the above.
> write long code for Ternary ,int(bool) a[-1] etc
> init big struct with default value.
> Which make Go not an Elegant and simple language.
> Once I thought go was a simple language, 
> but in fact we write more code.
>
> All above are proposal for many times. 
> And it is 6 years(or more).
> These basic functions are still not added. some of that should be add in 
> version 1.0
> I belive most above could make go simpler, 
> someone know  a little programing could know how to use it.
> however someone still fear it make go complicate like c++ 
>

-- 
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: shiny: get mouse position relative to window

[as . utf8]

I haven't seen this either, the solution depends on what platform you're 
trying to support. 

I have a package that does this, for Win32. If you're using Windows, you 
use the the Rect() or ClientAbs() in my package to get the position of the 
window (or the client area).

https://godoc.org/github.com/as/ms/win


On Saturday, January 14, 2017 at 8:47:17 AM UTC-8, kty...@gmail.com wrote:
>
> How do I get the position for a mouse.Event in shiny using 
> golang.org/x/mobile/event.mouse?
>
> The position returned is the global position on the screen, which changes 
> if I move the window.
> The comments in 
> https://github.com/golang/mobile/blob/master/event/mouse/mouse.go#L18 say 
> it's:
> "// X and Y are the mouse location, in pixels.". It doesn't mention if 
> they are relative to the screen or the window.
>
> How do I get the position relative to the window?
> Or is it an error of the driver (I'm using windows)?
> Neither shiny.Screen nor shiny.Window have methods to get the current 
> position of the window.
>
> Example:
> https://github.com/ktye/maps/blob/master/cmd/map/main.go#L101
>

-- 
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] Deleting the /r/golang subreddit

[as . utf8]

I don't use the site, nor understand how any immediate conflicts of interest 
can manifest based on the CEO's actions that justify removing the subreddit or 
locking it down.

Why not add a community to the official golang.org site and let the subreddit 
die of natural causes? It would be a favorable outcome if Reddit ever 
disappeared in the future to the hand of some other site: no content would need 
to be moved and the language's community posts would be self-contained.

-- 
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] Small complete examples which show the power of Go?

[as . utf8]

It's shorter, but it's harder for me to grasp what it does as easily as the 
first example.

On Wednesday, August 10, 2016 at 2:09:58 AM UTC-7, Anmol Sethi wrote:
>
> You can shorten that by 6 lines 
>
> package main 
>
> import "net/http" 
>
> func main() { 
> http.ListenAndServe(":8080", http.HandlerFunc(func(w 
> http.ResponseWriter, r *http.Request) { 
> w.Write([]byte("Hello World!")) 
> })) 
> } 
>
> A bare bones web server in just 9 lines! 
>
> > On Aug 10, 2016, at 3:53 AM, gary.wi...@victoriaplumb.com  
> wrote: 
> > 
> > Hi, 
> > 
> > I'm giving a talk at work introducing Go and I'm looking for small 
> examples to show Go's potential. For example, the following program 
> demonstrates a bare-bones webserver in 13 lines: 
> > 
> > import ( 
> > 
> > "fmt" 
> > "net/http" 
> > ) 
> >   
> > func home(w http.ResponseWriter, r *http.Request) { 
> > fmt.Fprintf(w, "Hello, world!") 
> > } 
> >   
> > func main() { 
> > http.HandleFunc("/", home) 
> > http.ListenAndServe(":8080", nil) 
> > } 
> > 
> > Has anyone here got any more little snippets like this to show the power 
> and potential of Go? It doesn't have to be in networking, just little a 
> little snippet to make people think "wow, that's cool!". 
> > 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

[go-nuts] Re: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

[as . utf8]

This is just a guess based on the origins of the language, but the design 
decision probably stems from a dim view of symbolic links. They are seen as 
ugly hacks that carry persistent state on the filesystem instead of a 
higher control plane such as a per-process namespace. The path variable 
approximates this by being settable by an individual shell process, whereas 
a symlink would affect every process on the system accessing the disk.

On Tuesday, July 12, 2016 at 1:05:36 PM UTC-7, jsej...@gmail.com wrote:
>
> Don't read this as a complaint. I'm trying to get feedback from code 
> reviewers about the design decision regarding this behavior of the 
> installer.
>
> In my experience, most software for OS X that installs cli components 
> installs to /usr/local/ and then creates symbolic links to executables in 
> /usr/local/bin/, as not to modify my $PATH. However, the Go installer 
> differs in approach by creating a new entry in /etc/paths.d/ for 
> path_helper 
> 
>  
> to read and then modify my $PATH. Can someone please explain the thinking 
> behind this design decision? Is it more common on Linux to have a lot of 
> path additions instead of symbolic links to executables? Was this something 
> that was discussed and decided upon by the core team or just an arbitrary 
> decision?
>
> I'd love to get a better understanding of why this choice. I have never 
> seen another software take this approach.
>
>
> 
>
>

-- 
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: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

>
> I wish I could be pointed to such discussion.
>

It was briefly discussed in *The Go Programming Language *book by Donovan & 
Kernighan (p 132)

*:*

> An analogous “shallow” equality test for slices could be useful, and it 
> would solve the problem with maps, but the inconsistent treatment of slices 
> and arrays by the == operator would be confusing. The safest choice is to 
> disallow slice comparisons altogether. 


Given this program, how would you modify it to include interfaces?

https://play.golang.org/p/9-rhDCZol_



On Sunday, July 3, 2016 at 2:37:45 PM UTC-7, Chad wrote:
>
> I wish I could be pointed to such discussion.
>
>> The language authors omitted this functionality for a reason. One of the 
>> reasons is that arrays and slices are similar, and changing their 
>> comparison semantics seemed confusing.
>>
>
>  https://blog.golang.org/slices specifically mentions that arrays and 
> slices are not similar. The spec does as well. Currently, slices do NOT 
> compare. I am simply arguing that they could very logically.
>
> The "==" operator is only overloaded in the case of strings currently but 
> that's truly an implementation detail. Strings are values but their 
> implementation is of a reference type. To get the value behaviour back, the 
> comparison is weakened to only take into account the underlying array 
> values and not where they are located. This probably for optimisation 
> purposes. 
>
> Other than that, there is a whole consistency to the language and how it 
> works. I simply would like that consistency extended.
>
> My main argument is that without specifying the logical "comparison" 
> behaviour for all reference types,* interface comparisons become unsafe*. 
> It's perhaps even a *bug*.
>
> N.B. I gave my definition of a reference type which is the definition I 
> would choose for Go. It does not have to be identical to what is found in 
> other languages. In any case, there probably needs to be a way to 
> distinguish between types that hold a reference to another datastructure 
> from those that don't.
>
>

-- 
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: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

I was being facetious. You have the right to opine, but elevating opinions 
to that of proofs doesn't give the discussion any utility. I think you 
should consider the underlying assumptions in some of your points: 

1. A slice is a descriptor of an aggregate
2. A struct can resemble a descriptor of an aggregate.
3. A struct can resemble a slice
4. If a slice can be compared as a struct holding a descriptor, then maps 
can have slices as keys
5. Because it benefits this use case, it is a good feature to add to the 
language

Enumerating the drawbacks of this feature is more useful than trying to 
justify its existence. The language authors omitted this functionality for 
a reason. One of the reasons is that arrays and slices are similar, and 
changing their comparison semantics seemed confusing.  

On Sunday, July 3, 2016 at 11:32:39 AM UTC-7, Chad wrote:
>
> Pardon?
>
> On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as@gmail.com wrote:
>>
>> Hardcoded proofs should be assigned well-named identifiers. If you ever 
>> have to alter them, you don't want to be rummaging around your lemmas and 
>> corollaries.
>>
>> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>>>
>>> Ok. That "haha" was merely to show that no animosity was borne. And also 
>>> because you didn't really answer the question as I asked (by quoting the 
>>> spec) which I found funny.
>>>
>>> Alas, I guess we couldn't see eye to eye.
>>>
>>> But chill a little bit. I have given all the hardcoded proofs and people 
>>> have just given me *feelings* about what they thought should be right. 
>>> I think I have the right to disagree.
>>>
>>> Anyway, I can only wish you good continuation. :)
>>>
>>>
>>> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:

 I'm sorry but your attitude is counterproductive to the discussion.
 "haha" what? I told you I see your point, I think I know the specs very 
 well, thank you for the link.
 However, you seem incapable of accepting, despite an number of others 
 saying the contrary, despite, given a reasonable example where even the 
 standard library gets this "wrong" (according to you, according to me it's 
 exactly as it should be).
 You've been explained several times that both point of views hold valid 
 arguments so why do you insist your point of view is the only correct one 
 and everyone else is wrong?
 The authors of the language which have far more experience that me (I 
 can't speak for your experience or others), couldn't get to an agreement 
 on 
 how this should work so they took the best decision, let the user deal 
 with 
 this according to their individual needs.
 I'll stop following this thread / replying as it's pointless to do so 
 at this point.
 Good luck proving everyone else is wrong and you know better.

 On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>
> Ok, Let me help you out haha :)
>
> Here is the definition of a slice. It is not a container.
> https://golang.org/ref/spec#Slice_types
>
> I am not inventing things.
>
> I know what people on this thread said, but that's their misconception.
>
> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>
>> As you pointed out, Printf() should follow the ref spec but that 
>> doesn't happen because some humans don't perceive this accuracy as 
>> necessary or maybe because the way to resonate about slices / arrays is 
>> as 
>> containers for the actual values.
>> Thus we have Printf working as it does (and %p will indeed print the 
>> memory address of the slice type).
>>
>> I would definitely want to be able to compare []int{1, 2, 3} with 
>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for 
>> example 
>> purposes but think of them as coming from different sources)
>> Apparently you don't, and that's fine.
>>
>> That's exactly why the compiler only allows comparison with nil, to 
>> force the user to think about that should be compared, not do it by 
>> default 
>> and have potential hidden issues that might be uncovered too late in the 
>> process.
>>
>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>>
>>> In fact, that is somewhat my fault.
>>>
>>> I should ask:
>>>
>>> What is a slice?
>>> What is an array?
>>>
>>> Spoiler: a slice is a reference type in its "wikipedia-ish" 
>>> definition (auto-dereferencing) which is the reason you observe such a 
>>> result in the playground.
>>>
>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:

 No. You should not get it from here. You should get the answer from 
 the spec. Let alone the fact that the implementation should ideally 
 follow 
 the spec and not the reverse.

 On Sunday, July 3

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

Hardcoded proofs should be assigned well-named identifiers. If you ever 
have to alter them, you don't want to be rummaging around your lemmas and 
corollaries.

On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>
> Ok. That "haha" was merely to show that no animosity was borne. And also 
> because you didn't really answer the question as I asked (by quoting the 
> spec) which I found funny.
>
> Alas, I guess we couldn't see eye to eye.
>
> But chill a little bit. I have given all the hardcoded proofs and people 
> have just given me *feelings* about what they thought should be right. I 
> think I have the right to disagree.
>
> Anyway, I can only wish you good continuation. :)
>
>
> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>>
>> I'm sorry but your attitude is counterproductive to the discussion.
>> "haha" what? I told you I see your point, I think I know the specs very 
>> well, thank you for the link.
>> However, you seem incapable of accepting, despite an number of others 
>> saying the contrary, despite, given a reasonable example where even the 
>> standard library gets this "wrong" (according to you, according to me it's 
>> exactly as it should be).
>> You've been explained several times that both point of views hold valid 
>> arguments so why do you insist your point of view is the only correct one 
>> and everyone else is wrong?
>> The authors of the language which have far more experience that me (I 
>> can't speak for your experience or others), couldn't get to an agreement on 
>> how this should work so they took the best decision, let the user deal with 
>> this according to their individual needs.
>> I'll stop following this thread / replying as it's pointless to do so at 
>> this point.
>> Good luck proving everyone else is wrong and you know better.
>>
>> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>>>
>>> Ok, Let me help you out haha :)
>>>
>>> Here is the definition of a slice. It is not a container.
>>> https://golang.org/ref/spec#Slice_types
>>>
>>> I am not inventing things.
>>>
>>> I know what people on this thread said, but that's their misconception.
>>>
>>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:

 As you pointed out, Printf() should follow the ref spec but that 
 doesn't happen because some humans don't perceive this accuracy as 
 necessary or maybe because the way to resonate about slices / arrays is as 
 containers for the actual values.
 Thus we have Printf working as it does (and %p will indeed print the 
 memory address of the slice type).

 I would definitely want to be able to compare []int{1, 2, 3} with 
 ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
 purposes but think of them as coming from different sources)
 Apparently you don't, and that's fine.

 That's exactly why the compiler only allows comparison with nil, to 
 force the user to think about that should be compared, not do it by 
 default 
 and have potential hidden issues that might be uncovered too late in the 
 process.

 On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>
> In fact, that is somewhat my fault.
>
> I should ask:
>
> What is a slice?
> What is an array?
>
> Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
> (auto-dereferencing) which is the reason you observe such a result in the 
> playground.
>
> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>
>> No. You should not get it from here. You should get the answer from 
>> the spec. Let alone the fact that the implementation should ideally 
>> follow 
>> the spec and not the reverse.
>>
>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>>
>>> If I look at what %v means, print out the values of various types in 
>>> Go, according to https://golang.org/pkg/fmt/ then I believe that 
>>> this holds the answer: https://play.golang.org/p/GiLckoBDxa
>>>
>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:

 Not for comparison.

 I am just asking what is the value of a slice and what is the value 
 of an array.

 Remember that there is no slice comparison that has been spec'ed so 
 far.

 On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>
> For []T the value of a slice for the purpose of comparison would 
> be each individual value compared against each-other (ofc maybe 
> comparing 
> the length first as an optimization).
> Same goes for an array.
>
> And again, you are missing the whole point. Both me and you are 
> wrong in each-others points of view.
> Just accept this.
>
> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

Relaxing unformalized behavior makes little sense to me. Explaining why 
equality is inconsistent between slices and arrays is not something I want 
to do either.


On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>
> Rob and Robert actually wrote that this area of the spec needs more work...
> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
> explained.
>
> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>>
>> Go does not have reference types. As far as I know, the word was 
>> purposefully removed from the spec to remove the ambiguity surrounding the 
>> word. 
>>
>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>
>
>
> @Martin
>
> As I've mentioned earlier, one ought to be careful about  false friends 
> from other languages. 
> I am not sure I understand what you mean by:
>
> if the name field is changed after the call
>
>
>

-- 
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: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

Go does not have reference types. As far as I know, the word was purposefully 
removed from the spec to remove the ambiguity surrounding the word.

https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA

-- 
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 decrypt data with AES in golang

[as . utf8]

An IV is not a key, it just changes the state of the block chain and must 
the same size as the block. The key can be a different size than the block, 
the IV can not in this case. Your program complains because you are reusing 
the key as an IV, and this key-IV happens to be a different size than the 
block. 

You shouldn't create the IV this way. The IV is supposed to be public, 
randomly generated, and shouldn't be reused.

If you don't want to use an IV, set it to a block of zeroes and then 
encrypt one random block of data before encrypting your plaintext. This 
randomizes the blockchain. When the decryptor receives the first 
ciphertext, he can decrypt the first block and then discard it. 

There is no need to base64 encode your data, it doesn't add anything in 
terms of secrecy.

Consider AES-GCM for authenticated encryption in your next project. 


On Wednesday, June 29, 2016 at 11:57:11 PM UTC-7, Lazytiger wrote:
>
> Hi, all
>
> I have a C# code to decrypt data as following
>
> public static string test(string input, string key)
> {
> if (((input == null) || string.IsNullOrEmpty(input.Trim()))
>  || ((input == "false") || (input == "null")))
> {
> return string.Empty;
> }
> RijndaelManaged managed = new RijndaelManaged {
> KeySize = 0x100,
> BlockSize = 0x100,
> Mode = CipherMode.CBC,
> Padding = PaddingMode.PKCS7,
> Key = Encoding.ASCII.GetBytes(key),
> IV = Encoding.ASCII.GetBytes(key)
> };
> try
> {
> byte[] buffer = Convert.FromBase64String(input);
> ICryptoTransform transform = managed.CreateDecryptor();
> byte[] bytes = null;
> using (MemoryStream stream = new MemoryStream())
> {
> using (CryptoStream stream2 = new CryptoStream(stream,
>  transform, CryptoStreamMode.Write))
> {
> stream2.Write(buffer, 0, buffer.Length);
> }
> bytes = stream.ToArray();
> }
> return Encoding.ASCII.GetString(bytes);
> }
> catch (Exception exception)
> {
> Console.Write (exception.ToString ());
> return string.Empty;
> }
> } 
>
> And I have write a golang code as following:
>
> *func* test1(data, key string) {
> raw, err := base64.StdEncoding.DecodeString(data)
> *if* err != nil {
> *println*(err.Error())
> *return*
> }
>
> block, err := aes.NewCipher([]byte(key))
> *if* err != nil {
> *println*(err.Error())
> *return*
> }
> mode := cipher.NewCBCDecrypter(block, []byte(key)[:aes.BlockSize])
> mode.CryptBlocks(raw, raw)
>
> *println*(string(raw))
> }
>
> Besides the PKCS7 padding problem, I can’t get the right answer. Can 
> someone help me with this? Where do I get  this IV parameter?
> I Can’t set IV as  C# does, because golang just complains about block size 
> problem.  
>

-- 
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] redirect already running processes stdout

[as . utf8]

Most systems don't support this functionality without a kernel patch or 
debugger trick. You can manipulate the file descriptor before the process is 
born, everything afterwards is luck or system specific. In Go, you have a lot 
more power: 

os.Stdout, os. Stderr = os.Stderr, os.Stdout 

fmt.Println("?")

I recommend the os.Exec approach

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

Re: [go-nuts] How to be safe in Go?

[as . utf8]

I wasn't referring to concurrency within package scope, but data crossing 
package boundaries (the earlier post says libraries' are responsible to 
ensure data passed *to* them is safe). The map type reveals an 
implementation detail by documenting that it isn't safe for parallel use. 

On Friday, June 24, 2016 at 8:52:40 PM UTC-7, Henry wrote:
>
> The implementation of map is not a valid argument to "unboxing the black 
> boxes". 
>
> The question to ask is who does the concurrency. In the case of map, if 
> the user is the one accessing the map concurrently, then it is the user's 
> responsibility to ensure the map is concurrent safe. If the map internally 
> implements some concurrent processing, then the map has the responsibility 
> to ensure data integrity during the concurrent processing. The map's 
> implementation should be invisible to the user. 
>

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

Re: [go-nuts] How to be safe in Go?

[as . utf8]

I mostly agree, but there are times when abstraction leads to complex code 
and more reasonable approach involves documented constraints. The map type 
is not safe either, but it enjoys widespread use. If it were abstracted to 
handle all possible use-cases, it would be unnecessarily slow for most of 
the operations its used for.

There's an illusion of safety in languages that advertise all-encompassing 
abstractions, in my experience the problem becomes the language or library 
itself, as the underpinnings acquire code bloat to cover all use-cases. If 
this happens, the user must now choose between unboxing the black box or 
writing their own (better/stronger/faster) language/package.

Knowing 5-10% of a package implementation details seems like a reasonable 
tradeoff for a simpler implementation.

On Friday, June 24, 2016 at 7:12:11 PM UTC-7, Henry wrote:
>
> Libraries should be more like black boxes. The user shouldn't need to know 
> about their implementation, be it concurrent or not. It is the libraries' 
> responsibility to ensure any data passed to them is safe.

-- 
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] Fedora and crypto/elliptic.P224

[as . utf8]

Security has little to do with this. It's a "legal" problem:

Unfortunately, this code has to be removed due to legal concerns. We 
> apologize for any inconvenience this causes you.


https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/RDAHDK4RKN477G2ZDSX4DZT5EDD4WVTX/

> So you're telling me that some random lawyer's decision is preventing me
> > from generating an SSH key required to do my job?
> > 
> > Classic.
> Short answer is yes. Btw you really should tell your deputy/senator your 
> opinion regarding software patents.

https://bugzilla.redhat.com/show_bug.cgi?id=319901


On Monday, June 20, 2016 at 10:24:46 PM UTC-7, Henrik Johansson wrote:
>
> The second one,  the redhat Bugzilla does. They only want to ship a select 
> set of curves distro wide apparently. If it is motivated by security or 
> something else is less clear. 
>
> On Tue, Jun 21, 2016, 07:08 Ian Lance Taylor  > wrote:
>
>> On Mon, Jun 20, 2016 at 9:18 PM,  > 
>> wrote:
>> >
>> > Nothing is stopping them, but people aren't going to go to the 
>> distribution
>> > docs for the Go standard library - they're going to go to the official 
>> docs.
>>
>> It  is not sustainable for us to provide distro-specific docs for
>> changes made by distros.  They need to provide their own docs.  That
>> is unfortunate but I don't see any other workable approach.
>>
>> A better strategy here would be for them to come to us and ask us to
>> make the change and explain why it is appropriate.  The links you
>> provided do not explain it.
>>
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] Fedora and crypto/elliptic.P224

[as . utf8]

   Go should not encourage distribution builder shenanigans. The effective 
way to solve this problem is by submitting it as an issue to the 
appropriate community it affects. A high search rank will accumulate based 
on the popularity of this issue, and the feedback (blame) will flow to the 
right channels accordingly.

One can argue that Fedora users won't know that the curve is unsupported, 
and would not even realize that the problem is Fedora specific, but this is 
a weak argument for a system that doesn't have standard facilities for 
decoding mp3 files.

On Monday, June 20, 2016 at 9:18:13 PM UTC-7, Josh Chase wrote:
>
> Nothing is stopping them, but people aren't going to go to the 
> distribution docs for the Go standard library - they're going to go to the 
> official docs. 
>
> On Monday, June 20, 2016 at 9:13:18 PM UTC-7, as@gmail.com wrote:
>>
>> If the distribution builders can take it out, what is preventing them 
>> from adding their own documentation?
>>
>> On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote:
>>>
>>> Yep, that's exactly what I'm saying.
>>>
>>>
>>> https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1038683
>>>
>>> Supposedly patent/legal reasons?
>>>
>>>
>>> On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  
>>> wrote:
>>>
 On Mon, Jun 20, 2016 at 6:59 PM,   wrote:
 >
 > Should there be a note in the documentation that this has been 
 removed by
 > the Fedora packagers?
 >
 > It would help assure developers that they're not insane when they get 
 a
 > compile error claiming that something that
 > https://golang.org/pkg/crypto/elliptic says should be there, isn't 
 there.

 I'm not sure I understand: are you saying that Fedora removed
 crypto/elliptic.P224 when they packaged the Go distribution?  Why
 would they do that?

 Ian

>>>
>>>

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

Re: [go-nuts] Fedora and crypto/elliptic.P224

[as . utf8]

If the distribution builders can take it out, what is preventing them from 
adding their own documentation?

On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote:
>
> Yep, that's exactly what I'm saying.
>
>
> https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
> https://bugzilla.redhat.com/show_bug.cgi?id=1038683
>
> Supposedly patent/legal reasons?
>
>
> On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  > wrote:
>
>> On Mon, Jun 20, 2016 at 6:59 PM,  > 
>> wrote:
>> >
>> > Should there be a note in the documentation that this has been removed 
>> by
>> > the Fedora packagers?
>> >
>> > It would help assure developers that they're not insane when they get a
>> > compile error claiming that something that
>> > https://golang.org/pkg/crypto/elliptic says should be there, isn't 
>> there.
>>
>> I'm not sure I understand: are you saying that Fedora removed
>> crypto/elliptic.P224 when they packaged the Go distribution?  Why
>> would they do that?
>>
>> Ian
>>
>
>
>
> -- 
> -Josh
> (502) 209-9704
>

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

Re: [go-nuts] [ANN] Mirror of Go SSA

[as . utf8]

That's because you are mirroring the compiler's internal ssa package. 
Sharing it as compile/ssa would probably remove this unintuitive name 
clash. 

On Thursday, June 16, 2016 at 1:52:31 AM UTC-7, JW Bell wrote:
>
> I've used golang.org/x/tools/go/ssa, it doesn't have everything this does.
> On Jun 16, 2016 12:41 AM, > wrote:
>
> Have you tried to *go get golang.org/x/tools/go/ssa 
>  *?
>
>
> On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>>
>> >>I have to say that I don't see a big benefit to mirroring a github 
>> repo on github itself. 
>> There isn't another way to use the ssa package.
>>
>> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>>>
>>> On Tue, Jun 14, 2016 at 7:07 PM,   wrote: 
>>> > Mirror of the Go compiler SSA library -  
>>> https://github.com/bjwbell/ssa 
>>> > The mirror is automatically updated daily. 
>>> > 
>>> > Any feedback is welcome. I'm unsure on the licensing requirements for 
>>> > mirroring. 
>>>
>>> The license requirements in general are in the LICENSE file.  It's no 
>>> different from mirroring than for any other use. 
>>>
>>> I have to say that I don't see a big benefit to mirroring a github 
>>> repo on github itself. 
>>>
>>> Ian 
>>>
>>

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

Re: [go-nuts] [ANN] Mirror of Go SSA

[as . utf8]

Have you tried to *go get golang.org/x/tools/go/ssa *?

On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>
> >>I have to say that I don't see a big benefit to mirroring a github 
> repo on github itself. 
> There isn't another way to use the ssa package.
>
> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Tue, Jun 14, 2016 at 7:07 PM,   wrote: 
>> > Mirror of the Go compiler SSA library -  https://github.com/bjwbell/ssa 
>> > The mirror is automatically updated daily. 
>> > 
>> > Any feedback is welcome. I'm unsure on the licensing requirements for 
>> > mirroring. 
>>
>> The license requirements in general are in the LICENSE file.  It's no 
>> different from mirroring than for any other use. 
>>
>> I have to say that I don't see a big benefit to mirroring a github 
>> repo on github itself. 
>>
>> 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: Problem with `go run *.go` in windows CMD - winapi error #123

[as . utf8]

How exactly do you propose this be fixed? Windows has a crippled shell that 
thinks programs should process and interpret their own asterisk characters. 
This turns into a major inconsistency across windows CLI tools. I dont think Go 
should tailor itself to badly designed plumbing. 

-- 
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: Save to store encryption key in Go executable?

[as . utf8]

You're right, even if you aren't planning to share the program, it's still 
a good idea to separate the key from the executable. For one, the 
executable is bigger and harder to keep secret than a few bytes of data. 
It's generally frowned upon to bundle the two since the secrecy should rely 
solely on the key.

If you don't like passwords, you can store the key on a flash drive as a 
file or even write it directly to the underlying block device.

On Monday, June 13, 2016 at 10:12:25 PM UTC-7, Haddock wrote:
>
> Thanks for all the useful answers. All I want to do is to create an 
> encryption program for simple home computing purposes. I once lost some 
> encrypted files, because I lost the password. I think I did a typo when 
> typing it in and didn't realize. So I thought I write my own encryption 
> programm with a catch-all password in it. That might be a very bad idea now 
> ... 
>
> I first wanted to use Java as I'm used to it. But Java code cannot be 
> encrypted to hide the encryption key, because the Java byte codes would 
> then become unreadable for the JVM. So I thought of something else. I 
> thought of moving the key to some server. But then I would be dependent on 
> some server and the Internet being reachable in order to decrypt my things 
> (password files, etc.). 
>
> Seems like the best solution would be to store the key in a separate file, 
> though I don't understand exactly how this makes things better. Having the 
> key in a separate file means that the decrypted blank key is only visible 
> from within the running encryption programm for a very short moment. Is 
> that the idea? Maybe have a solution that first looks for a local key file 
> and only checks some server for it when locally not present.
>
> Regards, Haddock
>
> Am Montag, 13. Juni 2016 18:01:48 UTC+2 schrieb Haddock:
>>
>> Hello,
>>
>> I'm developing my own little encryption application in Go. The Go 
>> application needs to know the key used for encryption and decryption. My 
>> question is whether that key can be extracted from the Go executable 
>> somehow through disassembly or looking at the applications memory or 
>> something. I'm a complete Go beginner and know nothing about its memory 
>> layout. So that's why I thought it's better to ask. 
>>
>> Thanks, Haddock
>>
>

-- 
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: Better sum types for go

[as . utf8]

Thanks!

On Monday, June 13, 2016 at 3:27:51 AM UTC-7, Jesper Louis Andersen wrote:
>
>
> On Mon, Jun 13, 2016 at 1:58 AM, > wrote:
>
>> What research or other literature can you recommend on the topic of type 
>> theory?
>
>
> Benjamin C. Pierce's "Types and Programming Languages", often abbreviated 
> TAPL, is a classic text on type theory. Working from the semanticists 
> favorite toy language, the Lambda-calculus, Pierce proceeds to add 
> different type-theoretic constructs on top of it one at a time to explain 
> their concepts. Don't let the choice of the lambda-calculus fool you. Once 
> you add references into that language it essentially becomes a basis for 
> imperative programming.
>
>
> -- 
> J.
>

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

[go-nuts] Re: Save to store encryption key in Go executable?

[as . utf8]

This is a key distribution problem, if you store the key in the executable 
you should assume everyone already has access to the key. This is a 
different problem than "can someone get the key out of running memory". If 
you store the key in the executable, then an existential compromise of this 
key in any copy of the program compromises the secrecy of all past, 
present, and future processes that use this program. The point is, the key 
should be stored outside of the program.

Have you thought about having the program read in a passphrase, feeding it 
into a good key derivation algorithm, and then using that symmetric key to 
encrypt and decrypt your data (with something like AES GCM)?  


On Monday, June 13, 2016 at 9:01:48 AM UTC-7, Haddock wrote:
>
> Hello,
>
> I'm developing my own little encryption application in Go. The Go 
> application needs to know the key used for encryption and decryption. My 
> question is whether that key can be extracted from the Go executable 
> somehow through disassembly or looking at the applications memory or 
> something. I'm a complete Go beginner and know nothing about its memory 
> layout. So that's why I thought it's better to ask. 
>
> Thanks, Haddock
>

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