[go-nuts] iota with gaps

[Jérôme LAFORGE]

const (
_ = iota 
One
Two
Three 
_
_
_
Seven
Eight 
Nine 
) 

-- 
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] iota with gaps

[Tong Sun]

Hi, 

How to use `iota` to define consts that have gap(s) in them? 

E.g., If my consts are, 

1, 2, 3, 7, 8, 9

How to use iota to define them? Thx. 


-- 
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: Ecdsa different behaviour on 32-bit and 64-bit system

[Todd Neal]

Ivan,

I tracked down the problem to a difference between the generic and 
optimized versions of the P256 implementations.  I'm not 100% sure of the 
correct fix, so I submitted it as golang.org/issues/20215 with a link to 
your example.

- Todd

On Tuesday, May 2, 2017 at 12:33:56 PM UTC-5, Ivan Voras wrote:
>
> Hi, 
>
> I'm using ECDSA with the P256 curve and I've found a problem which I've 
> tracked to a different result of signature verification on the Raspberry Pi 
> and x64 (both Linux and Windows). Later I've verified that i386 behaves as 
> RPI. I've tracked the problem down to this self-contained case: 
>
> https://gist.github.com/ivoras/32b2abd16b5984fa43c006486bfb7e2c 
>
> It's trivial to build. When run on the RPI or i386, verification succeeds. 
> On x64, it fails. RPI is running little-endian Ubuntu 16.04.2, 32-bit. 
>
> Am I doing something wrong or is it a bug in the libs? I've updated all 
> systems to Go 1.8.1, but I've noticed this behaviour on 1.7 (and the update 
> didn't solve it).

-- 
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] Fully-qualified import paths and Pull Requests

[st ov]

How should import paths be handled with regard to pull requests?

For example, I fork a project and add an internal package. 
Convention says I should use the fully-qualified import path in my own 
project.
When creating a pull request this import path would need to be updated to 
point to the upstream project.

Does the person accepting the pull request, make the modification? Should 
that be noted in the pull request?
Is there a better way, that doesn't risk someone forgetting to update the 
import path?

-- 
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: Build problem in Liteide

[mahuaduttakundu]

Is this possible to add FileDebug similarly ?

On Wednesday, February 17, 2016 at 9:27:17 PM UTC+5:30, Jose Maria Galeano 
wrote:
>
> It was easy forme I add a ne commnad in View -> Options -> LiteBuild 
> ...edit gosrc.xml
> and add this line
>  args="build $(EDITOR_FILE_NAME)" save="editor" output="true" codec="utf-8" 
> readline="true" work="$(EDITOR_DIR_PATH)"/>
>
> A new Action FileBuild taht is the stuff taht the editor do not has... you 
> can modify the key and add a png for the buttom
> and is teh better solution no more package build!!! for one file alone!
>
> El lunes, 18 de junio de 2012, 9:45:18 (UTC-3), Arie van Wingerden 
> escribió:
>>
>> Hi,
>>
>> when I try to BR (Build and Run) this source in Liteide:
>>
>> package main
>>>
>>> import (
>>>
>>> "fmt"
>>>
>>> "math"
>>>
>>> )
>>>
>>> var z float64 = 1.0
>>>
>>> func Sqrt(x float64) float64 {
>>>
>>> zold := z
>>>
>>> z = z - (z*z - x) / (2*z)
>>>
>>> fmt.Println(z)
>>>
>>> if math.Abs(z - zold) < 0.0001 {
>>>
>>> return z
>>>
>>> }
>>>
>>> return Sqrt(x)
>>>
>>> }
>>>
>>> func main() {
>>>
>>> fmt.Println(Sqrt(2.0), math.Sqrt(2.0))
>>>
>>> }
>>>
>>>
>> I get this error:
>>
>>> >> work="D:/src/Go">
>>
>> >c:/go/bin/go.exe build 
>>
>> # _/D_/src/Go  
>>
>> .\sqrt.go:20: main redeclared in this block  
>>
>> previous declaration at .\hello.go:6 
>>
>> > exit code 2, process exited normally. 
>>
>>  
>>
>>
>> However, when I do a separate Build and Run, no compiler errors and the 
>> program runs fine.
>>
>> A bug?
>>
>> Thx,
>>Arie 
>>
>>

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

[go-nuts] Re: encoding/json: unexpected behaviour when unmarshalling into struct with interface{} field

[Frits van Bommel]

On Tuesday, May 2, 2017 at 10:53:36 PM UTC+2, Brian Stengaard wrote:
>
>
> On Tuesday, 2 May 2017 16:02:47 UTC-4, Pierre Curto wrote:
>>
>> Hello,
>>
>> My guess:
>> If you dont pass in a pointer, then you pass a value.
>> What would be the point of updating the value that you will never see and 
>> that will get discarded?
>> Hence it returns a map that provides the unmarshaled values so at least 
>> you have something to work with.
>>
>>>
>>>
> True, if I pass in a raw value wrapped in a blank interface. In this case 
> we are talking about a field on a struct that is already addressable - 
> which in turn makes the content of the struct field addressable - then why 
> not just update the underlying value?
>

You can't update a raw value in an interface, you can only replace it. (the 
interface value is addressable, but the value it contains isn't)
It works with pointers because only the data pointed to changes, not the 
pointer itself.

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

[go-nuts] Re: encoding/json: unexpected behaviour when unmarshalling into struct with interface{} field

[Brian Stengaard]

