[go-nuts] [ANN] astits: parse and demux MPEG Transport Streams (.ts) natively in GO

[Asticode]

Hey guys,

I'm happy to announce go-astits, a Golang library to parse and demux MPEG 
Transport Streams (.ts) natively: https://github.com/asticode/go-astits

It allows you to either retrieve raw packets or event better retrieve 
complex data spanning over multiple packets.

Let me know what you think!

Cheers

-- 
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] Puzzle: make a sync.Once fire more than once

[Daniel Skinner]

I'd note the following:
https://play.golang.org/p/U_lmt-go6M

Also, this can be simplified to the following:
https://play.golang.org/p/eFnM98yRLk

Such a puzzle should look something more like:
https://play.golang.org/p/8KD6INL9QP


On Sun, Nov 19, 2017 at 6:25 PM Carl Mastrangelo 
wrote:

> Hi gophers,
>
> I was playing around with a puzzle trying to break the sync package and
> found something cool.   Can you think of a definition for f that causes
> once.Do to execute the argument more than once?
>
>
> package main
>
> import (
> "sync"
> )
>
> func main() {
> var once sync.Once
> var f = // ...
>
> once.Do(f)
> }
>
>
> HIGHLIGHT BELOW FOR ANSWER
>
>
> package main
>
> import (
> "fmt"
> "sync"
> )
>
> func main() {
> var once sync.Once
> var f func()
> times := 9
> f = func() {
> if times == 0 {
> return
> }
> times--
> fmt.Println("Called")
> oldonce := once
> * = sync.Once{}
> once.Do(f)
> once = oldonce
>
> }
> once.Do(f)
> }
>
> HIGHLIGHT ABOVE FOR ANSWER
>
> --
> 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: Flagging lazy-loaded fields as being unsafe to access directly

[Nate Finch]

Just use a comment.  That's usually fine.  // this is lazy loaded, use 
getBar() instead of directly accessing.

"Don't do that" is a surprisingly feasible solution to a lot of programming 
problems.  Not everything has to be enforced by tooling.

On Sunday, November 19, 2017 at 9:08:47 PM UTC-5, Traun Leyden wrote:
>
>
> In this case I mean within the boundaries of a single package.
>
> I realize there is no way to enforce another package maintainer to call 
> the method wrapper rather than the field directly, but I was wondering if 
> people have come up with naming conventions such as a leading underscore to 
> make it apparent that certain fields shouldn't be accessed directly under 
> most circumstances.  
>
> On Friday, November 17, 2017 at 10:27:05 PM UTC-8, Nicholas Hanley wrote:
>>
>> In Go, lowercase identifiers are not visible outside the package in which 
>> they are defined (ref: Exported identifiers 
>> ). Your example 
>> declares foo in the main package but I assume your real code would be in 
>> its own package. What you can do is export Foo and GetBar, but leave the 
>> bar field unexported.
>>
>> Your code would look something like this:
>> main.go
>> package main
>>
>> import (
>> "fmt"
>>
>> "example.com/baz"
>> )
>>
>> func main() {
>> f := baz.Foo{}
>> fmt.Printf("f.bar lazy-loaded: %v\n", f.GetBar())
>> }
>>
>> example.com/baz/foo.go
>> package baz
>>
>> type Foo struct {
>> bar string
>> }
>>
>> // Method wrapper that does lazy-loading
>> func (f *Foo) GetBar() string {
>> if f.bar == "" {
>> // lazy-load this from a database or some other expensive call
>> f.bar = "bar"
>> }
>> return f.bar
>> }
>>
>>
>> On Friday, November 17, 2017 at 4:00:27 PM UTC-5, Traun Leyden wrote:
>>>
>>>
>>>
>>> I'm trying to figure out a way to best signal to other developers 
>>> maintaining a single package that a field is unsafe to access directly.  In 
>>> this case, it's being lazily loaded, and the only way to ensure it will be 
>>> properly loaded is to access the method wrapper rather than directly 
>>> accessing the field.
>>>
>>> For example, see this code :
>>>
>>> type foo struct {
>>>bar string
>>> }
>>>
>>> // Method wrapper that does lazy-loading
>>> func (f *foo) getBar() string {
>>> if f.bar == "" {
>>> // lazy-load this from a database or some other expensive call
>>> f.bar = "bar"
>>> }
>>> return f.bar
>>> }
>>>
>>> func main() {
>>> f := foo{}
>>> fmt.Printf("f.bar directly: %v\n", f.bar) 
>>> fmt.Printf("f.bar lazy-loaded: %v\n", f.getBar()) 
>>> }
>>>
>>>
>>> If you access the field directly, you get an empty value.  If you call 
>>> the method wrapper, you get the intended value.
>>>
>>> I believe the official answer is just "do the right thing" since you are 
>>> within the package boundaries and have full control.  And I'm pretty sure 
>>> the language doesn't provide anything here.  
>>>
>>> But what I'm wondering -- are there any common conventions or 
>>> workarounds to avoid this pitfall?  So far the only idea I've been able to 
>>> come up with is to use underscores and/or comments to clearly mark the 
>>> field as being unsafe to access directly:
>>>
>>> type foo struct {
>>>*_bar* string  *// You probably want to use getBar() since this is 
>>> lazily loaded an unsafe to access directly.*
>>> }
>>>
>>>
>>>
>>>

