Re: [go-nuts] go get failing In Mac 10.11.4

[Krzysztof Kowalczyk]

My guess is that's because Mac filesystem is case preserving but not 
case-sensitive, meaning that in mac os "floRest" and "florest" is the same 
file/directory while on linux those are 2 distinct files. (you can 
configure mac filesystem to be case-sensitive as well, but that's not the 
default).

As you can see in the logs:

mv $WORK/github.com/jabong/floRest/src/examples.a
 /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/floRest/src/examples.a

mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/

cp $WORK/github.com/jabong/florest/src/examples.a
 /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/examples.a

go install github.com/jabong/florest/src/examples: open 
/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426/
github.com/jabong/florest/src/examples.a: no such file or directory


a file "floRest/src/examples.a" is moved and then there's an attempt to 
copy "florest/src/examples.a", which is the same file on mac os, and it's 
no longer there.


The question is why do you have "florest" and "floRest" packages in your 
code. Are those 2 different packages? Did you make a typo in an import 
statement?


-- kjk


On Tuesday, June 21, 2016 at 8:16:26 AM UTC-7, DM wrote:
>
> Below is the ouput using the -x flag:-
>
> jabongs-MacBook-Pro-4:florest debraj$ go get -x ./...
>
> WORK=/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426
>
> mkdir -p $WORK/github.com/jabong/floRest/src/examples/_obj/
>
> mkdir -p $WORK/github.com/jabong/floRest/src/
>
> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/examples
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/floRest/src/examples.a -trimpath $WORK -p 
> github.com/jabong/floRest/src/examples -complete -buildid 
> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
> github.com/jabong/floRest/src/examples -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go 
> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go 
> ./hello_world_multipe_errors.go ./swagger.go
>
> mkdir -p $WORK/github.com/jabong/floRest/src/service/_obj/
>
> mkdir -p $WORK/github.com/jabong/florest/src/examples/_obj/
>
> mkdir -p $WORK/github.com/jabong/florest/src/
>
> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/service
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/floRest/src/service.a -trimpath $WORK -p 
> github.com/jabong/floRest/src/service -complete -buildid 
> f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
> github.com/jabong/floRest/src/service -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go 
> ./business_logic_executor.go ./config_manager.go ./constants.go 
> ./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go 
> ./init_manager.go ./monitor_helper.go ./service_register.go 
> ./service_version_helper.go ./service_workflow_data.go ./uri_interpreter.go 
> ./web_server.go
>
> cd /Users/debraj/golang/src/github.com/jabong/florest/src/examples
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/florest/src/examples.a -trimpath $WORK -p 
> github.com/jabong/florest/src/examples -complete -buildid 
> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
> github.com/jabong/florest/src/examples -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go 
> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go 
> ./hello_world_multipe_errors.go ./swagger.go
>
> mkdir -p $WORK/github.com/jabong/florest/src/examples/cachestrategy/_obj/
>
> mkdir -p $WORK/github.com/jabong/florest/src/examples/
>
> cd /Users/debraj/golang/src/
> github.com/jabong/florest/src/examples/cachestrategy
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/florest/src/examples/cachestrategy.a -trimpath $WORK -p 
> github.com/jabong/florest/src/examples/cachestrategy -complete -buildid 
> c16efba4536c81f8b5b9f0090f909c0b3c71383c -D _/Users/debraj/golang/src/
> github.com/jabong/florest/src/examples/cachestrategy -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go 
> ./cache_strategy_user.go ./sample_db_adapter.go
>
> mkdir -p $WORK/github.com/jabong/florest/src/service/_obj/
>
> cd /Users/debraj/golang/src/github.com/jabong/florest/src/service
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/florest/src/service.a -trimpath $WORK -p 
> github.com/jabong/florest/src/service -complete -buildid 
> f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
> github.com/jabong/florest/src/service -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go 
> ./business_logic_executor.go ./config_manager.go ./constants.go 
> ./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go 
> ./init_manager.go ./monitor_helper.go 

[go-nuts] Re: A proposal for generic in go

[Matt Ho]

I think I have to agree with most of the posters here about generics.  In 
theory, I miss them.  However, in practice, I find that there are usually 
only a few times during the course of a project where I wish I had 
generics.  And then after writing a few lines of code to do what the 
generic would have done, I find I stop missing them.  

M



-- 
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 hide command line argument from ps

[Hoping White]

Thanks for all the replies. I agree that there is a better way to do the 
security jobs. I ask this question just for curiosity, to find out if there is 
a equivalence way to do this in golang. From all the replies I assume there is 
a no.

> 在 2016年6月21日，下午10:39，Matt Harden  写道：
> 
> It's generally a bad idea to try to improve security by hiding args. Much 
> better to pass the argument another way, for instance via an open file 
> descriptor that the program reads the value from.
> 
> 
> On Tue, Jun 21, 2016, 07:16 Hoping White  > wrote:
> Hi, all
> 
>I wonder is there a way to hide command line arguments from programs like 
> “ps”？ I can rewrite argv parameter for main in c language, or use LD_PRELOAD 
> to intercept libc_start_main, but all these methods do not be functional in 
> go. 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 
> .

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

[go-nuts] A proposal for generic in go

[Marcus Yip]

On Tuesday, June 21, 2016 at 2:56:01 PM UTC-4, Axel Wagner wrote: The issue
is, that a "KeyValuePair" (no matter if you implemented it via generics
or like you mention via interfaces) i

-- 
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] GoMobile window size always 800x800

[Andy Brewer]

OK, it sounds like it's more complicated than I thought to expose those
screen dimensions to the API.

There are a good (and growing) number of designers like me who code and the
gomobile tool is too barebones at the moment to be productive for testing
UI across multiple screen size or horizontal vs. vertical orientation.
Imagine a 1st person game that can only be played in landscape mode. Or, a
game that shows more of the game world on larger screens.  Or, a responsive
design with a breakpoint between screen sizes. In those scenarios, you will
end up resizing the window each time you test the UI. One nice thing about
browsers is that they stay the same size you left them, so if you want to
test a responsive layout at a particular dimension, you resize once and
then can test as many times as you like at that screen resolution. That was
the thought process behind giving the gomobile viewport control to the user.

But I could see how adding this feature could become a slippery slope to
requests for replicating other phone settings. I really like developing in
Go and would love to test my business logic in the test suite and quickly
test my UI in the viewport. It's much faster to than testing with a full
blown emulator.

One nice thing about React Native is the ability to startup an emulator
once (at a specific screen size) and refresh to see your app update. I
think if viewport control comes to gomobile, the testing speed with Go
would rival that of React Native, which is a big reason a lot of people use
it. I would much rather program my apps in Go than JavaScript, but if the
UI testing cycle is cumbersome and involves extra steps, it makes React
Native look like a more attractive option, just because of the tooling.

Thanks for looking into this.

On Tue, Jun 21, 2016 at 1:31 AM Daniel Skinner  wrote:

> In my experience, designers aren't writing code or demoing experiences in
> native code.
>
> If they were, it wouldn't be that dissimilar to what I already see, either
> resizing a window or choosing a specific window size in chrome dev tools.
>
> Put bluntly, designers just aren't affected here and I think the problem
> your having has more to do with how barebones gomobile is at the moment.
>
> Allowing the window size change via the api is superficial and you would
> quickly run into further hurdles. These hurdles are NOT invalid, they need
> to be addressed, its just more complicated than the size of a window when
> an app starts.
>
> It's something I know I'm actively investigating. It's something seeing
> action in exp/shiny with a flexbox implementation. It's a hot topic to say
> the least. And hopefully in the future there will be the tools available to
> allow you to look at your app beyond a pixel perfect representation for a
> specific mobile device, and as to something more, but for now "responsive
> ui" and concessions on a 1:1 aspect ratio being a bit non sensical are
> probably as good as it gets.
>
> Personally I think the solutions to these kinds of issues are purely
> numerical and should be easy to adopt in any codebase. Do you already have
> some sort of widget/ui library in the public? It might be more helpful to
> see how a responsive approach there really blows concerns for different
> sizes or a particular startup size away from concern.
>
> On Fri, Jun 17, 2016, 5:52 PM Andy Brewer  wrote:
>
>> OK, so designers will want to quickly test their app at specific screen
>> sizes. I think we just need to determine the best option because there
>> doesn't seem to be a gomobile best practice.
>>
>> It sounds like we have the following options:
>> 1. Run a script to resize the window (
>> http://www.labnol.org/software/resize-mac-windows-to-specific-size/28345/).
>> Upside: Works with current codebase. Downside: no cross-platform solution,
>> some solutions require extra clicks/typing, might need extra scripts for
>> each size.
>> 2. Run the app inside an emulator. Upside: works with current codebase.
>> full emulator control (wifi, settings, etc.). Downside: long testing
>> cycles, 10s+ (noted as a problem the gomobile viewport is trying to solve:
>> http://www.youtube.com/watch?v=ZLq0Zeoyu6Y=3m13s)
>> 3. Open up the API. Upside: developer control. Downside: Additional API
>> complexity.
>>
>> In the David Crawshaw talk, it sounds like the purpose of the viewport is
>> to not to replicate an emulator, but to improve the speed of the testing
>> feedback cycle. As a designer, being able to control the height/width of
>> the viewport would help me achieve that goal. We do the same thing with
>> responsive web design. We build a responsive layout, and then use a browser
>> extension to programmatically resize the browser to common screen
>> resolutions.
>>
>> I know for me, this is actually a stumbling block that I researched
>> online and found others having difficulty with as well. It would help a lot
>> to have this feature, but I'm not familiar enough with 

Re: [go-nuts] Go test to run over sub packages?

[gabriel . kopley]

Hi Ian, thanks for the confirmation!

It turns out that the cause of this behavior is that I had followed the 
instructions at 
https://github.com/karlseguin/the-little-go-book/blob/9f95b4405760fe9d24d4f9b7da93889cc9306f58/en/go.md#getting-started
 
and
symlinked thus: `$ ln -s ~/code/golang-workspace/src/github.com/foo/proj 
~/code/proj`

In a directory structure without the symlink, things work correctly :)

I'll file an issue on the Little Book of Go about this gotcha.

Gabe


On Tuesday, June 21, 2016 at 3:09:35 PM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Jun 21, 2016 at 12:42 PM,   
> wrote: 
> > Is `$ go test github.com/foo/proj/...`  
> really supposed to work? 
>
> Yes. 
>
> > When I run it I get 
> > 
> > warning: "github.com/foo/proj/..." matched no packages 
> > no packages to test 
> > 
> > But `cd src/github.com/foo/proj && go test ./...` does work as 
> suggested. 
>
> What is the value of your GOPATH environment variable? 
>
> 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] Go test to run over sub packages?

[Ian Lance Taylor]

On Tue, Jun 21, 2016 at 12:42 PM,   wrote:
> Is `$ go test github.com/foo/proj/...` really supposed to work?

Yes.

> When I run it I get
>
> warning: "github.com/foo/proj/..." matched no packages
> no packages to test
>
> But `cd src/github.com/foo/proj && go test ./...` does work as suggested.

What is the value of your GOPATH environment variable?

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] A proposal for generic in go

[Alex Bligh]

On 21 Jun 2016, at 19:55, 'Axel Wagner' via golang-nuts 
 wrote:

> The issue is, that a "KeyValuePair" (no matter if you implemented it 
> via generics or like you mention via interfaces) is a fundamentally useless 
> type and generics encourage people to add useless types. A "KeyValuePair V>" is a "struct { Key K, Value V }", plain and simple. It's not an interface 
> and it's not a generic type, it's simply a struct.
> 
> I agree, that generics are useful, but they seem to be mainly useful for 
> people who write "frameworks", not so much for people who write 
> "applications" and so far, go is pretty much a language for the latter. 
> Whenever people try to justify generics, they do it from a "I want to write a 
> framework" POV - and whenever I miss generics, I do because I'm currently 
> writing a framework of some kind.

Not sure that's fair.

For background, I'd quite like generics and liked Ian's last proposal quite a 
bit, but I also appreciate the cleanliness of go.

An recent example, in an real life application, where generics would have been 
useful is as follows.

I had a cache type thing built around a red-black tree, or more precisely two 
red black trees. The items were structs, and I needed one RB tree to be ordered 
by time of insertion (then key, for uniqueness), and one by key. One red-black 
tree dealt with expiries, and one with finding the item. In the absence of 
generics, I needed to embed the struct in a 'ByTime' and 'ByItem' struct, each 
of which implement a different 'LessThan' method. And everything that accessed 
the trees had a bunch of ugly casting from an interface{} to the relevant type. 
This does not make for readable code in any form. A RB tree that was 
implemented as a generic (and perhaps took a 'LessThan' function as a lambda) 
would have been far far cleaner in *my* code.

So saying it's all about being useful for people who write "frameworks" is 
unfair. It would actually have made the application code (i.e. the library 
user) far easier to read.

Of course it's possible to generate foolish uses (I would however note in 
passing that even with KeyValuePair things might not be as simple as you think, 
as it would (presumably) require comparability of K type items); however, it's 
also possible to perform stupidity with existing go syntax. The question is 
whether generics encourage it.

-- 
Alex Bligh




-- 
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] Getting a pointer in a type switch gives a *interface {} if case lists several options

[raidopahtma]

I have encountered some unexpected and inconsistent behavior with type 
switches. Can someone shed some light as to why Go behaves this way?

Take a look at https://play.golang.org/p/YPV5YPtWF8

I would expect both of the switches to behave the same way, but for some 
reason the one with multiple options in the case ends up with a pointer to 
an interface and the one with just one option ends up with a pointer to the 
correct type.

-- 
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] Handling panics in go_kafka_client

[chandradeepak . k]

Hi, We are trying to build an application using the go_kafka_client, for 
managing the consumer creation etc. We find it very convenient and easy to 
use. Thanks for building!

But in the go_kafka_client code we see a lot of panics.  

For example we created a consumer for a topic that doesn't exist, like 
below:

consumer.StartStatic(map[string]int{topic: config.NumConsumerFetchers}) 
which in turn does


 go c.createMessageStreams(topicCountMap)  -> since this is calling 
createMessageStreams 
in a go routine, we are not able to recover from the panic, when its thrown 
inside


Here is the place that does panic (partition_assignment.go):


*partitionsForTopic, err := coordinator.GetPartitionsForTopics(myTopics)*



*if err != nil {   panic(fmt.Sprintf("Failed to obtain partitions for 
topics: %s, topics: %v", err, myTopics))  --> this panic makes our application 
crash}*


We do see there is a panic handler for the zookeeper coordinator but not 
for the go_kafka_client package. What is the recommended way to handle 
panics from go_kafka_client?


Thanks,

Chandra.



-- 
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] Looking for go usage on QNX

[esealman]

Hello,

Looking for using go on QNX OS. I can see that gc isn't supported on QNX, 
but I thought might work since Plan9, freeBSD etc are supported. Additional 
solution can be the gccGo, so appreciate any help recommendation on both 
approaches.

Thanks,
Efraim

-- 
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: A proposal for generic in go

['Axel Wagner' via golang-nuts]

The issue is, that a "KeyValuePair" (no matter if you implemented it
via generics or like you mention via interfaces) is a fundamentally useless
type and generics encourage people to add useless types. A "KeyValuePair" is a "struct { Key K, Value V }", plain and simple. It's not an
interface and it's not a generic type, it's simply a struct.

I agree, that generics are useful, but they seem to be mainly useful for
people who write "frameworks", not so much for people who write
"applications" and so far, go is pretty much a language for the latter.
Whenever people try to justify generics, they do it from a "I want to write
a framework" POV - and whenever I miss generics, I do because I'm currently
writing a framework of some kind.

Generics empower abstractions, but most programmers are very bad at
building abstractions, so if you make it easy to build abstractions, you
will end up with a lot of bad abstractions (have a look at java). So, to a
certain degree, the value of go is, to *not* make building abstractions
overly simple. That leads to abstractions being used only where they are
essential and being left out where they are superfluous. This is where
reduced cognitive overhead comes into play - limiting the levels of
abstractions that people need to deal with to the bare essentials. Java is
bloated and hard to use, not because the language is bad, but because it
has a history of programmers building bad abstractions into it which gets
stacked on top of each other. So, yes, if you compare a bad abstraction
using interfaces with a bad abstraction using generics, generics will, in
general, compare very well. But you just shouldn't build the bad
abstraction in the first place.

The second concern with complexity is the spec. The exact behavior and
semantics of generics need to be spec'ed and useful generics need a lot
specification. For example, the current rules for type inference can be
understood completely just by looking at a single expression and it's type
and it's correspondingly simple to implement and spec. Generics usually
need more powerful type inference methods to not be cumbersome, which will
take up a lot of space in the spec. As humans, just like computers, have
very little memory, the time it takes to understand the spec will grow
superlinear with the length of it, due to frequent cache misses, so a long
spec will significantly increase the time needed to learn the language. In
the same vein, to understand a language, you need to know about
interactions between it's different concepts, not just the concepts itself,
so the needed space and time complexity to learn a language also grows
quadratic in the number of concepts in the language (in general). All of
that contributes to why people are wary of adding new concepts to go - the
costs in terms of understanding and learning the language are huge and they
grow very much superlinear in the number of concepts added, so each added
concept must be carefully examined (I know go for years and I still learn
new things about interactions between different concepts all the time).


I sometimes miss generics, yes, but I also believe adding them will make
the language significantly harder to learn and will significantly worsen
the quality of go code in the wild, so it would likely eliminate the
reasons I like go currently (which is that go code is usually of
exceptionally high quality, uniform and easy to understand).

On Tue, Jun 21, 2016 at 5:06 PM,  wrote:

> >> What I mean is that most people who have followed the past generics
> discussions already know it's possible to implement them with efficient
> memory use and performance. So they don't need to worry much about that.
>
> Thank you for explanation.
>
> >> can they be implemented without making Go a much more complex language
> than it is now
>
> What is a measure of the syntax complexity in the Go language.
> What this means and how they should be measured such a relative criteria?
> - Much more complex
> - More complex
> - Slightly more complex
> - Little bit more complex
>
> Also how you personally measure these cognitive loads?
>
> 1.Sample (pattern)
>
> type KeyValuePair interafce {
>   key interface{}
>   val  interface{}
> }
>
> 2.Sample (pattern)
>
> type KeyValuePair interafce {
>   key K
>   val  V
> }
>
> What about that a value of the #2 sample is more complex than #1 sample on
> the 146%?
> With permissible error of no more than 5%.
>
> I think that possible we should to start a discussion about that problem
> (complexity measurement of the Go language perception).
>
> I'm not kidding.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed 

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Michael Jones]