On Tuesday, 2 May 2017 16:02:47 UTC-4, Pierre Curto wrote:
>
> Hello,
>
> My guess:
> If you dont pass in a pointer, then you pass a value.
> What would be the point of updating the value that you will never see and 
> that will get discarded?
> Hence it returns a map that provides the unmarshaled values so at least 
> you have something to work with.
>
>>
>>
True, if I pass in a raw value wrapped in a blank interface. In this case 
we are talking about a field on a struct that is already addressable - 
which in turn makes the content of the struct field addressable - then why 
not just update the underlying value?

/Brian 

-- 
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: Sorting an array of time.Duration

[ramachandrang]

Thank you JuciÊ Andrade & Roberto.

On Tuesday, May 2, 2017 at 12:07:19 PM UTC-7, JuciÊ Andrade wrote:
>
> From Go v1.8 onwards there is yet another alternative: you can use the 
> sort package without implementing the Sort interface.
>
> Example:
>
> https://play.golang.org/p/YmiWpshLlX
>

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

[go-nuts] Re: encoding/json: unexpected behaviour when unmarshalling into struct with interface{} field

[pierre . curto]

Hello,

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

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

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

Re: [go-nuts] Is there a way to fee a memory object on demand?

[Jan Mercl]

On Tue, May 2, 2017 at 8:35 PM Piotr Narewski  wrote:

> Does anyone know a way to do something like this (freeing memory on
demand), but using pure Go?
> Something that will compile (and work) on any platform, without any extra
dependencies..

sync.Pool could be probably a good fit. Usage example:
https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/slice/pool.go
-- 

-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: Sorting an array of time.Duration

[ojucie]

>From Go v1.8 onwards there is yet another alternative: you can use the sort 
package without implementing the Sort interface.

Example:

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

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

[Brian Stengaard]

Hey Gophers,

When unmarshalling JSON into a struct with a blank interface (interface{}) 
I get a surprising result:

If I set the field to a pointer to a T value before unmarshalling, the data 
is filled out on the T value as expected. (See I2 in the playground 
example.)

If I set the field to a T value before unmarshalling, field will be set to 
a map[string]interface{} when returning, I was expecting a T value. 

Since the field is not nil I would expect json.Unmarshal to just fill in 
the fields on the data structure provided, not override the field value. 

What am I missing? 

Example: https://play.golang.org/p/O-55nj0h44 why is I1 a 
map[string]interface{} when I already gave it a T value?

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

[go-nuts] Re: Sorting an array of time.Duration

[Roberto Zanotto]

Seems to me that you didn't understand how to use sort, it's a bit 
different from what you are used to in other languages. Take a look at the 
examples in the package docs https://golang.org/pkg/sort/#example_

On Tuesday, May 2, 2017 at 8:16:20 PM UTC+2, ramach...@qualtrics.com wrote:
>
> Hello, 
>
> I have an array of time.Duration. I want to be able to sort this to do 
> tp90, tp99 calculations. The sort.Sort() library function doesn't work on 
> time.Duration. The error I get is 
>
> *time.Duration does not implement sort.Interface (missing Len method)*
>
> Anyone know if I can add the Len() method to type Duration? This post 
> seems to say no - 
> https://groups.google.com/forum/#!topic/golang-nuts/Hbxekd9g09c
>
> Thanks,
> ram.
>

-- 
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] Is there a way to fee a memory object on demand?

[Piotr Narewski]

My app uses large amounts of memory; it actively allocates and frees lots 
of slices.
I'm talking about gigabytes here.

With the default GOGC=100 setting, it needs twice more memory.

When I decrease GOGC to a lower value, it affects performance pretty badly.

So far the best solution I have found is this:

*
/*
#include 
*/
import "C"

func gcc_malloc(le uint32) unsafe.Pointer {
ptr := unsafe.Pointer(C.malloc(C.size_t(le+4)))
*((*uint32)(unsafe.Pointer(ptr))) = le
return ptr
}

func gcc_free(ptr unsafe.Pointer) {
C.free(unsafe.Pointer(ptr))
}

func gcc_len(ptr unsafe.Pointer) int {
return int(*((*uint32)(ptr)))
}

func gcc_slice(ptr unsafe.Pointer) []byte {
le := gcc_len(ptr)
return *(*[]byte)(unsafe.Pointer({Data:uintptr(ptr)+4, 
Len:le, Cap:le}))
}
*

So if I need a new slice to store a data, I do:
 slice := gcc_slice(gcc_malloc( HOW_MANY_BYTES ))

Then, when I no longer need this slice, I just do something like:
 gcc_free(unsafe.Pointer())

It works and performs very well, but I have a problem with compatibility on 
different platforms.
For instance, it needs gcc compiler...

Does anyone know a way to do something like this (freeing memory on 
demand), but using pure Go?
Something that will compile (and work) on any platform, without any extra 
dependencies..

-- 
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] Sorting an array of time.Duration

[ramachandrang]

Hello, 

I have an array of time.Duration. I want to be able to sort this to do 
tp90, tp99 calculations. The sort.Sort() library function doesn't work on 
time.Duration. The error I get is 

*time.Duration does not implement sort.Interface (missing Len method)*

Anyone know if I can add the Len() method to type Duration? This post seems 
to say no - https://groups.google.com/forum/#!topic/golang-nuts/Hbxekd9g09c

Thanks,
ram.

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

[go-nuts] ...interface{} vs interface{} + reflection

