[go-nuts] Re: golang.org/x/tools/go/loader: file names of parsed *ast.File

[Paul Jolly]

On Saturday, 13 August 2016 21:58:37 UTC+1, Paul Jolly wrote:
>
> Am I missing something obvious here?
>

Please excuse the reply to self, but I have discovered what I was missing.

For the sake of completeness, here is how the equivalent mapping is 
achieved in golang.org/x/tools/go/loader world:

import (
"go/ast"
"go/parser"
"golang.org/x/tools/go/loader"
)


conf := loader.Config{
ParserMode: parser.AllErrors | parser.ParseComments,
Cwd:path,
}

...

conf.CreateFromFilenames(path, toParse...)

prog, err := conf.Load()
if err != nil {
panic(err)
}

At this point conf.CreatePkgs (type []loader.PkgSpec) and prog.Created 
(type []*loader.PackageInfo) correspond to each other.

For each (loader.PkgSpec, *loader.PackageInfo) pairing, say pkgSpec and 
pkgInfo, then pkgSpec.Filenames (type []string) and pkgInfo (type 
[]*ast.File) again correspond, which gives us the required mapping.

-- 
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: Who wants to use Go to process your camera's raw files?

['Paul' via golang-nuts]

On Saturday, August 13, 2016 at 8:06:44 PM UTC+2, Klaus Post wrote:
>
> On Saturday, 13 August 2016 17:18:16 UTC+2, Paul wrote:
>>
>> From what I gather even Adobe uses [dcraw]. 
>>
>
> I am pretty sure it is the other way around. Observing for years, it seems 
> like dc is reverse engineering the Adobe DNG Converter. His color 
> conversion matrices are definitely from that, and his support mostly 
> follows a DNG converter release.
>

I could'nt remember where I read it, but it actually says so in the adobe 
forum Quote: 
"ACR contains some stuff from dcraw, and dcraw contains some stuff from 
ACR." 

>
> It should be possible to reference his code base in C and rewrite it in 
>> Go,  I think.
>>
>
> Have you read dcraw.c? I have spent hours "reverse-engineering" what his 
> code does. It is a spagetti of jumps, hoops, global variables, secret 
> values, weird dependencies, etc.
>
> /Klaus
>

Well apart from the 'code quality', his code does seem to be of interest to 
quite a few software developers in the graphics business,  including 
yourself as you write.  Adobe would have their own special reasons for 
using some of his stuff.  

I was not even aware of Rawspeed. I do use Darktable, however there is 
quite some discussion going on as to the quality of the images that 
opensource raw converters produce. Adobe seems to still be king of that 
hill. Or poprietary Converters such as Capture Nx2 which very unfortunately 
has been discontinued. 

   

-- 
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] keyed vs unkeyed fields

[Ian Lance Taylor]

On Sat, Aug 13, 2016 at 12:06 AM, Anmol Sethi  wrote:
> Thing is, since keyed fields are almost always better, why were unkeyed 
> fields even allowed for struct literals? I see what you mean in your example, 
> but I think it would be simpler to only have unkeyed fields.
>
> Was it a mistake or is there a even better reason?

I think this is a case where consistency is valuable.

And for something like
struct Point { x, y int }
there is no real confusion to writing
Point{1, 2}
Why make people always write
Point(x: 1, y: 2}
?

Also consider that there are useful structs with a single field, in
order to implement some interface without allowing people to casually
change the value.  It would be a pain to force people to always state
the field when writing a composite literal.  And it would be a pain to
have a special exception for a single field.

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: go mobile : keyboard input, camera

[danilolr]

About the camera I think you best hope is use NDK (c++ bindings to android 
functions).
But you are out of luck as most of the links I search do not provide a 
solution.
The best answer I find is this :

http://stackoverflow.com/questions/30328276/access-android-camera-with-ndk

Not tested, but I did a quick search because I will need this on the future.

Maybe to make it work without hacks you can make you app a android/iOS 
native application and call the go code as a SDK app. This way you can have 
all the calls on java/swift/objective-c.

sexta-feira, 12 de Agosto de 2016 às 02:00:23 UTC-3, zzz...@gmail.com 
escreveu:
>
> Hi,
>
>   I have looked the go mobile docs / examples (the most advanced being 
> 'flappy gopher'), but I can not find code/API for either of the following:
>
>   1) accessing the camera (i.e. taking a picture)
>   2) keyboard input (is the current best to draw a bunch of squares with 
> letters in them in OpenGL and manually track the touch events?)
>
> 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] Small complete examples which show the power of Go?

[as . utf8]

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

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

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

[go-nuts] Re: Who wants to use Go to process your camera's raw files?

['Paul' via golang-nuts]

I don't know what the true story actually is, however some camera hardware 
makers such as Nikon are giving software developers a tough time by 
intentionally obfuscating their metadata. A lot of folks had big problems 
with that including adobe. I just mentioned "reverse engineering" to 
indicate a potential for far bigger mess. Enough said. 