I asked for this a while back ("drop underscore between digits as in Ada")
and the answer was no. I try to ask just once.

This was shut down without much discussion at
https://github.com/golang/go/issues/42.

I agree that it's a nice feature.

By the way, though, one nice aspect of Go is that because of how
untyped constants work you can write integers using scientific
notation:

for i := 0; i < 10e6; i++ {
// ...
}

This is exactly the same as if you had written 1000.

(I don't think you'd want to do this in C or Java because, although it
would "work", 10e6 is a floating point number and so i would be
converted to a double for comparison. I am not an expert in those
languages, though, so someone can correct if I'm wrong here.)

On Tue, Jun 21, 2016 at 8:44 AM, Roger Pack  wrote:
> I found recently when doing some language comparisons
>
> In a few other languages (ruby, java, etc.) underscores within numeric
> literals to make them more readable, ex:
>
> 10_000_000.times do
>   ...
> end
>
> go ex:
>
> for i := 0; i < 1000; i++ {
> ...
> }
>
> I find it helps readability, and think it would be a nice addition to the
> language (or some way to group digits, perhaps there already is one?).
> Consider this a feature request (go 2.0 or what not).
> Cheers.
> -roger-
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

Re: [go-nuts] semantics of byteCount in gob encoding

[Alex Flint]

Oh I expected that since I only called encoder.Encode once, there would
only be on repetition of the outermost segment. I was expecting the
wireType to be within the inner "(-type id, encoding of a wireType)*"
segment. Otherwise shouldn't the spec be

((byteCount, -type id, encoding of a wireType)* (byteCount, type id,
encoding of a value))*

?

On Tue, Jun 21, 2016 at 8:47 AM Rob Pike  wrote:

> It's as advertised, 1 count byte (1a=26) followed by 26 bytes, followed by
> one count byte (5), followed by 5 bytes. Note the final '*' in that grammar.
> -rob
>
>
> On Tue, Jun 21, 2016 at 8:20 AM, Alex Flint  wrote:
>
>> The gob docs state that a gob stream consists of
>>
>> (byteCount (-type id, encoding of a wireType)* (type id, encoding of
>> a value))*
>>
>> I was expecting byteCount to be the number of bytes remaining in the
>> entire packet, but that does not seem to be the case. For example when
>> encoding a single instance of "struct Number { X int }", the gob stream is
>>
>> 000 1a ff 81 03 01 01 06 4e 75 6d 62 65 72 01 ff 82
>> 010 00 01 01 01 01 58 01 04 00 00 00 05 ff 82 01 06
>> 020 00
>>
>> The entire stream is 33 bytes, so I was expecting the first byte to be
>> 0x20, but in fact it is 0x1a. Is this count exclusive of the "(-type id,
>> encoding of a wireType)*" segment?
>>
>> Alex
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[go-nuts] feature request: allow literal digit underscore grouping

[Roger Pack]

I found recently when doing some language comparisons

In a few other languages (ruby, java, etc.) underscores within numeric 
literals to make them more readable, ex:

10_000_000.times do
  ...
end

go ex:

for i := 0; i < 1000; i++ {
...
}

I find it helps readability, and think it would be a nice addition to the 
language (or some way to group digits, perhaps there already is one?).
Consider this a feature request (go 2.0 or what not).
Cheers.
-roger-

-- 
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] semantics of byteCount in gob encoding

[Alex Flint]

The gob docs state that a gob stream consists of

(byteCount (-type id, encoding of a wireType)* (type id, encoding of a
value))*

I was expecting byteCount to be the number of bytes remaining in the entire
packet, but that does not seem to be the case. For example when encoding a
single instance of "struct Number { X int }", the gob stream is

000 1a ff 81 03 01 01 06 4e 75 6d 62 65 72 01 ff 82
010 00 01 01 01 01 58 01 04 00 00 00 05 ff 82 01 06
020 00

The entire stream is 33 bytes, so I was expecting the first byte to be
0x20, but in fact it is 0x1a. Is this count exclusive of the "(-type id,
encoding of a wireType)*" segment?

Alex

-- 
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] go get failing In Mac 10.11.4

[Debraj Manna]

Below is the ouput using the -x flag:-

jabongs-MacBook-Pro-4:florest debraj$ go get -x ./...

WORK=/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426

mkdir -p $WORK/github.com/jabong/floRest/src/examples/_obj/

mkdir -p $WORK/github.com/jabong/floRest/src/

cd /Users/debraj/golang/src/github.com/jabong/floRest/src/examples

/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
github.com/jabong/floRest/src/examples.a -trimpath $WORK -p
github.com/jabong/floRest/src/examples -complete -buildid
febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
github.com/jabong/floRest/src/examples -I $WORK -I
/Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
./data_structures.go ./hello_world.go ./hello_world_health_checker.go
./hello_world_multipe_errors.go ./swagger.go

mkdir -p $WORK/github.com/jabong/floRest/src/service/_obj/

mkdir -p $WORK/github.com/jabong/florest/src/examples/_obj/

mkdir -p $WORK/github.com/jabong/florest/src/

cd /Users/debraj/golang/src/github.com/jabong/floRest/src/service

/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
github.com/jabong/floRest/src/service.a -trimpath $WORK -p
github.com/jabong/floRest/src/service -complete -buildid
f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
github.com/jabong/floRest/src/service -I $WORK -I
/Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go
./business_logic_executor.go ./config_manager.go ./constants.go
./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go
./init_manager.go ./monitor_helper.go ./service_register.go
./service_version_helper.go ./service_workflow_data.go ./uri_interpreter.go
./web_server.go

cd /Users/debraj/golang/src/github.com/jabong/florest/src/examples

/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
github.com/jabong/florest/src/examples.a -trimpath $WORK -p
github.com/jabong/florest/src/examples -complete -buildid
febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
github.com/jabong/florest/src/examples -I $WORK -I
/Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
./data_structures.go ./hello_world.go ./hello_world_health_checker.go
./hello_world_multipe_errors.go ./swagger.go

mkdir -p $WORK/github.com/jabong/florest/src/examples/cachestrategy/_obj/

mkdir -p $WORK/github.com/jabong/florest/src/examples/

cd /Users/debraj/golang/src/
github.com/jabong/florest/src/examples/cachestrategy

/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
github.com/jabong/florest/src/examples/cachestrategy.a -trimpath $WORK -p
github.com/jabong/florest/src/examples/cachestrategy -complete -buildid
c16efba4536c81f8b5b9f0090f909c0b3c71383c -D _/Users/debraj/golang/src/
github.com/jabong/florest/src/examples/cachestrategy -I $WORK -I
/Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
./cache_strategy_user.go ./sample_db_adapter.go

mkdir -p $WORK/github.com/jabong/florest/src/service/_obj/

cd /Users/debraj/golang/src/github.com/jabong/florest/src/service