[Jonathan Hall]

I have a public API that takes `...interface{}` as an argument.  (For 
reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs )

I'm considering changing this to instead take `interface{}` as an argument, 
then using reflection to:

  - Validate that the underlying type is an array
  - Convert to `[]interface{}` before using it internally

The reason I'm considering the change is that the normal use-case for the 
function is on an array of specifically-typed documents, and converting to 
`[]interface{}` before every call is cumbersome, and redundant ~95%+ of the 
time.

I'm wondering if I might be overlooking any obvious drawbacks to this 
approach.  Thus far, my hesitation comes from the following facts:

- Using reflection to check that an argument is an array seems sloppy 
(although I've seen it before). It loses all benefits of compile-time 
checking
- Using reflection for the conversion is presumably slower than doing the 
conversion in the caller.

Are there other pros or cons I'm not considering that I should take into 
account when deciding how to proceed?

Much thanks,

-- Jonathan

-- 
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/cmd erroneous compile error: initialization loop

[max . dergosits]

This gives me a compilation error:

https://play.golang.org/p/5nSLXw9n82

but this does not: 

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

I  expected to see no error, and have a valid go program, since there are 
no real initialization dependencies.

This is the output I got:

> tmp/sandbox944533800/main.go:5: initialization loop:
> prog.go:5 x refers to
> prog.go:7 bar refers to
> prog.go:5 x

version, os, arch:

1.8
GOOS=nacl
GOARCH=amd64p32

-- 
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] Ecdsa different behaviour on 32-bit and 64-bit system

[ivoras]

Hi,

I'm using ECDSA with the P256 curve and I've found a problem which I've tracked 
to a different result of signature verification on the Raspberry Pi and x64 
(both Linux and Windows). Later I've verified that i386 behaves as RPI. I've 
tracked the problem down to this self-contained case:

https://gist.github.com/ivoras/32b2abd16b5984fa43c006486bfb7e2c

It's trivial to build. When run on the RPI or i386, verification succeeds. On 
x64, it fails. RPI is running little-endian Ubuntu 16.04.2, 32-bit.

Am I doing something wrong or is it a bug in the libs? I've updated all systems 
to Go 1.8.1, but I've noticed this behaviour on 1.7 (and the update didn't 
solve it).

-- 
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] Plugin Golang for SonarQube

[Falque Thibault]

Hi all, 

I have created the Golang Sonarqube Plugin 
. 

For the moment, 34 rules from GoLint are activated in the profile and  
provides tests and test coverage metrics.

Any feedback or contribution much appreciated! 

Thanks in advance,
Thibault. 

-- 
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: "Selling" Go to Management

[andrey mirtchovski]

On Tue, May 2, 2017 at 10:39 AM,   wrote:
> - Hey, boss, I want to show a novelty. It's called AUTOMOBILE.
> - Go ahead.
> - It can carry you to any place you want.
> - My horse can carry me to any place I want as well. So what?
> - No, I mean, an automobile is much more confortable.
> - Have you ride my horse?
> - No, I didn't.
> - So you are not entitled to say your auto-whatever is more confortable than
> my horse.
> - Ok, let's say the automobile is safer than a horse. It has 4 wheels. You
> can't fall from an automobile like you can fall from a horse.
> - What? Did you say "wheels"? Come on. And then you say we can go anywhere
> inside an auto-whatever. You must be kidding. The terrain is very rough,
> son.
> - One must build a road first.
> - Ahahahah.
> - Ok, boss, listen: once we get roads and automobiles we would be able to
> travel at 60 Mph easy.
> - I don't think human beings are made to travel at those speeds. What a
> dangerous proposition.
> - Inside an automobile you are shielded from the weather. If it rains you
> are protected.
> - If that really bothers you, the answer is very simple: use a carriage.
> There is a variety of types, ranging from very cheap to very expensive. A
> carriage can be as confortable as you want.
> - Oh, man. Can't you see?
> - There is nothing to be seen here. Sorry. What kind of food your
> auto-whatever needs to eat?
> - Gasoline.
> - What is gasoline?
> - It is a petrol derivative.
> - By the sake of God, where do you think we would get that stuff?
> - Someone needs to produce it by refining petrol.
> - Ahahahaha! I think we should adhere by our proven methods, thanks. Now get
> quiet and go back to work.
>
> --
> 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: "Selling" Go to Management

[ojucie]

- Hey, boss, I want to show a novelty. It's called AUTOMOBILE.
- Go ahead.
- It can carry you to any place you want.
- My horse can carry me to any place I want as well. So what?
- No, I mean, an automobile is much more confortable.
- Have you ride my horse?
- No, I didn't.
- So you are not entitled to say your auto-whatever is more confortable 
than my horse.
- Ok, let's say the automobile is safer than a horse. It has 4 wheels. You 
can't fall from an automobile like you can fall from a horse.
- What? Did you say "wheels"? Come on. And then you say we can go anywhere 
inside an auto-whatever. You must be kidding. The terrain is very rough, 
son.
- One must build a road first.
- Ahahahah.
- Ok, boss, listen: once we get roads and automobiles we would be able to 
travel at 60 Mph easy.
- I don't think human beings are made to travel at those speeds. What a 
dangerous proposition.
- Inside an automobile you are shielded from the weather. If it rains you 
are protected.
- If that really bothers you, the answer is very simple: use a carriage. 
There is a variety of types, ranging from very cheap to very expensive. A 
carriage can be as confortable as you want.
- Oh, man. Can't you see?
- There is nothing to be seen here. Sorry. What kind of food your 
auto-whatever needs to eat?
- Gasoline.
- What is gasoline?
- It is a petrol derivative.
- By the sake of God, where do you think we would get that stuff?
- Someone needs to produce it by refining petrol.
- Ahahahaha! I think we should adhere by our proven methods, thanks. Now 
get quiet and go back to work.

