kylebanks / goggles Goto Github PK

Hi Gogglers,

I tried to install the app on Mac OS but it fails. My terminal says:

$ go get github.com/KyleBanks/goggles/cmd/goggles
# github.com/KyleBanks/goggles/server/api
src/github.com/KyleBanks/goggles/server/api/pkg.go:17: undefined: sort.Slice

Could you help me?

From godoc.org

From goggles:

Note the different representations for the list of instructions.

godoc:

*ir.InstAdd
*ir.InstFAdd

goggles:

*ir.InstAdd *ir.InstFAdd

Currently the backend solution for errors is a graceful log.Fatal. Should return the error to the frontend for display to the user.

What I did:

$ # clone this repo and cd into it
$ git rev-parse HEAD
a5b8070a9a91e49496c33217192dfb445e3aaa9b
$ npm install gulp
$ go get -u github.com/alexflint/gallium
$ go install github.com/alexflint/gallium/cmd/gallium-bundle
$ make

This opens an "empty" web view which looks like a directory listing:

Currently it is not possible to resize or maximize the window.

Not having Windows and Linux support is a deal-breaker for me. I often see apps that only publish the binary that includes the assets in it (like https://github.com/sosedoff/pgweb ).. this allows it to run remotely (with a port-forward), locally and using your current browser..

Are we using any features of Gallium that make it interesting ? Otherwise, could we simply publish the binary + assets (with https://github.com/GeertJohan/go.rice or something) ?

thanks for goggles :) !

Currently the default display is the Gallium example menu, should create custom ones.

I can see some godeps files and other unrelated stuff like

• Godeps/_workspace/src/github.com/prometheus/client_golang/prometheus
• github.com/prometheus/prometheus_cli/.build/gopath/src/github.com/prometheus/common/expfmt
• .build/gopath/src/github.com/Sirupsen/logrus

The README suggests that you can download a stable release, but the page is blank (sadpanda)

Currently the backend renders JSON and Markdown while the frontend parses the JSON and Markdown into HTML. Bits and pieces are all over the place with no rhyme or reason.

It'd be cleaner to just have one side do everything, and it seems as though the backend doing it would be the simpler solution, considering it has access to all the go/ packages already for parsing. However, the frontend needs to be able to collapse sections, link around, add buttons, style, etc. It might have to be done all on the frontend, even if it's the more difficult solution.

I tried to use goggles today, and it does look great. However, upon doing so, it seems it encountered an error when trying to parse my $GOPATH, which is a list of GOPATH:s.

u@x220 ~> echo $GOPATH
/home/u/goget:/home/u/Desktop/go

When GOPATH is set to a list, goggles fails with the following error:

No packages found, does your $GOPATH look right?

Here are a couple of references that may be helpful for dealing with multiple $GOPATH:s.

https://golang.org/pkg/path/filepath/#SplitList
https://golang.org/pkg/go/build/#Context.SrcDirs

From mewkiz/pkg/goutil.SrcDir:

// SrcDir tries to locate dir in GOPATH/src/ or GOROOT/src/pkg/ and returns its
// full path. GOPATH may contain a list of paths.
func SrcDir(dir string) (absDir string, err error) {
	for _, srcDir := range build.Default.SrcDirs() {
		absDir = filepath.Join(srcDir, dir)
		finfo, err := os.Stat(absDir)
		if err == nil && finfo.IsDir() {
			return absDir, nil
		}
	}
	return "", errors.Errorf("unable to locate directory (%q) in GOPATH/src/ (%q) or GOROOT/src/pkg/ (%q)", dir, os.Getenv("GOPATH"), os.Getenv("GOROOT"))
}

Hi,

I did the following :

⇒  go get -u github.com/KyleBanks/goggles
package github.com/KyleBanks/goggles: no buildable Go source files in ~/go/src/github.com/KyleBanks/goggles

installed all the dependencies as per the docs on here ... then went to ~/go/src/github.com/KyleBanks/goggles and then ran

⇒  mmake
Makefile:54: github.com/KyleBanks/make/go/sanity: No such file or directory
make: *** No rule to make target `github.com/KyleBanks/make/go/sanity'.  Stop.

cheers
alex

If Goggles is started from the command line, could it also detect where Go is installed or take an argument "goroot" so that the stdlib godoc can also be shown? It would be nice to have all documentation available in a single app and not switch between Dash and Goggles for example.

Or perhaps the app could support its own config file something like ~/.config/goggles/... where the user could define defaults for GOROOT and GOPATH. Then the app could be started from anywhere, not just cmd line. Eventually the app could have its own Prefs GUI, but a simple file to start with would be fine.

This is likely because the app is not signed properly. I have no idea how that process really works, though.

Various experiments when searching other things reveals that it crashes when I select any of my private home-ai repos.

gopherize.me

https://github.com/KyleBanks/goggles/files/866685/goggles.txt

• when run directly from the .app
• works from command line

• Disable resizing
• Custom close button
• Refresh button
• Search bar on frame

If clicking through packages quickly, may get responses out of order. Ensure package details are related to the currently selected package.

though, how is it different from godoc ? godoc can host your $GOPATH locally.

Currently Goggles cannot detect the $GOPATH (or any environment variables) when launched via the .app, unless the user sets a global $GOPATH environment variable or uses launchctl. Having to request the user to set these up is a pain point.

Better would be to prompt the user for their $GOPATH if the default $HOME/go doesn't exist. The entered value could be stored locally in a config file, and used on subsequent launches.

The Travis badge could be triggered only when there is a .travis.yml file in the project directory

For example:

github.com/foo/bar

github.com/foo/baz/vendor/github.com/foo/bar

Here the second should always be ignored due to the /vendor/ path, however in this case only the /vendor/ version shows up in Goggles and the first path is ignored.

This issue may be difficult to reproduce, however I'll try to describe the observed behaviour of goggles.

The ir package of llir/llvm uses go generate to run the gen.go source file, to generating the source code of binary and bitwise instruction data representations.

When viewing the documentation for llir/llvm/ir the documentation of package ir is sometimes displayed, and sometimes, the documentation of package main is displayed.

Note, that gen.go contains a //+build ignore tag, which I think is what makes godoc skip this file when generating documentation. As a user of goggles, I would expect these kind of files to be ignored, so that the relevant documentation is displayed.

It may be worth taking a look at, and potentially using the go/build package which provides native support for handling build tags (along with support for dealing with multiple GOPATHs).

Any tips or fixes to make them look better?