/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
github.com/jabong/florest/src/service.a -trimpath $WORK -p
github.com/jabong/florest/src/service -complete -buildid
f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
github.com/jabong/florest/src/service -I $WORK -I
/Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go
./business_logic_executor.go ./config_manager.go ./constants.go
./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go
./init_manager.go ./monitor_helper.go ./service_register.go
./service_version_helper.go ./service_workflow_data.go ./uri_interpreter.go
./web_server.go

mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/floRest/src/

mv $WORK/github.com/jabong/floRest/src/examples.a
/Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/floRest/src/examples.a

mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/

cp $WORK/github.com/jabong/florest/src/examples.a
/Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/examples.a

go install github.com/jabong/florest/src/examples: open
/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426/
github.com/jabong/florest/src/examples.a: no such file or directory

mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/examples/

mv $WORK/github.com/jabong/florest/src/examples/cachestrategy.a
/Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/examples/cachestrategy.a

mv $WORK/github.com/jabong/floRest/src/service.a
/Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/floRest/src/service.a

mkdir -p $WORK/github.com/jabong/florest/_obj/

mkdir -p $WORK/github.com/jabong/florest/_obj/exe/

cd /Users/debraj/golang/src/github.com/jabong/florest

/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
github.com/jabong/florest.a -trimpath $WORK -p main -complete -buildid
fb73c44c8d0536fc3134f24ae052fdb67036f537 -D 

Re: [go-nuts] Re: A proposal for generic in go

[andrew . mezoni]

>> What I mean is that most people who have followed the past generics 
discussions already know it's possible to implement them with efficient 
memory use and performance. So they don't need to worry much about that. 

Thank you for explanation.

>> can they be implemented without making Go a much more complex language 
than it is now

What is a measure of the syntax complexity in the Go language.
What this means and how they should be measured such a relative criteria?
- Much more complex
- More complex
- Slightly more complex
- Little bit more complex

Also how you personally measure these cognitive loads?

1.Sample (pattern)

type KeyValuePair interafce {
  key interface{}
  val  interface{}
}

2.Sample (pattern)

type KeyValuePair interafce {
  key K
  val  V
}

What about that a value of the #2 sample is more complex than #1 sample on 
the 146%?
With permissible error of no more than 5%.

I think that possible we should to start a discussion about that problem 
(complexity measurement of the Go language perception).

I'm not kidding.

-- 
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 hide command line argument from ps

[Matt Harden]

It's generally a bad idea to try to improve security by hiding args. Much
better to pass the argument another way, for instance via an open file
descriptor that the program reads the value from.

On Tue, Jun 21, 2016, 07:16 Hoping White  wrote:

> Hi, all
>
>I wonder is there a way to hide command line arguments from programs
> like “ps”？ I can rewrite argv parameter for main in c language, or use
> LD_PRELOAD to intercept libc_start_main, but all these methods do not be
> functional in go. 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.
>

-- 
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 hide command line argument from ps

[Konstantin Khomoutov]

On Tue, 21 Jun 2016 22:16:38 +0800
Hoping White  wrote:

> I wonder is there a way to hide command line arguments from
> programs like “ps”？ I can rewrite argv parameter for main in c
> language, or use LD_PRELOAD to intercept libc_start_main, but all
> these methods do not be functional in go. Thanks. 

What problem are you trying to solve?

It smells like you're passing some security-sensitive data to your
program.  If yes, do not do that: pass it via stdin via any protocol
agreed-upon by both parties (a single LF-terminated UTF-8-encoded string
could be OK).  If you need to use stdin to pass some other data, create
a socket pair (man 2 socketpair) in your host program, mark its read
end as exported on fork (or, alternatively, mark its write end as not
exported on fork -- this really depends on what language/runtime the
host is written in) -- to make the read end's file descriptor inherited
by your Go process, and pass the number of that file descriptor on the
command-line to the Go process.  It will then convert it to a proper
socket value and read your security-sensitive data from there.  (That's
what GPG does, for instance).  If you need more details, ask away.

Otherwise, try looking at prctl(2) and its PR_SET_NAME.
Not sure if it works on all POSIX kernels as this call is not defined
by POSIX.

In any case, I should stress that any attempt of re-writing
command-line options as seen by `ps` for security is solving the problem
asswards.

-- 
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: A proposal for generic in go

[Henry]

You still haven't provided any argument why generics is indispensable. 

The reason why I am no longer sure about my position in this issue is because 
-while I agree that generics is useful- I don't think that generics is 
essential. In fact, all of C++ features are useful and implemented in a very 
efficient manner, but take a look what happened when you slab that many 
features together. If you can do away with less, I think you should go for 
less. The trouble is deprecating language features is a lot harder than 
deprecating APIs in the standard library, while programming fads come and go. 

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

Re: [go-nuts] Re: A proposal for generic in go

[Ian Davis]

 
On Tue, Jun 21, 2016, at 03:17 PM, andrew.mez...@gmail.com wrote:
> >>increase in cognitive load to decipher chains of type definitions.
>
> Sorry, but who are members of this mail lists?
> This is a first time when I hear about such loads such as the
> `cognitive load`.
> Also I am possible here a single person who does not know anything
> about the `cognitive load to decipher chains of type definitions`.
> I am mostly business man and a programmer just for my own
> requirements.
> I love to implements parsers, code generators, some effective
> algorithms for solving some problem at the most effective time.
> Also my work includes a diagnose the failures and locate them.
> And I want to apologize for my illiteracy (thick-headed), but I do not
> really was expecting that all members of this mail list worry mostly
> about the ` increase in cognitive load to decipher chains of type
> definitions` and don't worry about other things.
 
What I mean is that most people who have followed the past generics
discussions already know it's possible to implement them with efficient
memory use and performance. So they don't need to worry much about that.
 
What stops them being added to the language is: can they be implemented
without making Go a much more complex language than it is now.  In my
opinion complex or large languages result in code that is much harder
and expensive to maintain over the long term.
 
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] Re: A proposal for generic in go

[andrew . mezoni]

>> increase in cognitive load to decipher chains of type definitions.

Sorry, but who are members of this mail lists?
This is a first time when I hear about such loads such as the `cognitive 
load`.
Also I am possible here a single person who does not know anything about 
the `cognitive load to decipher chains of type definitions`.
I am mostly business man and a programmer just for my own requirements.
I love to implements parsers, code generators, some effective algorithms 
for solving some problem at the most effective time.
Also my work includes a diagnose the failures and locate them.
And I want to apologize for my illiteracy (thick-headed), but I do not 
really was expecting that all members of this mail list worry mostly about 
the ` increase in cognitive load to decipher chains of type definitions` 
and don't worry about other things.
I am sorry.

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

[go-nuts] How to hide command line argument from ps

[Hoping White]

Hi, all

   I wonder is there a way to hide command line arguments from programs like 
“ps”？ I can rewrite argv parameter for main in c language, or use LD_PRELOAD to 
intercept libc_start_main, but all these methods do not be functional in go. 
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.

Re: [go-nuts] Unmarshalling and tags

[Nate Finch]

I'd like to see something like this:

type Payment struct { 
ActionType paypal.ActionType `xml,yaml,json:"actionType,omitempty"` 
ReceiverList paypal.ReceiverList `xml,yaml,json:"actionType,omitempty"` 
} 


-- 
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: A proposal for generic in go

[Ian Davis]

 
On Tue, Jun 21, 2016, at 01:45 PM, andrew.mez...@gmail.com wrote:
> >>I am not saying that generics is bad, but I am questioning whether
> >>generics is necessary.
>
> Please, do not panic.
> If you worry about the following things:
> - Generated code will grow when used generics
> - Generated code will be more complex when used generics
> - Execution performance will slow down when used generics
> - Memory consumption will grow when used generics
 
I don't believe most people in this mailing list are worried about those
things. They are worried about things like code complexity, readability
and increase in cognitive load to decipher chains of type definitions.
 
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: A proposal for generic in go

[andrew . mezoni]

>> I am not saying that generics is bad, but I am questioning whether 
generics is necessary.

Please, do not panic.
If you worry about the following things:
- Generated code will grow when used generics
- Generated code will be more complex when used generics
- Execution performance will slow down when used generics
- Memory consumption will grow when used generics

I can say you.
- Generated code will NOT grow when used generics
- Generated code will NOT more complex when used generics
- Execution performance will NOT slow down when used generics
- Memory consumption will NOT grow when used generics

They are so arranged that they are universal for all uses cases and does 
not require a significant changes in the following things:
- Compilers
- Runtimes
- Reflections

