golang / gddo Goto Github PK

Went here:

http://go.pkgdoc.org/-/about]

Click on Index: http://go.pkgdoc.org/-/index

got this :

Session Timeout

With this as URL
http://216.49.178.206:15871/cgi-bin/blockpage.cgi?ws-session=2470001744

When I point to

http://gopkgdoc.appspot.com/pkg/github.com/jbrukh/goneuro

I get a 404, but http://github.com/jbrukh/goneuro exists.

Thanks,
Jake.

For my crypto package https://github.com/dgryski/dkeyczar the constants for the KeyczarEncoding and KeyczarCompression types are missing. They are visible in the normal godoc, but not on the gopkgdoc version.

http://gopkgdoc.appspot.com/pkg/github.com/dgryski/dkeyczar

and

https://github.com/dgryski/dkeyczar/blob/master/keyczar.go#L28
https://github.com/dgryski/dkeyczar/blob/master/keyczar.go#L35

When viewing package documentation locally with godoc -http=":6060", functions named by the pattern ExampleType_Method are correctly attributed to the appropriate method and show the example as Type.Method in the list of examples in the index.

Godoc.org currently associates examples named by this pattern with the Type and lists them all with name of Type in the index. This is confusing since the list of examples just shows the Type repeated multiple times and the examples aren't associated with the method they are demonstrating.

A live example is at http://godoc.org/github.com/davecgh/go-spew/spew#_index. Notice the repeated ConfigState under examples instead of the expected ConfigState, ConfigState.Dump, and ConfigState.Printf. Also notice how all three examples are associated with the ConfigState instead of the appropriate method.

One of the function definitions the causes this issue can be seen at https://github.com/davecgh/go-spew/blob/master/spew/example_test.go#L194

gopkgdoc doesn't seem to support the "go-import" meta tag.

As an example, try bumbleserver.org/client or bumbleserver.org/router or bumbleserver.org/common. It works when using "go get" to install it.

Along with the 2nd form being the valid representation with the current weekly, and with the future Go 1, the bookmarklet doesn't work when browsing a googlecode project.

Perhaps allow either, for now?

Fantastic project, by the way!

What's your opinion on people linking to your site as their own project's documentation?

Example: https://github.com/fluffle/goirc

By chance I checked this link: http://gopkgdoc.appspot.com/pkg/github.com/cznic/golex which is found here: https://github.com/cznic/golex (down the page in the README).

I'm not completely sure but I think I remember the link used to work sometime in the past. Are commands, in addition to packages, also supported by pkgdocsrv in analogy to godoc (by the magic package documentation in a magic doc.go file)?

If the answer is yes then there is a bug somewhere probably.

If it is not supported then may I wish it be supported, if possible?

This is only a wish. I would like to suggest that the styles of the generated documentation would be the same as they are when generated by local godoc.

If you look at larger packages (like mgo), it's quite cumbersome to get back to the top (or the index).
I'd like to have a fixed-positioned bar to jump back to the top or maybe even the index, as some packages have a rather long intro documentation.

On a related note: Giving the index the id index is likely to clash (again, see the mgo package which defines a index type itself). Something else like gopkg-index might be helpful.

Ensure that package synopsis column on /-/index does not extend past the edge of the page by breaking up long words.

So i had an idea to make pkgdoc into a sort of go get proxy and a terminal based package manager client similar to pacman on arch linux.

This leads to a list of things im personally looking into implementing.

We need to provide a pkgdoc semantic for tags in the documentation for a search query that can also be used to provide an efficient way to sort libraries into a categorical fashion.

That way we dont get lost in a sea of packages.

I suggest to support this by adding a semantic like this. .

//This is a golang wrapper for redis
// ect ect ect..
package Redis
//[TAGS: redis, datastore, wrapper]

If the TAGS semantic isnt provided in doc.go then we can just have it added to the unsorted section. Also we could define a default list of categories that will match with certain tags, for instance datastore would be a good example of a genre of code that would provide better organization of package when navigating from the browser.

Also another idea is to have it pkgdoc.org act as a proxy that will redirect go get to the appropriate package. Then you could introduce authenticated users who have permission to change where this redirects. This would greatly help situations where a project moves from one service to another while not breaking code that depends on the original location.

Example:
import "pkgdoc.org/redis" //Redirects to stored url to package hosted repo master branch
import "pkgdoc.org/Mortdeus/redis" //redirect to user Mortdeus's forked repo
import "pkgdoc.org/redis/test" //redirects to test branch if it exists else returns 404