-- 
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] Strange Go runtime behavior related to xml.Unmarshal

[Ian Lance Taylor]

On Tue, May 2, 2017 at 2:43 AM, Nikos Anastopoulos  wrote:
>
> Thanks for your feedback.  As a last question, what is the application
> aspect (or other factors) that determines how quickly new threads are being
> employed over time? For example, in my scenario above, if I choose to do the
> parsing using plain regexp rather than xml.Unmarshal, the threads will reach
> a count of ~8 within the same period (4 mins), vs 28 when using
> xml.Unmarshal. In some other Go apps, threads will remain constant (i.e., 4)
> forever. Where is this difference attributed?

I don't know that there is any one thing.  I would expect to be based
primarily on how many different goroutines are started and how often
those goroutines block in a system call.  In general the Go runtime
does not try to limit threads to less than GOMAXPROCS.

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: Testing reflect.type for equality with another type

[mhhcbon]

yes, you can use Name / PgkPath methods to test equality.

https://golang.org/pkg/reflect/#Type

Those methods might be useful too,

// Implements reports whether the type implements the interface type u.
Implements(u Type ) bool 


// AssignableTo reports whether a value of the type is assignable to 
type u.
AssignableTo(u Type ) bool 


// ConvertibleTo reports whether a value of the type is convertible to 
type u.
ConvertibleTo(u Type ) bool 


And the doc says,


// String returns a string representation of the type.
// The string representation may use shortened package names
// (e.g., base64 instead of "encoding/base64") and is not
// guaranteed to be unique among types. To test for type identity,
// compare the Types directly.
String() string 


>compare the Types directly.

I understand it means you need to iterate field and methods to test more.


On Tuesday, May 2, 2017 at 4:47:37 AM UTC+2, nz wrote:
>
> Hi
>
> As far as I can tell two reflect.Type's should be equal, but they fail 
> equality (==) test, printing the reflect.Type using "%#v" of the types 
> yields identical values
>
> {size:0x8, ptrdata:0x8, hash:0xdd3884e8, tflag:0x1, 
> align:0x8, fieldAlign:0x8, kind:0x36, alg:(*reflect.typeAlg)(0x136b930), 
> gcdata:(*uint8)(0xd60948), str:145804, ptrToThis:0}
> {size:0x8, ptrdata:0x8, hash:0xdd3884e8, tflag:0x1, 
> align:0x8, fieldAlign:0x8, kind:0x36, alg:(*reflect.typeAlg)(0x136b930), 
> gcdata:(*uint8)(0xd60948), str:145804, ptrToThis:0}
>
> When I invoke them they appear to create the same instance (printing using 
> "%#v") -
> (**my.TestObject)(0xc420196140)
> (**my.TestObject)(0xc420196148)
>
> Yet equality between types fails ... Is there something else that I can 
> test for ?
>
> thanks
> Nz
>
>

-- 
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: Will deleting a key from a map in an iteration prevent some keys being iterated in the same iteration?

['Keith Randall' via golang-nuts]

Yes, all keys present in the map at the start of iteration, that aren't 
deleted during iteration, will be returned during iteration.

On Monday, May 1, 2017 at 4:51:56 AM UTC-4, T L wrote:
>
>
>
> On Monday, May 1, 2017 at 3:56:51 PM UTC+8, Paul Jolly wrote:
>>
>> I think the part of the spec you're after is under the heading: 
>> https://golang.org/ref/spec#For_statements, specifically the sub-heading 
>> of that link "For statements with range clause", specifically point 3 in 
>> the enumerated list:
>>
>> *The iteration order over maps is not specified and is not guaranteed to 
>>> be the same from one iteration to the next. If map entries that have not 
>>> yet been reached are removed during iteration, the corresponding iteration 
>>> values will not be produced. If map entries are created during iteration, 
>>> that entry may be produced during the iteration or may be skipped. The 
>>> choice may vary for each entry created and from one iteration to the next. 
>>> If the map is nil, the number of iterations is 0.*
>>
>>
>>
>>
>>
> The guarantee I need is *every map entries created before the iteration 
> will be reached if it is not removed even if some entries are removed in 
> the iteration*.
> Looks this is silly. :) The answer should be yes I think.
>  
>
>>
>> On 1 May 2017 at 08:51, T L  wrote:
>>
>>>
>>>
>>> On Monday, May 1, 2017 at 3:50:11 PM UTC+8, T L wrote:

 for example

 for k, v := range m {
 if SatisfySomeCondition(k, v) {
 delete(m, k)
 }
 }

 will the above iteration guarantee to delete all k-v pairs from m?

>>>
>>>  will the above iteration guarantee to delete all k-v pairs satisfying a 
>>> condition from 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...@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] GC problem

[Jesper Louis Andersen]

I don't think it is a GC bug, but rather a trade-off of several desirable
properties.

The system does the following:

- allocates 2gb
- Since the current heap size is 0 the 10% gc limit is reached and a GC is
started concurrently with the program
- While the program processes the array, the GC finishes (using a separate
CPU core probably)
- The heap is now 2gb
- The next 2gb is requested
- Since the current heap size is 2gb, the limit of 10% is around 200mb.
This is reached, so a new concurrent allocation is started
- The system mallocs the 2gb in
- At this point, your program needs 4gb memory, but the GC is running and
immediately frees up 2 gigabytes
- ...
- The 2gigabytes are given back to the OS if nothing else in the program
needs it.

TL;DR: You must construct additional pylons!

You have two options if the malloc is denied by the operating system:

- Crash the program. This is the current behavior
- Block the program, try to GC and see if that frees up enough space.

I think Java did the blocking solution for a while. The problem with
blocking is that your program now has latency problems. Worse, a system
that is about to die ends up in a perpetual state where is grinds to a halt
while trying to squeeze out more bytes from the GC, but fails to do so,
which retrigger another blocking GC, and so on. Trying to recover from lack
of memory is almost always a futile endeavor which rarely ends up with good
results.

Go is a language created at solving systems problems. Systems problems
generally want low latency operation over high throughput, so a GC which
blocks the program is always undesirable.

Also, your program is somewhat extreme because it requests almost all of
the systems available memory very quickly. I know of no garbage collected
language implementation which fares well in that situation :)

On Tue, May 2, 2017 at 12:59 PM Serhat Sevki Dincer 
wrote:

> The allocation request (make) is made to the runtime which covers GC,
> right? GC percent is also set to 10%.
> After 1st call returns, my app has about 2gb ram allocated. When 2nd call
> requests allocation, runtime cannot:
> - first allocate another 2gb
> - free the 1st buffer later
> due to the definition of the GOGC (GC percent).
> I think this is a GC bug.
>
> 2 May 2017 07:09 tarihinde "Sokolov Yura"  yazdı:
>
>> GC is triggered *after* allocation than crosses boundary. So your second
>> allocation is actually tries to complete before first allocation freed. And
>> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause
>> overcommit is not enabled by default.
>>
>> Use C/C++, or buy more memory, or change your datastructure from slice to
>> slice of slice and allocate second dimension lazely, or call runtime.GC()
>> explicitely between calls to f() (it will block until GC finishes).
>>
>> --
>>
> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/HrZpsyfb3i0/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] GC problem

[Юрий Соколов]

There is nowhere told that GOGC defines border that could not be reached.
GOGC defines proportion that triggers GC, ie GC is triggered AFTER GOGC
proportion crossed, not before.

In fact, if you allocates by small portions, then GC tries to predict when
you will reach this border, and tries to start earlier. But it doesn't stop
your program if you run faster and cross this border, cause current Golang
GC us concurrent and tries to minimize GC pause. How could it minimize GC
pause if it ought to stop whole your program to not cross GOGC proportion?

And you partially right: GC of old Go's versions may stop program before
GOGC proportion crossed. So, if you try Go 1.0 most likely your programm
will run.

But new behaviour is much better.

The point: you should know your instrument and environment. No one GC
enabled runtime will be happy if you allocate huge arrays (perl/python/php
are exceptions, cause they use reference counting). If you ought to
allocate huge arrays in GC runtime, use off-heap allocation (Java men learn
that hard way).

For example, you may use mmap to allocate huge array.

Or, I'll repeat my self, use datastructure without huge continuous
allocation (ie slice of slices for your example). Then GC will have a
chance to trigger ealier and free some memory before it exhausted.

2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" 
написал:

The allocation request (make) is made to the runtime which covers GC,
right? GC percent is also set to 10%.
After 1st call returns, my app has about 2gb ram allocated. When 2nd call
requests allocation, runtime cannot:
- first allocate another 2gb
- free the 1st buffer later
due to the definition of the GOGC (GC percent).
I think this is a GC bug.

2 May 2017 07:09 tarihinde "Sokolov Yura"  yazdı:

GC is triggered *after* allocation than crosses boundary. So your second
> allocation is actually tries to complete before first allocation freed. And
> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause
> overcommit is not enabled by default.
>
> Use C/C++, or buy more memory, or change your datastructure from slice to
> slice of slice and allocate second dimension lazely, or call runtime.GC()
> explicitely between calls to f() (it will block until GC finishes).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/golang-nuts/HrZpsyfb3i0/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Feedback welcome: "Shorten your URL"

[Lutz Horn]

Hi,


To serve static files,
you can use one of the many pre defined go http handlers,

  fs := http.FileServer(http.Dir("static"))
  http.Handle("/", fs)

found this article, among many others,
http://www.alexedwards.net/blog/serving-static-sites-with-go


Yes, that's a good point. Reading the bytes every time is not a good 
idea.



I suspect this code here
https://github.com/lutzhorn/shorturl/blob/master/db.go#L34
might be optimized to avoid cpu consumption.

If you d flood that url, that would trigger as many heavy computations 
as

req,
so all reqs will be impacted by the slow cpu,
including those not doing this computation (and that is where is the 
pb).


You might put that computation into a limited worker pool
to slow down only that url and not impact all the server.


Compuation of a a new hashid should only happen on a POST request inside 
NewURL. The newHashID is not named very good, it does not to the 
computation, it constructs an object that is then later used to make the 
actual computation. But I will keep an eye on this.



https://github.com/lutzhorn/shorturl/blob/master/db.go#L74
you might try something like this to avoid repeating the rollback on 
error,

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


That looks interessting.

Thanks!

Lutz

--
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] openid connect