Most of the type checks will be performed at the compile time only because 
the Go language is statically typed language.
Most of the type instances (instances of the generic types which will be 
created at runtime) will be stored for the further reuse (they will be not 
created again and again but they will retrieved from the hidden static 
variables, so called lazy getters).

Only when used reflection then they (newly created type instances) can get 
some overhead but just a little bit more then with non-generic types.

Generic types is not evil, nor complex.
They are still the same types but only with the parameters (this is single 
kind of complexity which for me is not complexity at all) and they are 
variative (but this is not a complexity this is just a rules).

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

Re: [go-nuts] A proposal for generic in go

[Micky]

I guess that's for diplomatic reasons. If you watch talks of core
contributors then I believe you'll know what I mean :)

On Tue, Jun 21, 2016 at 5:15 AM, Rodrigo Kochenburger  wrote:
> Micky, I'm not sure where you're quoting from but they never said it's never
> gonna happen.
>
> From the FAQ: "Generics may well be added at some point." and "This remains
> an open issue".
>
> https://golang.org/doc/faq#generics
>
>
> On Mon, Jun 20, 2016 at 4:54 PM Micky  wrote:
>>
>> It's never going to happen! To quote the powers-to-be, "The language is
>> done".
>> Good luck!
>>
>> On Wed, Jun 15, 2016 at 6:04 AM, xingtao zhao 
>> wrote:
>> > Here is my proposal for generic in go:
>> >
>> > https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>> >
>> > Many parts has not been finished, and just initial thoughts. In the
>> > proposal, I want to keep back compatibility. And I try to add the
>> > orthogonal
>> > feature only and keep the language still simple enough.
>> >
>> > Please add your comments on it. Hope it is useful and could inspire some
>> > new
>> > features in go 2.0
>> >
>> > 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.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] [ANN] primegen.go: Sieve of Atkin prime number generator

[alb . donizetti]

>  Do you plan to include SSA for the x86 version as well?

For an answer to this: yes, it seems like the plan is to port every 
supported architecture
to SSA. It was discussed here:
https://groups.google.com/d/msg/golang-dev/fSIl5Sbr4ek/10sgOsnDEAAJ

Il giorno martedì 21 giugno 2016 03:39:41 UTC+2, gordo...@gmail.com ha 
scritto:
>
> On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote: 
> Further to the subject of compiler efficiency, the following is the 
> assembler code output with array bounds checking turned off (-B) the the 
> inner tight composite culling loop of FasterEratspeed above (generated with 
> go tool compile -B -S FasterEratspeed.go > FasterEratspeed.asm): 
>
> 0x0051 00081 (main.go:426)MOVLR11, CX 
> 0x0054 00084 (main.go:426)SHRL$5, R11 
> 0x0058 00088 (main.go:428)MOVL(R9)(R11*4), R13 
> 0x005c 00092 (main.go:430)MOVL$1, R14 
> 0x0062 00098 (main.go:430)SHLLCX, R14 
> 0x0065 00101 (main.go:430)ORLR13, R14 
> 0x0068 00104 (main.go:431)MOVLR14, (R9)(R11*4) 
> 0x006c 00108 (main.go:429)LEAL(R12)(CX*1), R11 
> 0x0070 00112 (main.go:425)CMPLR11, R8 
> 0x0073 00115 (main.go:425)JCS$0, 81 
>
> At 10 instructions, this is about as tight as it gets other than for using 
> the more complex read/modify/write version of the ORL instruction, but that 
> doesn't seem to save much if any time given instruction latencies.  Note 
> that this code has eliminated the "k & 31" for the shift, seeming to 
> recognize that it isn't necessary as a long shift can't be greater than 31 
>
> Getting rid of the &31 is easy and I'll do that in 1.8. 
>   
> anyway, that unlike the simple PrimeSpeed program, this properly uses the 
> immediate load of '1', 
>
> I don't know what the issue is yet, but it shouldn't be hard to fix in 
> 1.8. 
>   
> that it cleverly uses the LEAL instruction to add the prime value 'q' in 
> R12 to the unmodified 'k' value in CX to produce the sum to the original 
> location of 'j' in R11 to save another instruction to move the results from 
> CX to R11. 
>
> The current SSA backend should do this also. 
>   
> No, Keith, you seem to have misunderstood, I wasn't complaining above the 
> above assembler codeas produced by the 1.7beta1 compiler, and I was 
> wondering why it always isn't this good, which is about as good as it gets 
> for this loop and already properly gets rid of &31, does a proper immediate 
> load of 1, and the clever use of the LEA instruction without the misuse of 
> the LEA instruction to continuously recalculate 'p'.  The assembler code 
> above is produced by either of the below loop variations: 
>
> 1) as it is in FasterEratspeed: 
>
> for k < lngthb { 
> pos := k >> 5 
> data := k & 31 
> bits := buf[pos] 
> k += q 
> bits |= 1 << data // two[data] 
> buf[pos] = bits 
> } 
>
> 2) I get the same assembler code if I change this to the simpler: 
>
> for ; k < lngthb; k += q { 
> buf[k>>5] |= 1 << (k & 31) 
> } 
>
> where all variables and buffers are uint32. 
>
> My question was, why did the compiler produce this very good code for both 
> variations, yet produced something much worse for the same variation two 
> loop in the simple PrimeSpeed code, with the main difference that 
> PrimeSpeed uses 64-bit uint for the loop variables and loop limit.  Does 
> that give you a clue where the problem might be?  Converting PrimeSpeed to 
> use uint32's as here fixed the continuous recalculation of 'p' but not the 
> other problems. 
>
> It seems that sometimes the compiler erroneously tries to reduce register 
> use without applying the cost in execution speed to the decision.  It is 
> inconsistent, sometimes producing great code as here, and sometimes not so 
> great as in PrimeSpeed. 
>
> I was looking for some general advice on how to format loops so they 
> produce code as good as this? 
>
> Do you plan to include SSA for the x86 version as well?

-- 
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] Treeless: distributed NoSQL key-value DB written in Go

[David M.]

Hi,

I've just released Treeless (https://github.com/dv343/treeless), a new 
distributed NoSQL key-value DB written in Go.

I have been focused on performance and simplicity and I think I have 
achieved good results. For example, Get performance is 20% slower compared 
to Redis, but Set performance can be up to 2x faster than Redis.

I think I have reached a  stable state. Real usage may show critical bugs, 
but all tests are passed now.

I would love to get some feedback about it, I know it's not perfect, and it 
needs some polish, but I hope you like it.

PS: I didn't thought I would achieve those performance results with Go, 
using Go has been a really good design choice. Congratulations to all Go 
developers! 