There are a bunch of cool ways this could be used and in my opinion is a prettier and much more convenient way to use go get import semantics.

Also I think we could extend pkgdoc.org into being a general purpose web application for other languages to. I assume you were thinking of that since you have the url for pkgdoc.org.

We would just have to introduce a specific format for documentation in languages to be used in pkgdoc.

I mean we could have a py.pkgdoc.org, ruby.pkgdoc.org, c.pkgdoc.org, cpp.pkgdoc.org, ect...

Just a thought, but im already going ahead and working on making this legit. Also ill work on the aesthetics of the website and create a logo if you want.

Heres some examples of my design work.
http://imgur.com/a/vN1o1,
http://www.gocos2d.org/ (still very early in terms of website layout, but the logo is finished)

Let me know what you think about all of this. :)

This works:

go get camlistore.org/pkg/fileembed

but it doesn't show up in pkgdoc (because the magic is on a 404 page, I think)

I suspect the following line:
https://github.com/garyburd/gopkgdoc/blob/master/doc/doc.go#L57

Using some library like color-mirror, this is not a big job.

If possible, it would be nice to have the subject supported in the same way as godoc does.

Trying to get
bitbucket.org/gotamer/conv

It should not to get the documentation from souce files with build constrain: build ignore

URLs that used to work now give 404. Example: http://go.pkgdoc.org/github.com/globocom/tsuru/cmd/tsuru.

Even packages listed in the index displays 404: http://go.pkgdoc.org/github.com/globocom/tsuru/errors.

What happened?

Explain that packages are deleted from GoPkgDoc when the repo is deleted. Add email address for force deletion of package.

Send your ideas, feature requests and questions to the author via Github
The via Github link is a page 404.

The links to source code lines, e.g. function names have too few left padding/margin. This is how it looks like in Chromium 18: http://i.imgur.com/WaV5j.png
Link to source page so you can check for yourself: http://go.pkgdoc.org/github.com/sauerbraten/radix

If I'm looking at a page of documentation and want to look something else up, I either have to open another tab or go back to the front page. It would be useful to have a quick search bar visible in the top bar.

It does not add the public methods of private types.

Like an example, you can see the output for a program with this use.

• Find all packages in the project.
• Fetch package level data once instead of once per package.

Look for branch or tag that matches version of Go.

• Github
• Google Project Hosting
• Launchpad
• Bitbucket
• Gitorious

Will be great to have gitorious.org support on gopkgdoc.

I did not include a link to /-/go in the navigation bar because golang.org should be the place to go for doc on standard packages.

Requested by Jimmy Zelinskie

Example: http://go.pkgdoc.org/github.com/chsc/gogl/gl42#Ushort

Suggested by @kisielk in #50 comment.

Here's a snapshot of the data: https://gist.github.com/4475318

https://code.google.com/p/google-code-prettify/

Requested by Jimmy Zelinskie

Exported methods attached to an unexported embedded struct are not shown.
For example, consider package neo4j. Types Node and Relationship contain an embedded neoEntity struct. The neoEntity type itself is not exported. However many exported methods are attached to the embedded neoEntity struct, and are thus exported from the final Node and Relationship types.

The methods in question are for sure exported - they can be accessed from code that imports the package, and they are shown in the output of go doc.

GoPkgDoc shows only a few methods on Node and Relationship. Yet go doc's output shows many more:

package neo4j
    import "github.com/jmcvetta/neo4j"

    Package neo4j provides a client for the Neo4j graph database.

VARIABLES

var (
    BadResponse        = errors.New("Bad response from Neo4j server.")
    NotFound           = errors.New("Cannot find in database.")
    FeatureUnavailable = errors.New("Feature unavailable")
    CannotDelete       = errors.New("The node cannot be deleted. Check that the node is orphaned before deletion.")
)


TYPES

type Database struct {
    // contains filtered or unexported fields
}
    A Database is a REST client connected to a Neo4j database.

func NewDatabase(uri string) (db *Database, err error)

func (db *Database) CreateNode(p Properties) (*Node, error)
    CreateNode creates a Node in the database.

func (db *Database) GetNode(id int) (*Node, error)
    GetNode fetches a Node from the database

func (db *Database) GetRelationship(id int) (*Relationship, error)
    GetRelationship fetches a Relationship from the DB by id.