[aman]

hello go community,
how can i do authentication using openid for github and my local web app
how to create issuer url
what certificates and key i will have to generate for issuer 
how to make server for end-point connection for oauth2 and openid connect 

i am new to golang n am a noob :P
please do reply   

-- 
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: Feedback welcome: "Shorten your URL"

[mhhcbon]

hi,

some more sharings,

like val said, https://github.com/lutzhorn/shorturl/blob/master/main.go#L42 
is not optimum,

get ride of the anonymous func is obvious.
Note: that would have been useful in a loop iteration that spawns go 
routine.

To go beyond, I think you can do, signatures seems to match from here.

http.HandleFunc("/index.html", handler.Index)

when index is invoked, it will keep its receiver.


To serve static files,
you can use one of the many pre defined go http handlers,

  fs := http.FileServer(http.Dir("static"))
  http.Handle("/", fs)


found this article, among many others, 
http://www.alexedwards.net/blog/serving-static-sites-with-go


Based on that i suspect some changes will happen into handler.Root.

I suspect this code here
https://github.com/lutzhorn/shorturl/blob/master/db.go#L34
might be optimized to avoid cpu consumption.

If you d flood that url, that would trigger as many heavy computations as 
req,
so all reqs will be impacted by the slow cpu, 
including those not doing this computation (and that is where is the pb).

You might put that computation into a limited worker pool
to slow down only that url and not impact all the server.

But, maybe this hashing is very fast, i don t know about that.


https://github.com/lutzhorn/shorturl/blob/master/db.go#L63
this is tricky to make better in place, but it smells useless complexity.

https://github.com/lutzhorn/shorturl/blob/master/db.go#L74
you might try something like this to avoid repeating the rollback on error,
https://play.golang.org/p/DC2S1nVD8U

I also invite you to also check packages like dbr or gorm to handle the DB.



On Tuesday, May 2, 2017 at 9:32:45 AM UTC+2, Lutz Horn wrote:
>
> Hi Go Nuts, 
>
> to practice my Go skills, I've implemented a simple web application that 
> allows you to shorten an URL. The application consists of a backend 
> written in Go and a web frontend using jQuery with some plugins and 
> Bootstrap for layout. 
>
> The code is available on GitHub at https://github.com/lutzhorn/shorturl, 
> the application is deployed on https://u.lhorn.de. 
>
> I would very much appreciate any feedback you can give especially on the 
> Go part. Coming from a Java and Python background, I'm trying to get 
> into the Go way of programming, In Python there is a 'Pythonic' way to 
> write code, I am sure there is something similar in Go: File structure, 
> name choice, exporting names, error handling, ... 
>
> If you have a little time, please tak a look at the code, play with the 
> deployed application, and please give me feedback. 
>
> Thanks! 
>
> Lutz 
>
>
>

-- 
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] GC problem

[Serhat Sevki Dincer]

The allocation request (make) is made to the runtime which covers GC,
right? GC percent is also set to 10%.
After 1st call returns, my app has about 2gb ram allocated. When 2nd call
requests allocation, runtime cannot:
- first allocate another 2gb
- free the 1st buffer later
due to the definition of the GOGC (GC percent).
I think this is a GC bug.

2 May 2017 07:09 tarihinde "Sokolov Yura"  yazdı:

> GC is triggered *after* allocation than crosses boundary. So your second
> allocation is actually tries to complete before first allocation freed. And
> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause
> overcommit is not enabled by default.
>
> Use C/C++, or buy more memory, or change your datastructure from slice to
> slice of slice and allocate second dimension lazely, or call runtime.GC()
> explicitely between calls to f() (it will block until GC finishes).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/HrZpsyfb3i0/unsubscribe.
> To unsubscribe from this group and all its topics, 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: [ANN] listser/mutexer/channeler: generators.

[mhhcbon]

Hi,


Some more about that.

I added tow new generators jsoner / httper.

jsoner takes a type in input, 
parses method args from a json body req, 
output func params to a json body response.
JSON-RPC.

httper, takes an http req in input,
interprets it as a json-rpc request,
pass it to the underlying RPC decoder (jsoner?)
and handle the response.

Still work to be done,
but looks at this main to get a json api,

package main

import (
"log"
"net/http"
)

// Tomate is about red vegetables to make famous italian food.
type Tomate struct {
Name string
}

// GetID return the ID of the Tomate.
func (t Tomate) GetID() string {
return t.Name
}

//go:generate lister vegetables_gen.go Tomate:Tomates
//go:generate jsoner json_vegetables_gen.go *Tomates:JSONTomates
//go:generate httper http_vegetables_gen.go *JSONTomates:HTTPTomates

func main() {

backend := NewTomates()
backend.Push(Tomate{Name: "red"})
jsoner := NewJSONTomates(backend)
httper := NewHTTPTomates(jsoner)

// public views
http.HandleFunc("/", httper.At)

/*
curl -H "Accept: application/json" -H "Content-type: 
application/json" -X POST -d ' {"i":0}'  http://localhost:8080/
*/

log.Fatal(http.ListenAndServe(":8080", nil))
}


Last note: can generics handle that ? (I dont think so)