-- 
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: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Tuesday, 21 June 2016 12:50:16 UTC+3, Egon wrote:
>
>
>
> On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>>
>>
>> 
>>
>> I am attempting to generate a random starfield, in go. This is something 
>> that will need to printed on actual paper, but that is another issue and I 
>> only mention it to give some context for what I am doing here: Using go to 
>> create graphics to pair with something I'm already doing in go (I've been 
>> through several iterations of trying to use the go parts I have with 
>> numerous variations of tex/latex templates using asymptote, and I reached a 
>> point of frustration where I figured why not just do it all in go, as it 
>> seems less a problem than I originally thought -- but opens a new set of 
>> problems to solve, one of the biggest is that I know nothing at all about 
>> graphics, let alone how to apply graphics in go).
>>
>> Cosmic1 from:  
>> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, 
>> generates the above it is the first thing that even roughly approximates 
>> what I want to do.
>>
>> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
>> directly translate an opengl shader to something cpu bound(which I suspect 
>> is a thing, I may need to do more that I can't see right now).
>>
>
> As for the current code:
>
> Here you are picking a random rotation for each pixel:
> a1 := .5 + float64(float64(mr.Intn(size.X))/3)/float64(mr.Intn(size.X))*2
> a2 := .8 + float64(float64(mr.Intn(size.X))/2)/float64(mr.Intn(size.Y))*2
>
> This can change for every pixel (in shader the time is a constant for one 
> frame):
> time := float64(time.Now().UTC().Unix())*speed + 0.25
>
> In func toUint8(in float64) uint8 { you need to clamp the value between 0 
> and 255, otherwise the conversion overflows.
>
> Color adjusting code doesn't match the shader code.
>
> I suspect there are further issues in the iteration code.
>
> PS: often with such fragments you can simplify code and achieve a similar 
> result with less details, e.g. 
> https://gist.github.com/egonelbre/b5f41ac8946e609ce1a944631dd462ef
>

Here's the minimal code for doing that: 
https://gist.github.com/egonelbre/811d37e94dda69b6d92365a7e63a2eec 

+ Egon

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

[go-nuts] go get failing In Mac 10.11.4

[DM]

Hi

On Mac OS X 10.11.4 *go get* is failing with the below error. 

jabongs-MacBook-Pro-4:florest debraj$ go get ./...
go install github.com/jabong/florest/src/common/config: open /var/folders/lp
/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build823644730/github.com/jabong/
florest/src/common/config.a: no such file or directory
go install github.com/jabong/florest/src/common/utils/responseheaders: open 
/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build823644730/github.
com/jabong/florest/src/common/utils/responseheaders.a: no such file or 
directory
go install github.com/jabong/florest/src/service: open /var/folders/lp/
3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build823644730/github.com/jabong/florest
/src/service.a: no such file or directory


Can some one let me know why this is failing? This is working perfectly 
fine on Ubuntu.

   - Go Lang Version - 1.6.1


-- 
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: A proposal for generic in go

[Henry]

I am not saying that generics is bad, but I am questioning whether generics 
is necessary.


On Tuesday, June 21, 2016 at 3:45:08 PM UTC+7, andrew...@gmail.com wrote:

> >> I was one of the generics supporters for Go in this forum, but now I am 
> not so sure.
>
> But why?
> Generic types is the same types as and the regular types.
> Difference only in that the regular types does not have a parameters but 
> generic types are always have at least one parameter.
> This is why they are called generic (universal) types.
> The same as you don't worry about that the function can have a parameters 
> why you should worry about that the type can have a parameters?
> When for types allowed to have parameters then this get a some benefits:
> 1. Generice types can be "configured" by some requirements (by their 
> parameters)
> 2. Generice types can have a restrictions (eg. each parameter can have its 
> own upper type bounds)
> 3. Generic types are universal types
>
> Eg. Trivial example
>
> type KeyValuePair struct {
>   key K
>   val V
> }
>
> You can use this type everywhere since it is universal type.
>
> Below is not the same type (because in generic type system K != V, but 
> here interface{} == interface{}):
>
> type KeyValuePair struct {
>   key interface{}
>   val interface{}
> }
>
> Because power of the generic types in that the they are variative:
> - Covariant
> - Contrvariant
> - Invariant
>
> And they, of course, can have a parameters.
>

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

[go-nuts] Re: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>
>
> 
>
> I am attempting to generate a random starfield, in go. This is something 
> that will need to printed on actual paper, but that is another issue and I 
> only mention it to give some context for what I am doing here: Using go to 
> create graphics to pair with something I'm already doing in go (I've been 
> through several iterations of trying to use the go parts I have with 
> numerous variations of tex/latex templates using asymptote, and I reached a 
> point of frustration where I figured why not just do it all in go, as it 
> seems less a problem than I originally thought -- but opens a new set of 
> problems to solve, one of the biggest is that I know nothing at all about 
> graphics, let alone how to apply graphics in go).
>
> Cosmic1 from:  
> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, 
> generates the above it is the first thing that even roughly approximates 
> what I want to do.
>
> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
> directly translate an opengl shader to something cpu bound(which I suspect 
> is a thing, I may need to do more that I can't see right now).
>

As for the current code:

Here you are picking a random rotation for each pixel:
a1 := .5 + float64(float64(mr.Intn(size.X))/3)/float64(mr.Intn(size.X))*2
a2 := .8 + float64(float64(mr.Intn(size.X))/2)/float64(mr.Intn(size.Y))*2

This can change for every pixel (in shader the time is a constant for one 
frame):
time := float64(time.Now().UTC().Unix())*speed + 0.25

In func toUint8(in float64) uint8 { you need to clamp the value between 0 
and 255, otherwise the conversion overflows.

Color adjusting code doesn't match the shader code.

I suspect there are further issues in the iteration code.

PS: often with such fragments you can simplify code and achieve a similar 
result with less details, e.g. 
https://gist.github.com/egonelbre/b5f41ac8946e609ce1a944631dd462ef

-- 
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] Send us your gophers!

[Jan Mercl]

On Sat, May 21, 2016 at 8:28 AM 'Andrew Gerrand' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Renee French and I are doing a little secret project and would love it if
you would draw a gopher and sent it to us.

Hi Andrew,

is / will be there be some public output of your little secret project?

-- 

-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: A proposal for generic in go

[andrew . mezoni]

>> I was one of the generics supporters for Go in this forum, but now I am 
not so sure.

But why?
Generic types is the same types as and the regular types.
Difference only in that the regular types does not have a parameters but 
generic types are always have at least one parameter.
This is why they are called generic (universal) types.
The same as you don't worry about that the function can have a parameters 
why you should worry about that the type can have a parameters?
When for types allowed to have parameters then this get a some benefits:
1. Generice types can be "configured" by some requirements (by their 
parameters)
2. Generice types can have a restrictions (eg. each parameter can have its 
own upper type bounds)
3. Generic types are universal types

Eg. Trivial example

type KeyValuePair struct {
  key K
  val V
}

You can use this type everywhere since it is universal type.

Below is not the same type (because in generic type system K != V, but here 
interface{} == interface{}):

type KeyValuePair struct {
  key interface{}
  val interface{}
}

Because power of the generic types in that the they are variative:
- Covariant
- Contrvariant
- Invariant

And they, of course, can have a parameters.

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

[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[Benjamin Measures]

On Sunday, 19 June 2016 09:53:34 UTC+1, Simon Ritchie wrote:
>
> Whichever you choose, it will not be as good as PHP in some respects and I 
> predict that speed of redeployment will be one of them. 
>

When deploying to hundreds of servers, deploying hundreds of files to each 
becomes unmanageable. Facebook solved this by compiling everything into a 
single binary, which is how Go does things from the onset.

-- 
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 manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[Benjamin Measures]

On Thursday, 16 June 2016 16:02:50 UTC+1, romano.p...@gmail.com wrote:
>
> In Layman terms, if I had a portal in php I could (of course it depends on 
> situations) simply replace the pages of the module for the Service 1 
> without the need to stop everything (not only Service 2,3,4 and so on but 
> the whole portal).
>

Put a service router in front and make each an independent service [binary].

An example of such 
infrastructure: 
https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-router-for-gov-uk/

-- 
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] GoMobile window size always 800x800

[Daniel Skinner]

In my experience, designers aren't writing code or demoing experiences in
native code.

If they were, it wouldn't be that dissimilar to what I already see, either
resizing a window or choosing a specific window size in chrome dev tools.

Put bluntly, designers just aren't affected here and I think the problem
your having has more to do with how barebones gomobile is at the moment.

Allowing the window size change via the api is superficial and you would
quickly run into further hurdles. These hurdles are NOT invalid, they need
to be addressed, its just more complicated than the size of a window when
an app starts.

It's something I know I'm actively investigating. It's something seeing
action in exp/shiny with a flexbox implementation. It's a hot topic to say
the least. And hopefully in the future there will be the tools available to
allow you to look at your app beyond a pixel perfect representation for a
specific mobile device, and as to something more, but for now "responsive
ui" and concessions on a 1:1 aspect ratio being a bit non sensical are
probably as good as it gets.

Personally I think the solutions to these kinds of issues are purely
numerical and should be easy to adopt in any codebase. Do you already have
some sort of widget/ui library in the public? It might be more helpful to
see how a responsive approach there really blows concerns for different
sizes or a particular startup size away from concern.

On Fri, Jun 17, 2016, 5:52 PM Andy Brewer  wrote:

> OK, so designers will want to quickly test their app at specific screen
> sizes. I think we just need to determine the best option because there
> doesn't seem to be a gomobile best practice.
>
> It sounds like we have the following options:
> 1. Run a script to resize the window (
> http://www.labnol.org/software/resize-mac-windows-to-specific-size/28345/).
> Upside: Works with current codebase. Downside: no cross-platform solution,
> some solutions require extra clicks/typing, might need extra scripts for
> each size.
> 2. Run the app inside an emulator. Upside: works with current codebase.
> full emulator control (wifi, settings, etc.). Downside: long testing
> cycles, 10s+ (noted as a problem the gomobile viewport is trying to solve:
> http://www.youtube.com/watch?v=ZLq0Zeoyu6Y=3m13s)
> 3. Open up the API. Upside: developer control. Downside: Additional API
> complexity.
>
> In the David Crawshaw talk, it sounds like the purpose of the viewport is
> to not to replicate an emulator, but to improve the speed of the testing
> feedback cycle. As a designer, being able to control the height/width of
> the viewport would help me achieve that goal. We do the same thing with
> responsive web design. We build a responsive layout, and then use a browser
> extension to programmatically resize the browser to common screen
> resolutions.
>
> I know for me, this is actually a stumbling block that I researched online
> and found others having difficulty with as well. It would help a lot to
> have this feature, but I'm not familiar enough with the codebase or feature
> threshhold to understand the downside of adding it to the API.
>
> Andy
>
> On Fri, Jun 17, 2016 at 11:04 AM Daniel Skinner  wrote:
>
>> > but I still want to test my app at explicit screen sizes
>>
>> testing on actual hardware is still going to be the best, but I'd imagine
>> there's something out there for OSX that'd let you specify the exact window
>> size (of any window open).
>>
>> > Also, Android best practices does recommend as an option creating a
>> unique UI/layout for each screen size you want to support
>>
>> I'd say that recommendation is more of a state-of-current-affairs than an
>> actual ideal. Simply due to how things have been, it's generally easier to
>> maintain multiple xml layout files behind different resource flags. None of
>> that will even be available to you so you should be looking at more generic
>> best practices. For example, consider
>> https://material.google.com/layout/responsive-ui.html
>>
>> > Developers might also want to send screenshots to their clients [...] 
>> > Another
>> option would be to simply launch the app inside an emulator
>>
>> There's nothing prohibiting either. Here's an old screenshot from
>> something I put together that was running on an emulator and used the
>> screenshot util from android studio to frame it:
>> http://i.imgur.com/M5Jj6hJ.png
>>
>> On Fri, Jun 17, 2016 at 12:23 PM Andy Brewer  wrote:
>>
>>> Thanks. I'm wondering how I can test my UI efficiently with gomobile.  So,
>>> I will create a responsive design as you recommend, but I still want to
>>> test my app at explicit screen sizes to mimic the actual user experience,
>>> rather than approximate it.
>>>
>>> The use case is someone who wants to support iPhone 4 and up. Most
>>> designers would want to test their UI against the actual screen size of the
>>> iPhone 4, 5, 6 and 6+, even if the UI is built to be fully responsive 

[go-nuts] Re: A proposal for generic in go

[Henry]

I think we should carefully consider whether generics is worthy enough to be 
added into the language. It is easy to add a feature, but nearly impossible to 
remove one without breaking the backward compatibility promise. 

One thing for sure is that we are in the middle of a paradigm shift. I am 
seeing more and more codes blending OOP with elements of functional 
programming. Some OOP purists go as far as avoiding getter/setter and use DTO 
to allow data editing, which to me it looks like a separation of data and 
function in procedural programming. Whatever the latest trend is, we shouldn't 
let Go become another C++ by blindly following trends. Everything must be 
thought of carefully. 

I was one of the generics supporters for Go in this forum, but now I am not so 
sure.

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

Re: [go-nuts] [?] emulating an opengl shader in cpu bound functions

[Daniel Skinner]

I pinned this question to my email b/c I'm going to be doing something
similar soon and why not help a similar soul out, but really even though I
can't give you a straight answer now, the answer is still pretty straight
forward.

There's nothing predominantly interesting between a gpu shader and a cpu
bound method generating an image. That's it. If you're seeing something
other than expected, it's simply due to error. Part of this may play a part
in actually understanding what a vertex and fragment shader is doing down
to each individual expression as it relates to a pixel... well, actually...
that's probably all of it.

I only very briefly glanced at your code and the glsl code you referenced
much earlier in the day and nothing at the time jumped out at me, but I'm
certain scrutiny would turn something up. It's important to understand how
a fragment shader works in relation to the pixels on screen, how any
derivative functions in use work in relation, and so on.

The only resource that's prohibitive in this case is time. Most things are
going to take longer to do on cpu, but there's nothing special about the
gpu or shader code here except that it runs in parallel very very fast.

So while "give more scrutiny" is all I have to offer atm, if you're having
some question of a gpu shader having access to some impossible data
inaccessible to the cpu, then I can only hope to completely throw that out
of thought so you may feel more comfortable giving scrutiny to your code vs
the shader code. That's where the problem is and that's where the problem
will be identified and fixed.

On Mon, Jun 20, 2016 at 10:03 AM  wrote:

>
> 
>
> I am attempting to generate a random starfield, in go. This is something
> that will need to printed on actual paper, but that is another issue and I
> only mention it to give some context for what I am doing here: Using go to
> create graphics to pair with something I'm already doing in go (I've been
> through several iterations of trying to use the go parts I have with
> numerous variations of tex/latex templates using asymptote, and I reached a
> point of frustration where I figured why not just do it all in go, as it
> seems less a problem than I originally thought -- but opens a new set of
> problems to solve, one of the biggest is that I know nothing at all about
> graphics, let alone how to apply graphics in go).
>
> Cosmic1 from:
> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16,
> generates the above it is the first thing that even roughly approximates
> what I want to do.
>
> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't
> directly translate an opengl shader to something cpu bound(which I suspect
> is a thing, I may need to do more that I can't see right now).
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: A proposal for generic in go

[andrew . mezoni]

>> While later I realized that we still need some parameter check in the 
callee code to satisfy the interface matching (the generic version of each 
function in my proposal).

A am sorry but your judgements is not correct.
Here is a proofs:
1. It is redundant to perform check of the correctness of the assignments 
after when assignement already made.

Eg.

val i int
i = 0
// It is redundant to perform check the correctness of the assignments of 
`i` after when assignement of `i` already made.

2. Fucntion is a callable piece of code which CAN have initial variables 
(function parameters) which SHOULD be assigned (via function arguments) 
before function invocation.

Of course, these parameters can be explicit and implicit.
Eg. receiver of the method is an implicit parameter but it still a 
parameter (function variable which would be assigned before function 
invocation implicitly by the compiler, or by the reflection construction).

That is, this code is equilvalent.

var i int
i = 0
// other code, `i` already assigned

func foo(i int) {
  // other code, `i` already assigned
}


3. Also you should to know that in a generic type system (type sytem with 
the generic types) each type is potentialy a generic type.
Here is a proof.

Each type in a generic type system looks like a function.
Type can have a [0..~] number of parameters which are declared by the type 
declaration and whose parameters can be assigned by the type arguments. If 
arguments omitted then parameters assigned to default values (types).


The same as the funtions.

// Declare type with 2 parameters, K and V
type Type {}

// Declare type with 2 bounded parameters, K and V
type Type1 {}

// Instantiate new type with a specified arguments (the same as the 
function invocation)
// For simplicity we can imagine the following auto generated code
// if *__staticType1021 == nill {
//   *__staticType1021 = __createGenericType(__getType(Type1), 
__getType(string), __getType(bool))
//  That is, call to __createGenericType(*t RType, args... *RType)
// }

// foo := __newobject(*__staticType1021)

foo := Type1()

Another story when we use generic type on the callee side.

func (t *Type1) foo(key K) V {
  // Here compiler always assume that the type of `t` is a generic type 
`Type1` with a correctly assigned type arguments.
  // Assigned arguments does not need to re-check 
  // ___type0 := __getTypeOf(t)
  // Here is enough (since type are generic) rely only on that the each 
type argument bound to the type parameter
  ...
}


-- 
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] Unmarshalling and tags

[Ain]

teisipäev, 21. juuni 2016 9:47.54 UTC+3 kirjutas rog:
>
> I feel your pain - we quite often have tags with entries for three 
> formats (JSON, YAML and BSON) - but I'm not sure that collapsing them 
> is necessarily a good idea, as the named tags indicate that the object 
> is explicitly intended to be able to be marshaled with those formats. 
>

Another idea is to allow the tags to be defined by more than one string:

type Payment struct { 
ActionType paypal.ActionType `xml:"actionType,omitempty"` 
 `json:"action"`
ReceiverList paypal.ReceiverList 
`xml:"receiverList,omitempty"`  `json:"receiver"`
} 

compiler would concatenate them into single string so all code will 
continue to work but this would allow the gofmt to align them into neat 
columns, making it easier to read.


ain 

-- 
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] Unmarshalling and tags