I was not aware of Rawspeed. I do not have any personal preferences, all I 
was saying is that a lot of hard work has already been done and it would be 
reasonable to try and leverage it.  Go language would be good,  I think, 
because a lot of programmers that would like to help out in opensource 
image processing drop out when they discover C++ is just to hard. They try 
for a while and then they just give up. Maybe Go language has the potential 
to bring some change to that problem.   
 

On Wednesday, July 27, 2016 at 4:36:31 AM UTC+2, Jonathan Pittman wrote:
>
> Well me too!  I am looking to see what level of interest there is in the 
> Go community to see this happen.  I am also looking for people who are 
> interested in working on this.
>
> Figuring out how to handle this problem for one specific camera's raw 
> files is not too difficult.  Figuring out how to do this to handle the 
> majority of cases requires a bit more work.
>
> To be clear, I am wanting a pure Go solution that is better thought out, 
> better laid out, and better to use than the existing C/C++ options.
>

-- 
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: Who wants to use Go to process your camera's raw files?

[Klaus Post]

On Saturday, 13 August 2016 17:22:29 UTC+2, Peter Herth wrote:
>
> Having a parallel version of the raw converter could yield conversion 
> times far faster then the original C. And it would be a neat Go library to 
> have. 
>

For the biggest part, I would not expect you to be able to beat C code, for 
that there is too much pointer arithmetic going on. The forced bounds 
checks will probably eat around 20% of your speed. The Go 1.7 SSA compiler 
will however help bringing us to the 20% overhead.

In terms of multithreading - only a few formats can be decoded 
multithreaded. Most formats are some sort of LJPEG, where every pixel 
depends on previous data - forcing you to do single threaded decoding. DNG 
being the only "big" exception. 

For uncompressed formats, you are just moving bits, so multithreading gives 
you little advantage. RawSpeed has multithreaded decoding of images where 
it is possible.

/Klaus

-- 
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: Who wants to use Go to process your camera's raw files?

[Klaus Post]

On Saturday, 13 August 2016 17:18:16 UTC+2, Paul wrote:
>
> From what I gather even Adobe uses [dcraw]. 
>

I am pretty sure it is the other way around. Observing for years, it seems 
like dc is reverse engineering the Adobe DNG Converter. His color 
conversion matrices are definitely from that, and his support mostly 
follows a DNG converter release.

It should be possible to reference his code base in C and rewrite it in 
> Go,  I think.
>

Have you read dcraw.c? I have spent hours "reverse-engineering" what his 
code does. It is a spagetti of jumps, hoops, global variables, secret 
values, weird dependencies, etc.

/Klaus

-- 
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: Who wants to use Go to process your camera's raw files?

[Klaus Post]

On Wednesday, 27 July 2016 04:36:31 UTC+2, Jonathan Pittman wrote:
>
> Well me too!  I am looking to see what level of interest there is in the 
> Go community to see this happen.  I am also looking for people who are 
> interested in working on this.
>

(a bit late to the party)

I am the author of RawSpeed - https://github.com/klauspost/rawspeed - which 
is a RAW decoding library which currently supports >700 cameras. It decodes 
to CFA-level images, so processing is still required to make the image 
"viewable". It is used by "Darktable" as well as other open source 
projects. It has even been stolen (oh sorry - converted) by raw.pics.io for 
their browser based decoding.

In my own humble opinion the code quality is way above dcraw, and I and 
other people have spent a lot of time trying to work out what goes on under 
the hood. Metadata is in a readable separate XML file (yes, this was 
designed in 2008), and not scattered around a single CPP file. Furthermore 
it is LGPL v2, but with a rewrite to Go, it should probably be MIT or 
similar. 

The code should translate rather well to Go - there is no big problems with 
it. Finding a decoder, parsing file structure and decoding images are 
nicely separated. Only the "RawImageData" seems to have accumulated a lot 
of fields and methods over time. It is rather sparsely commented, but I 
think the code should be pretty clear for a Gopher.

There are some design decision made that makes it faster by design. It 
decodes from raw memory and not a stream which makes it much faster to 
"jump around" without having to seek in the input stream. It decodes to 
unpadded memory which makes it use less memory and generally faster. 
Decoders have been heavily optimized for speed, while always maintaining 
full quality.

I have considered converting it to Go almost since I started programming, 
but since the demand for it is probably pretty small and I don't have a few 
months to spend on it, I have not done so. I am willing to help out the 
extent my knowledge

/Klaus

>

-- 
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: Who wants to use Go to process your camera's raw files?

[Peter Herth]

Dcraw seems to be only partially gpl - otherwise Adobe couldn't use it in
its products. Having a parallel version of the raw converter could yield
conversion times far faster then the original C. And it would be a neat Go
library to have.

Peter