On Saturday, April 29, 2017 at 5:08:52 PM UTC+2, mhh...@gmail.com wrote:
>
> i forgot to say at the end, id love to be able to do
>
> cat mystruct.go | lister Tomates | mutexer Tomatex | 
>
> That d be awesome! :D
>
> On Saturday, April 29, 2017 at 5:06:27 PM UTC+2, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> several generators i made to avoid some duplication.
>>
>> https://github.com/mh-cbon/lister
>>
>> Package lister is a generator to generate typed slice.
>>
>>
>> https://github.com/mh-cbon/channeler
>>
>> Package channeler is a cli generator to generate channeled version of a 
>> type.
>>
>> https://github.com/mh-cbon/mutexer
>>
>> Package mutexer is a cli generator to generate mutexed version of a type.
>>
>>
>> so basically, using below code you got hundreds of line generated for you,
>>
>>
>> in that example to make a mutexed []Tomate.
>>
>>
>> But as it s not too stupid, or tries too, it will be able to handle 
>>
>> pointer and basic types
>>
>> mutexed []*Tomate
>>
>> mutexed []string
>>
>> ect
>>
>>
>> It should also be able to lookup for a constructor of the src type 
>> (Tomate),
>>
>> and reproduce it into the dest type implementation.
>>
>>
>> There is both mutexer / channeler because both cases applies for reasons.
>>
>>
>> The lister is a convenient way to create typed slice.
>>
>>
>> package demo
>>
>> // Tomate is about red vegetables to make famous italian food.
>> type Tomate struct {
>> Name string
>> }
>>
>> // GetID return the ID of the Tomate.
>> func (t Tomate) GetID() string {
>> return t.Name
>> }
>>
>> //go:generate lister vegetables_gen.go Tomate:Tomates
>> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>>
>> hth
>>
>>

-- 
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: All the Go project history, live in RAM

[mhhcbon]

looks awesome!

On Sunday, April 30, 2017 at 11:42:03 PM UTC+2, bradfitz wrote:
>
> Gophers,
>
> Want to analyze the Go project's Git, GitHub, and Gerrit history?
>
> Here a package to make it easy:
>
>  https://godoc.org/golang.org/x/build/maintner/godata
>
> See the example:
>
> 
> https://godoc.org/golang.org/x/build/maintner/godata#example-Get--NumComments
>
> If you run that, it'll download 350 MB (once) and then tell you there have 
> been 111228 GitHub comments on Go repos.
>
> Run it again a few seconds later and the number might increase.
>
> The data is generally under 1 second behind reality, thanks to the 
> webhook+incoming-SMTP server we run now at 
> https://pubsubhelper.golang.org/ to get updates from GitHub & Gerrit.
>
> gopherbot now uses this infrastructure. See 
> https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go 
> for some more examples.
>
> Thanks to Kevin Burke for all the help & code reviews.
>
> - Brad
>
>

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

[go-nuts] Re: Go on AIX

[Tony . Reix]

The first (alpha) version of Gcc Go for AIX 7.1 is available on 
BullFreeware:

  http://bullfreeware.com/affichage.php?id=3614 

It is an experimental version. That means that still several Go compiler 
and Go libgo tests are still failing and only 32 bit version has been 
built/tested in depth for now.
Gcc Go compiler tests : still 13 AIX-specific tests out of 7346 are still 
failing.
libgo test: about 17 failing tests out of 145

GCC v7 snapshot 20170323
Go v1.8

Failures deal with: , networking, linking issue with type, etc.
If you have a message like: "value of type string is not assignable to type 
string", showing that types are considered to be different though the same, 
try linking with: -static-libgo

However, this GCC Go compiler/runtime has been used for compiling/testing a 
real Go product, FileBeat, with success.

Feel free to experiment with it.

-- 
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] Strange Go runtime behavior related to xml.Unmarshal

[Nikos Anastopoulos]

Τη Κυριακή, 30 Απριλίου 2017 - 2:36:15 π.μ. UTC+3, ο χρήστης Ian Lance 
Taylor έγραψε:
>
> On Sat, Apr 29, 2017 at 3:09 AM, Nikos Anastopoulos  > wrote: 
> > Τη Σάββατο, 29 Απριλίου 2017 - 7:33:00 π.μ. UTC+3, ο χρήστης Nikos 
> > Anastopoulos έγραψε: 
> >> 
> >> Either through the /proc/PID/tasks entries, or using 
> >> GODEBUG=schedtrace=1000.I get consistent results with both ways 
> > 
> > 
> >  With some experimentation more I did, I tend to believe this behavior 
> has 
> > somehow to do with the number of CPUs of the platform; or to be more 
> > precise, to the number of CPUs made available to the Go app through the 
> CPU 
> > affinity mask. When reducing the available CPUs from 88 to 44, 22, 11, 
> and 
> > so on, the total number of threads after a 4-min run decreases as well, 
> as 
> > you can see from the detailed results below (look at the "threads" 
> field). 
> > So it is quite possible that if you try to reproduce the test on a 
> low-count 
> > CPU environment you won't see anything weird. 
>
> All else being equal, which it never is, the number of threads used by 
> Go will tend to level out at about GOMAXPROCS plus a bit.  If you have 
> 88 available CPUs, GOMAXPROCS will default to 88, and over time you 
> should expect to see your program using around 92 threads. 
>
> If you see the number of threads growing significantly beyond 
> GOMAXPROCS, without an obvious explanation like blocking C threads, 
> then there may be a problem. 
>
> Ian 
>

Thanks for your feedback.  As a last question, what is the application 
aspect (or other factors) that determines how quickly new threads are being 
employed over time? For example, in my scenario above, if I choose to do 
the parsing using plain regexp rather than xml.Unmarshal, the threads will 
reach a count of ~8 within the same period (4 mins), vs 28 when using 
xml.Unmarshal. In some other Go apps, threads will remain constant (i.e., 
4) forever. Where is this difference attributed?