[roger peppe]

I feel your pain - we quite often have tags with entries for three
formats (JSON, YAML and BSON) - but I'm not sure that collapsing them
is necessarily a good idea, as the named tags indicate that the object
is explicitly intended to be able to be marshaled with those formats.

That said, it's quite common for us to have an issue where someone has
(say) tagged for YAML but not for JSON.

Given that there is (more-or-less) a standard subset of the tags that
works between encodings, maybe it would make sense to have
a standard tag that could be used for all of them, similarly to the
way that TextUnmarshaler and TextMarshaler are supported across
most encodings.

For example:

type Payment struct {
ActionType paypal.ActionType `encode:"actionType,omitempty"`
ReceiverList paypal.ReceiverList `encode:"actionType,omitempty"`
}

One would need to define the format quite carefully,
and perhaps define things so that attributes not recognised
by a particular encoder are ignored (allowing, for example,
an XML-specific "attr" tag without preventing JSON
from using it)

Then of course every existing encoder would need to be updated
to recognise it...

  cheers,
rog.

On 19 June 2016 at 13:42, 'Mihai B' via golang-nuts
 wrote:
> Hi there,
>
> I have a struct that needs to be marshalled/unmarshalled using various
> serialization formats(xml, json, name/value). The tags start to represent a
> considerable effort[0] so I'm wondering if this is a common use case and if
> a change[1] to the encoding packages to specify the tag key/selectors would
> be a bad idea. Another option would be to use a standard tag key as default
> (e.g. "encoding") but I think it may violate  the Go1 backward
> compatibility.
>
> Mihai.
>
>
> [0]
> type Payment struct {
> ActionType paypal.ActionType `query:"actionType,omitempty"
> json:"actionType,omitempty"  xml:"actionType,omitempty"`
> ReceiverList paypal.ReceiverList `query:"actionType,omitempty"
> json:"receiverList,omitempty"  xml:"receiverList,omitempty"`
> }
>
>
> [1] (dec *Decoder)SetTagKey(key string)
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] [?] emulating an opengl shader in cpu bound functions