-- 
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] My trouble of local package referencing

[Ally Dale]

Thanks for replying all above.
The main point of this topic is probably to discuss "what's the right way 
to manage local-only packages".
1. Axel has point out that "why local-packages is not necessary in golang"
2. Jake has given an effective way to use "vendor" path to fix 
local-refering problem.
But this is with a liitle defective that it's depart from vendor's original 
goal--manage explicit-version of third-party packages.
3. Goalng has a local package refer solution with "./xxx" "../xxx" style. 
But this is not recommeded by go team.
a)It may cause out-of-control problems(“../.../xxx” maybe refer to a path 
out of my project).
b)It doesn't work when working path is under GoPath(error: local import 
"./local2" in non-local package) .
c)local and global package reference style cannot working well together.
4. "#/xxx" style reference seems a best solution like "vendor" to fix 
local-package reference problem.
Without any hard code "where I am" exists in any go files.
And it will works well together with current global-style, because "#" will 
be replaced with  by compiler automatically. 

在 2017年11月18日星期六 UTC+8下午7:19:33，Ally Dale写道：
>
>
> We must explicit followed priorty of go package find process:
> : with highest-priorty path to find local packages.
>  : with second-priorty path to find explicit-version of 
> local-referenced third-party packages.
>  : with third-priorty path to find standard packages.
>  : with lowest-priorty path to find third-party packages.
>
>
>
>>

-- 
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: Flagging lazy-loaded fields as being unsafe to access directly

[Traun Leyden]

In this case I mean within the boundaries of a single package.

I realize there is no way to enforce another package maintainer to call the 
method wrapper rather than the field directly, but I was wondering if 
people have come up with naming conventions such as a leading underscore to 
make it apparent that certain fields shouldn't be accessed directly under 
most circumstances.  