On Sat, Aug 13, 2016 at 5:18 PM, 'Paul' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> DCRAW pretty much does it all. Its straight C under GPLv2.  Dave Coffin
> reverse engineered a lot of stuff to get it to work. It would be a sizable
> duplication of effort to try to do all that again.  From what I gather even
> Adobe uses his stuff. It should be possible to reference his code base in C
> and rewrite it in Go,  I think. The question would be, what is the point?
> Its probably already fast as hell and it likely will not need a garbage
> collector. Whatever...
>
> On Wednesday, July 27, 2016 at 4:36:31 AM UTC+2, Jonathan Pittman wrote:
>>
>> Well me too!  I am looking to see what level of interest there is in the
>> Go community to see this happen.  I am also looking for people who are
>> interested in working on this.
>>
>> Figuring out how to handle this problem for one specific camera's raw
>> files is not too difficult.  Figuring out how to do this to handle the
>> majority of cases requires a bit more work.
>>
>> To be clear, I am wanting a pure Go solution that is better thought out,
>> better laid out, and better to use than the existing C/C++ options.
>>
> --
> 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] context race

[Dave Cheney]

Receiving from a closed channel immediately returns the channel types zero 
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] context race

[upadhyay]

Say I have:

func DoSomething(ctx context.Context) {
for {
 select {
 case <- ctx.Done():
 return
 case <- time.After(time.Second)
 // do something
 }
}
}

Based on the documentation of context: 

Successive calls to Done return the same value.


So for each context there is only one channel, which is returned to every 
caller. 

Now given receiving on a closed channel never returns, above is not safe. I 
can check inside my second case if ctx.Err() is non nil, but its not a very 
clean solution. 

What would be safe way to use context.Done()? Or am I not understanding 
something right?

-- 
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] what is the meaning of ENV GOEXE

[Andy Xie]

​thanks. Just run `go env` and see it and is curious about it.


===
Ning Xie


2016-08-13 20:01 GMT+08:00 Anmol Sethi :

> I looked in the Go source code. You can’t actually set it as a environment
> variable. It’s the value of the executable suffix. It’s set automatically
> in build.go. Like if running on windows, it is '.exe’ or for c-archives it
> is ‘.a’.
>
> I don’t think it matters for an end user.
>
> > On Aug 13, 2016, at 7:51 AM, andyxning  wrote:
> >
> > when run `go env`, i get the following output:
> >
> > ```
> > GOARCH="amd64"
> > GOBIN=""
> > GOEXE=""
> > GOHOSTARCH="amd64"
> > GOHOSTOS="darwin"
> > GOOS="darwin"
> > GOPATH="/Users/andy/Github/go"
> > GORACE=""
> > GOROOT="/usr/local/go"
> > GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> > GO15VENDOREXPERIMENT="1"
> > CC="clang"
> > GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics
> -Qunused-arguments -fmessage-length=0 -fno-common"
> > CXX="clang++"
> > CGO_ENABLED="1"
> > ```
> >
> > what makes me confused is the GOEXE env, i googled it but found nothing.
> >
> > --
> > 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] xDT encoder / decoder

[Joe Blue]

There is a full implementation in js, so there is a starting point.

I can also provide test data of course.

https://www.npmjs.com/package/xdt

-- 
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] what is the meaning of ENV GOEXE

[Anmol Sethi]

I looked in the Go source code. You can’t actually set it as a environment 
variable. It’s the value of the executable suffix. It’s set automatically in 
build.go. Like if running on windows, it is '.exe’ or for c-archives it is ‘.a’.

I don’t think it matters for an end user.

> On Aug 13, 2016, at 7:51 AM, andyxning  wrote:
> 
> when run `go env`, i get the following output:
> 
> ```
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/Users/andy/Github/go"
> GORACE=""
> GOROOT="/usr/local/go"
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> GO15VENDOREXPERIMENT="1"
> CC="clang"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 -fno-common"
> CXX="clang++"
> CGO_ENABLED="1"
> ```
> 
> what makes me confused is the GOEXE env, i googled it but found nothing.
> 
> -- 
> 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] what is the meaning of ENV GOEXE

[andyxning]

when run `go env`, i get the following output:

```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/andy/Github/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
```

what makes me confused is the GOEXE env, i googled it but found nothing.

-- 
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] Invoking Golang executable on Mac OS X

[Justin Israel]

Maybe wrap it with Automator into an app?

On Sat, 13 Aug 2016, 5:52 AM  wrote:

> Maybe this is more OS related than Go, since Go just produces a static
> executable, so please feel free to lock this.
>
> I've built a simple tool, it works just fine in the terminal, both as a
> local executable and when put in the PATH. But when I want to register it
> as the default app for a given file type (to be run from Finder by double
> clicking a file of said file type), I'm not allowed to select it. Is this
> got to do with the Gatekeeper functionality? Or do I need to build a
> wrapper that has all the plists and other Mac specific things? If so, is
> there a Go way to wrap it (and still pass os.Args)?
>
> 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] keyed vs unkeyed fields

[Anmol Sethi]

Thing is, since keyed fields are almost always better, why were unkeyed fields 
even allowed for struct literals? I see what you mean in your example, but I 
think it would be simpler to only have unkeyed fields.

Was it a mistake or is there a even better reason?

> On Aug 12, 2016, at 10:12 PM, Nate Finch  wrote:
> 
> Unkeyed can be good to remind future you that you've changed the signature of 
> a struct and are now not populating all the fields.  That cuts both ways, 
> since it means you *have* to go to every place you've created a value of that 
> struct and update it with a new value... but it also means that if you don't 
> have a good default for that new field, that you won't miss places it's used.

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