func (db *Database) RelationshipTypes() ([]string, error)
    RelationshipTypes gets all existing relationship types from the DB

type Node struct {
    // contains filtered or unexported fields
}
    A node in a Neo4j database

func (e *Node) Delete() error
    Delete removes the object from the DB.

func (e *Node) DeleteProperties() error
    DeleteProperties deletes all properties.

func (e *Node) DeleteProperty(key string) error
    DeleteProperty deletes property key

func (e *Node) GetProperty(key string) (string, error)
    GetProperty fetches the value of property key.

func (n *Node) Id() int
    Id gets the ID number of this Node.

func (n *Node) Incoming(types ...string) (map[int]Relationship, error)
    Incoming gets all incoming Relationships for this Node.

func (n *Node) Outgoing(types ...string) (map[int]Relationship, error)
    Outgoing gets all outgoing Relationships for this Node.

func (e *Node) Properties() (Properties, error)
    Properties fetches all properties

func (n *Node) Relate(relType string, destId int, p Properties) (*Relationship, error)
    Relate creates a relationship of relType, with specified properties,
    from this Node to the node identified by destId.

func (n *Node) Relationships(types ...string) (map[int]Relationship, error)
    Relationships gets all Relationships for this Node, optionally filtered
    by type, returning them as a map keyed on Relationship ID.

func (e *Node) SetProperties(p Properties) error
    SetProperties updates all properties, overwriting any existing
    properties.

func (e *Node) SetProperty(key string, value string) error
    SetProperty sets the single property key to value.

type Properties map[string]string
    Properties is a bag of key/value pairs that can describe Nodes and
    Relationships.

type Relationship struct {
    // contains filtered or unexported fields
}
    A relationship in a Neo4j database

func (e *Relationship) Delete() error
    Delete removes the object from the DB.

func (e *Relationship) DeleteProperties() error
    DeleteProperties deletes all properties.

func (e *Relationship) DeleteProperty(key string) error
    DeleteProperty deletes property key

func (r *Relationship) End() (*Node, error)
    End gets the ending Node of this Relationship.

func (e *Relationship) GetProperty(key string) (string, error)
    GetProperty fetches the value of property key.

func (r *Relationship) Id() int
    Id gets the ID number of this Relationship

func (e *Relationship) Properties() (Properties, error)
    Properties fetches all properties

func (e *Relationship) SetProperties(p Properties) error
    SetProperties updates all properties, overwriting any existing
    properties.

func (e *Relationship) SetProperty(key string, value string) error
    SetProperty sets the single property key to value.

func (r *Relationship) Start() (*Node, error)
    Start gets the starting Node of this Relationship.

func (r *Relationship) Type() string
    Type gets the type of this relationship

There is an error when you visit any project docs page.

I guess this has to do with Google app engine resource usage. If you are running out I'm sure there are many happy Go users who wouldn't mind chipping in a few bucks for more hosting.

This is not a bug, but a suggestion for an enhancement. A number of libraries rely on Go's experimental packages, and because of that, are not go-gettable thus not indexed on the site (although their doc is still available).

Experimental packages being somewhat part of Go (what I mean by that is it's not like asking to pre-install a random package, this is part of Go's source tree), it would seem reasonable to pre-install them so that more packages become go-gettable. Yes this is partly egocentric, as my GoQuery and GoCrawl libraries are in this situation, but so is Cascadia and probably a bunch of other interesting libraries out there :)

Here's Andrew Gerrand's recipe to install the experimental packages, should you move ahead with this suggestion:
http://code.google.com/p/go-wiki/wiki/InstallingExp

Thanks,
Martin

I was messing around with the default tracking branch of a git repository to
figure the best way of making work nicely with go get. It seems to have
caused some issues at your end, as my package is no longer updated correctly.
The solution is probably just a simple matter of deleting the local package, but
this also indicates that there might be an edge case bug in here somewhere.

My timeline of changes went something like this:

• stable and master branch point to the same commit. master is the default
  tracking branch.
• add new commits to master.
• change default tracking branch to stable (this doesn't really change the
  behaviour of go get, as go get will simply retrieve the most recent
  version of the package unless you tag it correctly).
• refresh docs for the package at gopkgdoc.appspot.com — which will point to
  the most recent commit in master branch.
• delete remote master branch
• push local stable branch to remote master (git push origin stable:master)
• change default tracking branch to master
• delete remote stable branch