On Friday, November 17, 2017 at 10:27:05 PM UTC-8, Nicholas Hanley wrote:
>
> In Go, lowercase identifiers are not visible outside the package in which 
> they are defined (ref: Exported identifiers 
> ). Your example 
> declares foo in the main package but I assume your real code would be in 
> its own package. What you can do is export Foo and GetBar, but leave the 
> bar field unexported.
>
> Your code would look something like this:
> main.go
> package main
>
> import (
> "fmt"
>
> "example.com/baz"
> )
>
> func main() {
> f := baz.Foo{}
> fmt.Printf("f.bar lazy-loaded: %v\n", f.GetBar())
> }
>
> example.com/baz/foo.go
> package baz
>
> type Foo struct {
> bar string
> }
>
> // Method wrapper that does lazy-loading
> func (f *Foo) GetBar() string {
> if f.bar == "" {
> // lazy-load this from a database or some other expensive call
> f.bar = "bar"
> }
> return f.bar
> }
>
>
> On Friday, November 17, 2017 at 4:00:27 PM UTC-5, Traun Leyden wrote:
>>
>>
>>
>> I'm trying to figure out a way to best signal to other developers 
>> maintaining a single package that a field is unsafe to access directly.  In 
>> this case, it's being lazily loaded, and the only way to ensure it will be 
>> properly loaded is to access the method wrapper rather than directly 
>> accessing the field.
>>
>> For example, see this code :
>>
>> type foo struct {
>>bar string
>> }
>>
>> // Method wrapper that does lazy-loading
>> func (f *foo) getBar() string {
>> if f.bar == "" {
>> // lazy-load this from a database or some other expensive call
>> f.bar = "bar"
>> }
>> return f.bar
>> }
>>
>> func main() {
>> f := foo{}
>> fmt.Printf("f.bar directly: %v\n", f.bar) 
>> fmt.Printf("f.bar lazy-loaded: %v\n", f.getBar()) 
>> }
>>
>>
>> If you access the field directly, you get an empty value.  If you call 
>> the method wrapper, you get the intended value.
>>
>> I believe the official answer is just "do the right thing" since you are 
>> within the package boundaries and have full control.  And I'm pretty sure 
>> the language doesn't provide anything here.  
>>
>> But what I'm wondering -- are there any common conventions or workarounds 
>> to avoid this pitfall?  So far the only idea I've been able to come up with 
>> is to use underscores and/or comments to clearly mark the field as being 
>> unsafe to access directly:
>>
>> type foo struct {
>>*_bar* string  *// You probably want to use getBar() since this is 
>> lazily loaded an unsafe to access directly.*
>> }
>>
>>
>>
>>

-- 
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: Puzzle: make a sync.Once fire more than once

[Chris G]

I've been tempted to reset the sync.Once inside the function, but I believe 
there's a subtle bug -- I'd be very interested to know if my understanding 
is incorrect.

When Do() is called for the first time, it can aquire a mutex, and defers 
the unlocking until after the supplied function has completed.  If you 
reset the state of the Once inside the supplied function, the mutex state 
gets reset as well -- meaning that the defer would unlock a mutex that 
hadn't ever been locked.

Calling the Do() *again* with in the supplied function is...asking for more 
problems, and starts getting a bit harder to reason about than I care to 
try on a sunday evening.

It'd be much better to use something 
like https://godoc.org/golang.org/x/sync/singleflight  to deduplicate calls 
-- or have a secondary mutex that gets aquired to occasionally reset the 
once.

On Sunday, November 19, 2017 at 4:24:41 PM UTC-8, Carl Mastrangelo wrote:
>
> Hi gophers,
>
> I was playing around with a puzzle trying to break the sync package and 
> found something cool.   Can you think of a definition for f that causes 
> once.Do to execute the argument more than once?
>
>
> package main
>
> import (
> "sync"
> )
>
> func main() {
> var once sync.Once
> var f = // ...
>
> once.Do(f)
> }
>
>
> HIGHLIGHT BELOW FOR ANSWER
>
>
> package main
>
> import (
> "fmt"
> "sync"
> )
>
> func main() {
> var once sync.Once
> var f func()
> times := 9
> f = func() {
> if times == 0 {
> return
> }
> times--
> fmt.Println("Called")
> oldonce := once
> * = sync.Once{}
> once.Do(f)
> once = oldonce
>
> }
> once.Do(f)
> }
>
> HIGHLIGHT ABOVE FOR ANSWER
>

-- 
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: Easy access to #golang

[Kevin Powick]

On Friday, 17 November 2017 10:47:44 UTC-5, Sam Whited wrote:
>
> Hi all, 
>
> I don't like signing up for accounts, or having to jump through hoops 
> (even if they're relatively straight forward hoops) to get an invite to 
> something that should just be public. Also, some people seem to like web 
> clients, so here's a quick and easy way to access the #golang channel on 
> Freenode: 
>
> https://gopher.chat/ 
>
> I hope you find it useful. 
>
>
Doesn't seem to bypass the invite requirement.

[17:28] == xx was kicked from #golang by ChanServ [Invite only channel] 


-- 
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] Puzzle: make a sync.Once fire more than once