-- 
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: Feedback welcome: "Shorten your URL"

[Val]

Actually, html/template is good for templating, with data formatting, etc.
For a static static file, consider  http.ServeFile 


On Tuesday, May 2, 2017 at 10:03:19 AM UTC+2, Lutz Horn wrote:
>
> Hi Val, 
>
> > I'll go with 2 remarks and leave other concerns to other reviewers : 
> > - using ioutil.ReadFile to serve some static html isn't the most 
> > idiomatic. 
> > Have a look at html/template . 
>
> I had a vague feeling that this should be easier :) Thanks, I'll take a 
> look at html/template. 
>
>

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

[go-nuts] Re: go get -u doesn't update dependencies

[Dave Cheney]

One cause can be an incorrect GOPATH setting (if the source is outside 
GOPATH, possibly due to symlinks)

On Tuesday, 2 May 2017 18:33:34 UTC+10, anatoly techtonik wrote:
>
> https://github.com/lxc/lxd/pull/3260 was an attempt to prevent breaking 
> builds due to a missing/updated dependency with `go get -u`. However, this 
> command didn't fetch it. Why? Why not to fix it?
>

-- 
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 -u doesn't update dependencies

[anatoly techtonik]

https://github.com/lxc/lxd/pull/3260 was an attempt to prevent breaking 
builds due to a missing/updated dependency with `go get -u`. However, this 
command didn't fetch it. Why? Why not to fix it?

-- 
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: Feedback welcome: "Shorten your URL"

[Lutz Horn]

Hi Val,


I'll go with 2 remarks and leave other concerns to other reviewers :
- using ioutil.ReadFile to serve some static html isn't the most 
idiomatic.

Have a look at html/template .


I had a vague feeling that this should be easier :) Thanks, I'll take a 
look at html/template.



- why write
func(handler *Handler) {
handler.Index(w, req)
}(handler)

instead of
handler.Index(w, req)   ?

Is there an expected benefit that I'm not seeing?


You are right, there is no benefit in wrapping this method call into an 
anonymous function. Changing the handler registration will be much 
shorter without it.


Thanks!

Lutz


--
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: Feedback welcome: "Shorten your URL"

[Val]

Hello Lutz
This code already looks nice, and running "go vet" doesn't even complain, 
great!

I'll go with 2 remarks and leave other concerns to other reviewers :
- using ioutil.ReadFile to serve some static html isn't the most idiomatic. 
Have a look at html/template .
- why write 
func(handler *Handler) {
handler.Index(w, req)
}(handler)

instead of
handler.Index(w, req)   ?

Is there an expected benefit that I'm not seeing?

I wish you a pleasant journey in go world.
Cheers
Val

On Tuesday, May 2, 2017 at 9:32:45 AM UTC+2, Lutz Horn wrote:
>
> Hi Go Nuts, 
>
> to practice my Go skills, I've implemented a simple web application that 
> allows you to shorten an URL. The application consists of a backend 
> written in Go and a web frontend using jQuery with some plugins and 
> Bootstrap for layout. 
>
> The code is available on GitHub at https://github.com/lutzhorn/shorturl, 
> the application is deployed on https://u.lhorn.de. 
>
> I would very much appreciate any feedback you can give especially on the 
> Go part. Coming from a Java and Python background, I'm trying to get 
> into the Go way of programming, In Python there is a 'Pythonic' way to 
> write code, I am sure there is something similar in Go: File structure, 
> name choice, exporting names, error handling, ... 
>
> If you have a little time, please tak a look at the code, play with the 
> deployed application, and please give me feedback. 
>
> Thanks! 
>
> Lutz 
>
>
>

-- 
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] "Selling" Go to Management

[Simon Ritchie]

I think interoperability is an important issue.  If you are trying to introduce 
Go into a mature environment you need to avoid any idea that the existing apps 
will have to be rewritten.

For example, gRPC allows a Go application to work with apps written in Java, 
C#, RoR, Python and a host of other languages, so it offers the potential to 
introduce new functionality written in Go and make it work with the stuff that 
you already have.

Another issue is testing.  Go has excellent ready-made testing facilities.  
However, not all managers understand how important testing is, so that point 
may be irrelevant to your purposes.

In general, when dealing with managers, talk about money - you need to argue 
that Go offers lower development costs, better software for the same money, 
more efficient use of equipment, and so on.  If you can't offer those benefits 
convincingly, they probably won't be interested.


-- 
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] Feedback welcome: "Shorten your URL"

[Lutz Horn]

Hi Go Nuts,

to practice my Go skills, I've implemented a simple web application that 
allows you to shorten an URL. The application consists of a backend 
written in Go and a web frontend using jQuery with some plugins and 
Bootstrap for layout.


The code is available on GitHub at https://github.com/lutzhorn/shorturl, 
the application is deployed on https://u.lhorn.de.


I would very much appreciate any feedback you can give especially on the 
Go part. Coming from a Java and Python background, I'm trying to get 
into the Go way of programming, In Python there is a 'Pythonic' way to 
write code, I am sure there is something similar in Go: File structure, 
name choice, exporting names, error handling, ...


If you have a little time, please tak a look at the code, play with the 
deployed application, and please give me feedback.


Thanks!

Lutz


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