As you can see there are many point of faliure here, and none of them are
guaranteed have caused the stale cache.

Anyhow, I thought I'd let you know, and thanks for all the fish :)

S.

The package in question was http://github.com/simonz05/godis

When viewing package documentation locally with godoc -http=":6060", functions named by the pattern Example* that are included in *_test.go files are automatically collated and added to the Index section under an Examples header. In addition, a link is added under the import Overview/Index links to navigate to the list of examples.

GoPkgDoc does display the examples in the Index with a small graphic next to functions that have the examples, but I would like to suggest the functionality describe above be added as well. At the least, perhaps simply make the functions that have examples more noticeable. Myself and a couple of other people I was chatting with had not noticed the little link icon for examples at all. I only finally noticed the links while I was writing this issue and checking to make sure I wasn't missing anything, which turned out to be the case .

Hi, I'm using mgo, it works so fine.
But now I have som questions:
How to do regular expression query and $where query with mgo?

Certainly, $where query is not import, I can fetch the data, and then filter with go program.

thanks & best regards
xing zhang

Hi there!

So I've got a repo with several branches:

https://bitbucket.org/jaybill/sawsij/src

gopkgdoc appears to pick up one of our development branches, (the 2.x one in particular) instead of "default".

http://godoc.org/bitbucket.org/jaybill/sawsij/framework

The docs being displayed are wrong for the current default branch.

I have a package with import path at "go.3fps.com/utils/log" where I have this meta tag:

<meta name="go-import" content="go.3fps.com/utils/log git https://github.com/3fps/log2go.git">

http://go.pkgdoc.org/github.com/go.3fps.com/utils/log does not work
but http://go.pkgdoc.org/github.com/3fps/log2go works just fine.

Do I need to do something special?

Content of https://go.3fps.com/utils/log:

<html>
<head>
<meta name="go-import" content="go.3fps.com/utils/log git https://github.com/3fps/log2go.git">
</head>
<body>
<p>You're being redirected to the API documentation...</p>
<script>
setTimeout(function() {
window.location="http://go.pkgdoc.org/go.3fps.com/utils/log"+window.location.hash;
}, 2)
</script>
</body>
</html>

it would be nice to have, say, an entry box on the landing page into which one could
provide a github (why just github?) project's address.

Only displays exported functions, not exported methods. See:

func (n *node)WriteTree() in github.com/clbanning/x2j.

It looks to be happening on any package that uses that uses cgo (that is, includes import "C").

On the snowball package page, it says snowball imports 4 packages. Clicking the link in that section leads you to the import page that only lists 3.

Same thing happens on the levigo and others, but not on non-cgo projects.

add such as :

/api/search 
/api/add

will be much great

And then ,we can do :

go search "mysql"
>> github.com/xxxx/mymysql
>> xxxx/xxx/go-mysql

If you take a look at http://gopkgdoc.appspot.com/pkg/github.com/humanfromearth/gopathfinding#Astar there is a link to Wikipedia which is broken I guess that some regexp doesn't like * in urls.

Example: http://golang.org/pkg/encoding/xml/#pkg-bugs
Syntax described at: http://golang.org/doc/articles/godoc_documenting_go_code.html

I sent you an email explaining that snippet.

In regards to the API for the package manager, the most essential feature thats probably the only thing that should be worried about is the raw text http request for a specific package. What im envisioning is to use termbox (nsf's ncurses-like tty graphics lib.) and implement a package manager command line termbox-client that can request pkg data from a web server hosted on appengine, and have it all nicely displayed and organized.

This would make it so you dont have to install a window manager, and can have a nice go dev environment even if you dont want to install X11 to browse the web via chrome/firefox ect. (This is nice for servers, and for minimalist linux distros like archlinux, ect.)

So I think pkgdoc's best contribution to the manager itself would be just having a raw text http response for a package that can be fetched by the server so the doc can be forwarded to the users local terminal client. That way you dont have to go get the actual repo to check out the godoc for that pkg while browsing.

Have you ever used archlinux's package manager (pacman)?

I don't know if this is intentional or if it is possible to add this to the architecture, but if you search for string, the strings package doesn't show up.

Set package source URLs for:

• Bitbucket
• Launchpad
• Google Project Hosting
• GItorious

• Limit number of files per package.
• Limit size of an individual file.

As the owner of a package, when I've pushed a package, I'd like to be able to tell gopkgdoc to refresh
its cache of the package docs rather than letting it time out for itself.