[Carl Mastrangelo]

Hi gophers,

I was playing around with a puzzle trying to break the sync package and 
found something cool.   Can you think of a definition for f that causes 
once.Do to execute the argument more than once?


package main

import (
"sync"
)

func main() {
var once sync.Once
var f = // ...

once.Do(f)
}


HIGHLIGHT BELOW FOR ANSWER


package main

import (
"fmt"
"sync"
)

func main() {
var once sync.Once
var f func()
times := 9
f = func() {
if times == 0 {
return
}
times--
fmt.Println("Called")
oldonce := once
* = sync.Once{}
once.Do(f)
once = oldonce

}
once.Do(f)
}

HIGHLIGHT ABOVE FOR ANSWER

-- 
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: Parsing OpenSSH ed25519 private keys

[Nurahmadie Nurahmadie]

Correct, apologies I think I'm half asleep when I replied before. Please
ignore my reply before.

On Mon, Nov 20, 2017 at 12:16 AM, Anmol Sethi  wrote:

> That library will not work either.
>
> See https://github.com/fudanchii/edssh/blob/bd7d88fd1d85351bf598cdcd1fb7b0
> 4528cf42e2/keys.go#L44
>
>
> On Nov 19, 2017, at 11:49 AM, Nurahmadie Nurahmadie 
> wrote:
>
> Hi Chandru,
>
> I made a library to support openssh ed25519 key format.
> It can be used as a drop-in replacement of `ssh.ParsePrivateKey` as shown
> here: https://github.com/fudanchii/edssh
>
> On Thu, Nov 16, 2017 at 11:43 PM, me via golang-nuts  googlegroups.com> wrote:
>
>> x/crypto/ssh does support OpenSSH's ed25519 private key files.
>>
>> However, it looks like it does not support encrypted private keys in the
>> OpenSSH format.
>>
>> See https://github.com/golang/crypto/blob/9f005a07e0d31d45e6
>> 656d241bb5c0f2efd4bc94/ssh/keys.go#L922 and https://
>> github.com/openssh/openssh-portable/blob/master/PROTOCOL.key
>>
>> On Wednesday, November 15, 2017 at 12:09:29 PM UTC-5, Chandra Sekar S
>> wrote:
>>>
>>> Can x/crypto/ssh parse OpenSSH's ed25519 private key files?
>>>
>>> ParseRawPrivateKeyWithPassphrase returns "ssh: cannot decode encrypted
>>> private keys" as error.
>>>
>>> --
>>> Chandra Sekar.S
>>>
>>
>> --
>> 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.
>>
>
>
>
> --
> regards,
> Nurahmadie
> --
>
>
>


-- 
regards,
Nurahmadie
--

-- 
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: Parsing OpenSSH ed25519 private keys

['Anmol Sethi' via golang-nuts]

That library will not work either.

See 
https://github.com/fudanchii/edssh/blob/bd7d88fd1d85351bf598cdcd1fb7b04528cf42e2/keys.go#L44

> On Nov 19, 2017, at 11:49 AM, Nurahmadie Nurahmadie  
> wrote:
> 
> Hi Chandru,
> 
> I made a library to support openssh ed25519 key format.
> It can be used as a drop-in replacement of `ssh.ParsePrivateKey` as shown 
> here: https://github.com/fudanchii/edssh 
> 
> On Thu, Nov 16, 2017 at 11:43 PM, me via golang-nuts 
> > wrote:
> x/crypto/ssh does support OpenSSH's ed25519 private key files.
> 
> However, it looks like it does not support encrypted private keys in the 
> OpenSSH format.
> 
> See 
> https://github.com/golang/crypto/blob/9f005a07e0d31d45e6656d241bb5c0f2efd4bc94/ssh/keys.go#L922
>  
> 
>  and https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.key 
> 
> 
> On Wednesday, November 15, 2017 at 12:09:29 PM UTC-5, Chandra Sekar S wrote:
> Can x/crypto/ssh parse OpenSSH's ed25519 private key files?
> 
> ParseRawPrivateKeyWithPassphrase returns "ssh: cannot decode encrypted 
> private keys" as error.
> 
> --
> Chandra Sekar.S
> 
> -- 
> 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 
> .
> 
> 
> 
> -- 
> regards,
> Nurahmadie
> --