[Christian Mauduit]

Hi,

Using OpenGL to draw something that will end up on paper might prove
somewhat complicated. As for "translating" a shader to something cpu
bound, since a shader is more or less a program in some language that
"has some remote parentness with C", you could probably do it. But the
most pragmatic way, IMHO, is to understand what the program does and
rewrite it. If you really want to leverage OpenGL's power, I know it
allows you to render "in memory" so you could draw things on a virtual
screen, grab the output, and you're set. To some extent, recent OpenGL
with shaders is more or less a generic way to harness the power of
massive parallel, dedicated hardware, and it's very versatile. But
complex as well.

If you are not a graphics guru, I'd advice you to use a plain simple
native Go library, there are several candidates, one is :

https://github.com/llgcode/draw2d/

Have a nice day,

Christian.

On 06/20/2016 05:02 PM, bluebl...@gmail.com wrote:
> 
> 
> 
> I am attempting to generate a random starfield, in go. This is something
> that will need to printed on actual paper, but that is another issue and
> I only mention it to give some context for what I am doing here: Using
> go to create graphics to pair with something I'm already doing in go
> (I've been through several iterations of trying to use the go parts I
> have with numerous variations of tex/latex templates using asymptote,
> and I reached a point of frustration where I figured why not just do it
> all in go, as it seems less a problem than I originally thought -- but
> opens a new set of problems to solve, one of the biggest is that I know
> nothing at all about graphics, let alone how to apply graphics in go).
> 
> Cosmic1 from: 
> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16,
> generates the above it is the first thing that even roughly approximates
> what I want to do.
> 
> Any thoughts, or help cleaning that up. Maybe tell me why exactly I
> can't directly translate an opengl shader to something cpu bound(which I
> suspect is a thing, I may need to do more that I can't see right now).
> 
> -- 
> 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.

-- 
Christian Mauduit
uf...@ufoot.org
http://www.ufoot.org
int q = (2 * b) || !(2 * b);

-- 
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: Result is sometimes different despite using same value when encode by encoding/gob

[Harry]

Thank Dave and Jan.

I understood completely.
I'd consider another solution to manage that next.

Thanks again.


Harry.


2016年6月21日火曜日 14時58分39秒 UTC+9 Dave Cheney:
>
> To serialise the keys and values of a map and code would have to iterate 
> over it
>
> for k,v := range m { 
>// serialise k and v
> }
>
> But map iteration does not have a guaranteed ordering. This is why the 
> result is not stable.
>
> On Tuesday, 21 June 2016 15:44:05 UTC+10, Harry wrote:
>>
>> Hello guys,
>>
>> I'm trying to use encoding/gob package to know how it works.
>> And I wrote below codes.
>>
>>
>>
>> import "encoding/gob"
>>
>>
>> func ToGOB64(data interface{}) (string, error) {
>>  b := bytes.Buffer{}
>>
>>  e := gob.NewEncoder()
>>  err := e.Encode(data)
>>  if err != nil {
>>  fmt.Println(`failed gob Encode`, err)
>>  return "", err
>>  }
>>  return base64.StdEncoding.EncodeToString(b.Bytes()), nil
>>
>> }
>>
>>
>>
>> func FromGOB64(str string, tData interface{}) error {
>>
>>  by, err := base64.StdEncoding.DecodeString(str)
>>
>>  if err != nil {
>>  return err
>>
>>  }
>>  b := bytes.Buffer{}
>>  b.Write(by)
>>  d := gob.NewDecoder()
>>  err = d.Decode(tData)
>>  if err != nil {
>>  return err
>>
>>  }
>>  return nil
>> }
>>
>>
>> And then, I prepared for test targeted type are struct, map, interface{}.
>>
>> func TestSerializeStruct(t *testing.T) {
>>  u := User{Id: 10, Name: "harry dayo"}
>>
>>  result, err := ToGOB64(u)
>>  if err != nil {
>>  t.Errorf("TestSerializeStruct error: %s", err)
>>  }
>>  if result != 
>> "Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA=" 
>> {
>>  t.Errorf("TestSerializeStruct result: %+v", result)
>>  }
>> }
>>
>>
>>
>> func TestDeSerializeStruct(t *testing.T) {
>>
>>
>>  u := User{}
>>  err := FromGOB64(
>> "Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA="
>> , )
>>  if err != nil {
>>  t.Errorf("TestDeSerializeStruct error: %s", err)
>>  }
>>  if u.Id != 10 {
>>  t.Errorf("TestDeSerializeStruct result: %+v", u)
>>  }
>> }
>>
>>
>> //2.map (map is not stable.)
>> func TestSerializeMap(t *testing.T) {
>>
>>
>>  m := map[string]int{"apple": 150, "banana": 300, "lemon": 300}
>>  //when using map, result is not stable.
>>  result, err := ToGOB64(m)
>>  if err != nil {
>>  t.Errorf("TestSerializeMap error: %s", err)
>>  }
>>  if result != 
>> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY" {
>>  //if result != 
>> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs" {
>>  t.Errorf("TestSerializeMap result: %#v", result)
>>  }
>> }
>>
>>
>> //
>> func TestDeSerializeMap(t *testing.T) {
>>
>>
>>  u := map[string]int{}
>>  
>> //FromGOB64("Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY",
>>  
>> )
>>  err := FromGOB64(
>> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs", )
>>  if err != nil {
>>  t.Errorf("TestDeSerializeMap error: %s", err)
>>  }
>>  if u["apple"] != 150 {
>>  t.Errorf("TestDeSerializeMap result: %#v", u)
>>  }
>> }
>>
>>
>>
>> //interface x slice
>> func TestSerializeInterfaces(t *testing.T) {
>>
>>
>>  args := []interface{}{1, "abcde", true}
>>  result, err := ToGOB64(args)
>>  if err != nil {
>>  t.Errorf("TestSerializeInterfaces error: %s", err)
>>  }
>>  if result != 
>> "DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB" {
>>  t.Errorf("TestSerializeInterfaces result: %+v", result)
>>  }
>> }
>>
>>
>>
>> func TestDeSerializeInterfaces(t *testing.T) {
>>
>>
>>  args := []interface{}{}
>>  err := FromGOB64(
>> "DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB", &
>> args)
>>  if err != nil {
>>  t.Errorf("TestDeSerializeInterfaces error: %s", err)
>>  }
>>  if args[0] != 1 || args[1] != "abcde" || args[2] != true {
>>  t.Errorf("TestDeSerializeInterfaces result: %+v", args)
>>  }
>> }
>>
>>
>>
>> As a result, serialized map value often change though deserialized map is 
>> no problem.
>> Why serialized value is not invaliable when using map value.
>>
>> I'd like to know that reason sincerely.
>>
>> Thanks in advance.
>>
>>
>>
>>
>>
>>

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

Re: [go-nuts] Result is sometimes different despite using same value when encode by encoding/gob

[Jan Mercl]

On Tue, Jun 21, 2016 at 7:44 AM Harry  wrote:

> Why serialized value is not invaliable when using map value.

Map keys are comparable but they are not required to be ordered
, ie. sorting them before
serializing is not only costly, but in the general case not (directly)
possible.

-- 

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