-- 
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: Parsing OpenSSH ed25519 private keys

[Nurahmadie Nurahmadie]

Hi Chandru,

I made a library to support openssh ed25519 key format.
It can be used as a drop-in replacement of `ssh.ParsePrivateKey` as shown
here: https://github.com/fudanchii/edssh

On Thu, Nov 16, 2017 at 11:43 PM, me via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> x/crypto/ssh does support OpenSSH's ed25519 private key files.
>
> However, it looks like it does not support encrypted private keys in the
> OpenSSH format.
>
> See https://github.com/golang/crypto/blob/9f005a07e0d31d45e6656d241bb5c0
> f2efd4bc94/ssh/keys.go#L922 and https://github.com/openssh/
> openssh-portable/blob/master/PROTOCOL.key
>
> On Wednesday, November 15, 2017 at 12:09:29 PM UTC-5, Chandra Sekar S
> wrote:
>>
>> Can x/crypto/ssh parse OpenSSH's ed25519 private key files?
>>
>> ParseRawPrivateKeyWithPassphrase returns "ssh: cannot decode encrypted
>> private keys" as error.
>>
>> --
>> Chandra Sekar.S
>>
> --
> 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.
>



-- 
regards,
Nurahmadie
--

-- 
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] running 'dep init -gopath' on new project: what don't I get?

[ossbsd]

dep faq says:
How do I make dep resolve dependencies from my GOPATH?
  dep init provides an option to scan the GOPATH for
  dependencies by doing dep init -gopath, 

Assuming these files exist

$GOPATH/src/foo.com/lib/hello/hello.go
$GOPATH/src/bar.com/prg/doit/main.go

when I do the following

$ dep version
dep:
  version : devel
  build date :
  git hash :
  go version : go1.9
  go compiler : gc
  platform : freebsd/amd64
$ cd $GOPATH/src/bar.com/prg/doit/
$ ls -F
main.go
$ cat main.go
import (
"foo.com/lib/hello"
"github.com/urfave/cli"
) 
...
$ go build
$ ls -F
doit* main.go
$ ./doit 
hello, world
$ dep init -gopath -v
Getting direct dependencies...
unable to deduce repository and source type for "foo.com/lib/hello": 
unable to read metadata: unable to fetch raw metadata: failed HTTP request 
to 
URL "http://foo.com/lib/hello?go-get=1": Get 
http://foo.com/lib/hello?go-get=1: 
dial tcp: lookup foo.com: no such host
$ ls -F
doit* main.go

I don't get what I expect, ie no vendor folder, and inability to resolve a 
local path import by dep.

I saw somewhere there is a desire to avoid $GOPATH local
dependencies, but what then is the -gopath switch use case?

Now, before I start an exhaustive study of dep source, is there
a simple abstraction I'm not getting?  All I want is to vendor
local company libs that for development, security, or
purely cantankerous reasons live locally.

I know I can manually copy dependencies into vendor/ so 'go build'
is happy, but then 'dep ensure' is sad.  I know I can set up a local
http / git server that speaks of routes and params, Daniel J.
Bernstein and I can split horizon foo.com, but before any of that, is
there a simple way to vendor local files, a Gopkg.toml incantation that
automagically allows a local dir (assuming git subdir/files are present in
the expected places) to be vendored and tracked?  If not, how best to do? 
And indeed if I'm on the wrong path entirely, on the way to perdition, Oh 
please kind soul, point me at the light (or RTFM I missed)


-- 
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 vet doesn't complain about overgeneralized panic

[as]

Shouldn't vet complain about this? I see this type of thing mostly in 
closed-source code

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

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