niemeyer / gopkg Goto Github PK
View Code? Open in Web Editor NEWSource code for the gopkg.in service.
License: Other
Source code for the gopkg.in service.
License: Other
Am I right that atm only github.com is supported? What about self-hosted Git instances? Can we add support for other sites, too?
Not sure where the problem lies here, but external systems reference gopkg.in/v2/yaml , which cannot be resolved by go get (go get gopkg.in/yaml.v2 works though)
e.g. https://github.com/GoogleCloudPlatform/kubernetes/blob/master/Godeps/Godeps.json
Is that incorrect, and/or did something change at gopkg.in?
https fetch failed: Get https://gopkg.in/mgo.v2?go-get=1: unexpected EOF
Sorry, no more details than that. I see this error occasionally.
gopkg considers this repo an unsupported URL pattern even though the github repo exists: http://gopkg.in/nickjones/proc_box.v1.
I am not sure if this is the appropriate forum to bring up such issue, but here goes.
When I run go get -v gopkg.in/yaml.v2
while on my corporate VPN, I get the error: Failed to connect to gopkg.in port 443: Operation timed out
, but go get
works just fine on my home network.
Additionally, I can't even hit https://gopkg.in on corporate VPN, but works fine on my home network.
I originally suspected my corporate VPN / strict firewall policies to be the problem, but I was able to hit a number of *.in
domains.
I am starting to think that perhaps gopkg.in
has blocked the egress IP address of my corporate VPN.
Any ideas?
Hi,
The package https://gopkg.in/h2non/bimg.v1 points to tag v1.0.8, even though v1.0.9 has been pushed over 4 hours ago (at moment of writing).
When can I expect the update to take place?
Cheers,
Mark
GoDoc.org (like godoc) provides links in the documentation to the source code when the viewer clicks on the function name.
For code hosted on the major sites (github, bitbucket, google code) the links are present and work correctly, but no links are present on gopkg.in packages.
Hi @niemeyer,
This is not an issue, more of a question really. Is there any plan to add support for self hosted deployments. It would be really cool if we can use this tool internally. I was reading through the code, and I suppose to do such a thing would be quite doable, for the most part it's about replacing "gopkg.in" with a variable (perhaps flag) and other such values which are now hard coded.
Would you be accepting pull requests for these additions? Do you have any guidelines or recommendations for contributing?
Thanks,
Alex
gopkg.in considers the following URL invalid though it should map to a GitHub repo that exists: http://gopkg.in/errcw/glow.v0/gl-core/4.4/gl. I believe this is the result of the URL parsing regular expressions being too strict.
Error pages should display more information.
For instance, once a package has created a version branch, the pkg.v0 will be invalidated. Right now this is displayed as:
GitHub repository at https://github.com/go-yaml/yaml has no branch or tag "v0", "v0.N" or "v0.N.M"
This could be a page explaining that the package might have launched it's firsts version. e.g.:
Maybe this package was released under a stable version number. Try <a>pkg.v1</a>
Also; it wouldn't hurt to have all errors in the same styling as the home and pkg page. We could do this by creating a generic "error" page.
If you agree, I'm willing to start working on it.
██ go get -u gopkg.in/mattes/migrate.v1
will result in pulling master on https://github.com/mattes/migrate instead of branch v1, any idea how that can happen
I just tried refreshing the documentation of my package Gomail which use gopkg.in and GoDoc showed this error: Error refreshing package: Internal server error.
Whereas refreshing the documentation of github.com/go-gomail/gomail worked fine:
So I tried refreshing mgo's documentation, and there's no error with labix.org/v2/mgo but I just got this error with gopkg.in/mgo.v2: Error refreshing package: Error getting package files from gopkg.in.
Since gopkg is making a MitM between the real repository and the clients, we can track the number of clones and some other cool metrics. I will love know a bit more about how often are my packages used.
Caveats:
The bad part of this is that for keep the stats the service will require storage.
I can work in this feature if fits on the project scope.
How about Gitlab.
https://gopkg.in/fsnotify/fsnotify.v0 reports v0.14.0, as it should be.
But when I do a fresh go get -u gopkg.in/fsnotify/fsnotify.v0
and less CHANGELOG.md
, I only see v0.9.0.
Also, the documentation at http://godoc.org/gopkg.in/fsnotify/fsnotify.v0 is showing the old v0.9.0 API.
I'm not sure why this is. Is it just pulling the wrong tag from the right repo?
Or worse, is it pulling the wrong repo altogether. Perhaps https://github.com/howeyc/fsnotify? As you can see, http://gopkg.in/howeyc/fsnotify.v0 points to v0.9.0.
As you know, go1.4 will allow developers to specify the canonical import path that should be used for importing a package. For packages that include this, gopkg should not recommend using a gopkg import path.
For example, the appengine library uses an import path of google.golang.org/appengine. However, if you were to navigate to http://gopkg.in/golang/appengine.v0, you would be instructed to use an import path of gopkg.in/golang/appengine.v0
, which is clearly wrong and won't be allowed by the go command.
Instead, if gopkg detects that a package is using a canonical import path, it should display some kind of message to the effect of:
This package uses the canonical import path
example.com/foo
and therefore cannot be used with gopkg.Using gopkg is great because it supports features X, Y, and Z. Feel free to contact the developer of package foo and tell them why they should use it. In the meantime, you can get this package using:
go get example.com/foo
and import this package using:
import "example.com/foo"
To be clear, I think using this as a place to promote the benefits of gopkg is totally fine, but it should still respect the developer's declared import path.
is failing with
go: gopkg.in/[email protected]: unrecognized import path "gopkg.in/yaml.v2" (parse https://gopkg.in/yaml.v2?go-get=1: no go-import meta tags ())
and has been for a few days now.
dustin@jemison ~ $ curl https://gopkg.in/yaml.v2?go-get=1
<html>
<head>
<meta name="go-import" content="gopkg.in/yaml.v2 git https://gopkg.in/yaml.v2">
<meta name="go-source" content="gopkg.in/yaml.v2 _ https://github.com/go-yaml/yaml/tree/v2.2.2{/dir} https://github.com/go-yaml/yaml/blob/v2.2.2{/dir}/{file}#L{line}">
</head>
<body>
go get gopkg.in/yaml.v2
</body>
</html>
I can't reproduce this locally, but I expect that yaml.v2 has been cached somewhere for me.
Can not get packages like go get gopkg.in/alecthomas/kingpin.v2
. It will fail with the following error: Unknown SSL protocol error in connection to gopkg.in:-9838
For example, if router.go
of main
uses trie
package in a subdir, I tried gopkg.in/GlassyMedia/go-json-rest/trie.v1
but it doesn't seem to work. Is this feature available?
I can send in a pull request if you point me in the right direction on how to patch it.
├── router.go
├── router_benchmark_test.go
├── router_test.go
├── status.go
├── status_test.go
├── test
│ └── util.go
├── timer.go
└── trie
├── impl.go
└── impl_test.go
Are there plans to just allow any ref to be fetched? Right now only branches are supported.
run:
$ go get gopkg.in/yaml.v2
result:
# cd .; git clone https://gopkg.in/yaml.v2 /Users/akupila/go/src/gopkg.in/yaml.v2
Cloning into '/Users/akupila/go/src/gopkg.in/yaml.v2'...
error: RPC failed; HTTP 301 curl 22 The requested URL returned error: 301
fatal: The remote end hung up unexpectedly
package gopkg.in/yaml.v2: exit status 128
I suspect this could be related to the recently added Let's Encrypt support. I'm not very familiar with how git clone works under the hood but some quick googling and found https://github.com/gitlabhq/gitlabhq/issues/3892
Hello, folks!
I'm using your project and everything working well. I working from MacOS, CentOS 7 and everything goes smoothy.
But from one server with CentOS 6 I expected so huge issues:
git clone -v https://gopkg.in/tomb.v2
Initialized empty Git repository in /root/tomb.v2/.git/
......
And process hangs.
I have traced it with strace:
strace -f -etrace=connect git clone -v https://gopkg.in/tomb.v2
Initialized empty Git repository in /root/tomb.v2/.git/
Process 166342 attached
[pid 166342] connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 166342] connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 166342] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.133.100.100")}, 16) = 0
[pid 166342] connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("107.178.216.236")}, 16) = -1 EINPROGRESS (Operation now in progress)
Process 166343 attached
[pid 166343] +++ exited with 0 +++
[pid 166342] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=166343, si_status=0, si_utime=0, si_stime=0} ---
Process 166344 attached
[pid 166342] connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.133.100.100")}, 16) = 0
[pid 166342] connect(6, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("107.178.216.236")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 166342] connect(9, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.133.100.100")}, 16) = 0
[pid 166342] connect(9, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.30.252.129")}, 16) = -1 EINPROGRESS (Operation now in progress)
So as you can see we have issues with Git itself.
I have checked another server from another network with CentOS 6 and same Git tool version and got same issues:
git clone https://gopkg.in/tomb.v2
Initialized empty Git repository in /root/tomb.v2/.git/
....
it hangs too
Could you test it and fix? I could offer any debug details.
I would like to propose allowing people to write their own Go HTTP server with import "github.com/niemeyer/gopkg"
or perhaps import "gopkg.in/gopkg.v1"
.
The primary purpose would be:
example.com/pkg.v1
-> github.com/specificuser/pkg
), identical to self-hosting (see #16).example.com
.example.com/pkg.v1
in a browser could display a custom page with news about the package or other things.The package would need to expose a way to:
gopkg
to handle a given HTTP request by writing an appropriate response, it would be no-op if the path was not a package (e.g. example.com/some/page.html
would be no-op).net/url.URL
is a package path (e.g. example.com/pkg.v1
) so that a custom package page can be rendered.Would others find such a feature useful?
Hi,
It seems the gopkg.in is no longer reachable through HTTPS. Did the certs expire or something? It would be nice to have this fixed soon as our project depends on some packages in gopkg.in.
https fetch failed: Get https://gopkg.in/redis.v5?go-get=1: remote error: tls: internal error
package gopkg.in/redis.v5: unrecognized import path "gopkg.in/redis.v5" (https fetch: Get https://gopkg.in/redis.v5?go-get=1: remote error: tls: internal error)```
The default branch of a git repository is its remote HEAD branch.
In modern versions of Go, go get
respects the default branch and uses it.
I have a tool that verifies that a Go package has the default branch checked out (and lets you know if it's not). It's currently failing to work correctly on some gopkg.in
repositories. This is because the implementation of changeRefs
does something that causes the remote HEAD to be ambiguous.
Consider gopkg.in/sourcemap.v1
import path.
If I go get
(or git clone
) it and cd into the directory:
$ git remote show origin
* remote origin
Fetch URL: https://gopkg.in/sourcemap.v1
Push URL: https://gopkg.in/sourcemap.v1
HEAD branch (remote HEAD is ambiguous, may be one of the following):
master
v1
Remote branches:
master tracked
v1 tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
Note:
HEAD branch (remote HEAD is ambiguous, may be one of the following):
master
v1
On the other hand, a regular git repository such as github.com/gorilla/mux
typically prints:
$ git remote show origin
* remote origin
Fetch URL: https://github.com/gorilla/mux
Push URL: https://github.com/gorilla/mux
HEAD branch: master
Remote branches:
custom-context tracked
master tracked
matcher-refactor tracked
subexp-fix tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
Note the single unambiguous value in HEAD branch: master
.
This issue was originally reported at shurcooL/Go-Package-Store#72 (/cc @mvdan), you can see it for more details.
You can reproduce it by running this code:
package main
import (
"fmt"
"log"
"github.com/shurcooL/vcsstate"
)
func main() {
rv, err := vcsstate.NewRemoteVCS(vcs.ByCmd("git"))
if err != nil {
log.Fatalln(err)
}
branch, revision, err := rv.RemoteBranchAndRevision("https://gopkg.in/sourcemap.v1")
fmt.Printf("branch = %q\nrevision = %q\nerr = %v\n", branch, revision, err)
// Output:
// branch = ""
// revision = "6e83acea0053641eff084973fee085f0c193c61a"
// err = HEAD branch not found in ls-remote output
}
On the other hand, a git repository from github results in:
branch, revision, err := rv.RemoteBranchAndRevision("https://github.com/gorilla/mux")
fmt.Printf("branch = %q\nrevision = %q\nerr = %v\n", branch, revision, err)
// Output:
// branch = "master"
// revision = "599cba5e7b6137d46ddf58fb1765f5d928e69604"
// err = <nil>
RemoteBranchAndRevision
internally uses git ls-remote --symref remoteURL HEAD refs/heads/*
, see its code.
You can also compare the output of:
curl -A 'git/2:2.1.1+github-607-gfba4028' 'https://github.com/gorilla/mux/info/refs?service=git-upload-pack'
curl -A 'git/2:2.1.1+github-607-gfba4028' 'https://gopkg.in/sourcemap.v1/info/refs?service=git-upload-pack'
git ls-remote --symref 'https://github.com/gorilla/mux' HEAD 'refs/heads/*'
git ls-remote --symref 'https://gopkg.in/sourcemap.v1' HEAD 'refs/heads/*'
I believe the root issue is in changeRefs
and that needs to be fixed.
I'm using git version 2.10.1 (Apple Git-78)
and go version go1.8 darwin/amd64
.
Please let me know if you need any more information to reproduce this @niemeyer. Thank you.
Running
go get -u gopkg.in/alecthomas/gometalinter.v1
I get an installed binary called gometalinter.v1
. I would expect to simple call a binary called gometalinter
directly, but that does not work.
Is that something that can be fixed in gopkg? Or is this dependent on logic within go get
?
Suppose I import "gopkg.in/pipe.v1" in my project, and one day there's an improved API-breaking change, which is available as "gopkg.in/pipe.v2".
If the same improved API-breaking change happened for a package not using gopkg.in, it's likely (but not guaranteed) that I would find out when I update that Go package via go get -u
and find that my code no longer compiles. Then I can proceed to look at the API change and update to new, improved API.
How can I find out about potential new versions for packages that do use gopkg.in?
I think it would be a big improvement if http://gopkg.in showcased popular packages that are conforming to the versioning standards and being heavily used. This would help adoption and give incentives to package maintainers to share the word about gopkg.in.
@nuveo maintains a software called pREST that this in the beta version, today we generate version 0.2 that is not compatible with 0.1, how to deal with this case in gopkg?
This is what happened when I disabled StartCom from the list of System Root CAs, which prevented package manager (Glide in my case) from fetching any gopkg.in
dependencies.
Consider the community's response to what WoSign and StartCom did, it's a good practice to disable them. Maybe switch to Let's Encrypt?
Is there any way to currently pull a specific git commit via sha? instead of relying on branches and tags?
Thank you
I created a new organisation, github.com/go-myorg, and a new repository, github.com/go-myorg/myorg, then pushed a "v1" branch in that repo.
gopkg.in did not recognise the branch (I got an error saying that the branch was not found).
When I pushed a "master" branch to that repo, gopkg.in/myorg.v1 immediately started working.
See kubernetes/kubernetes#39583 for an example of this failure
Hi, assume I have a library which is unstable and in v0 but still being used in several other projects. I don't want to switch major version to 1 yet as backwards incompatible changes are still being made frequently.
However I want my other library dependent projects stick to some particular v0 versions (let's say project Foo uses v0.1 and project Bar uses v0.2) and not break anytime backwards incompatible changes are introduced to the library. And as I see this is currently not possible with v0 packages (getting a message like package gopkg.in/foo/bar.v0.2: unrecognized import path "gopkg.in/foo/bar.v0.2"
).
I understand we could switch the major version anytime breaking changes are introduced but having a library of version v13.1.5 which is not production ready is funny.
Is there a chance you start supporting minor versions for v0 projects and if so would you accept PR with such a change? Hopefully I could find some time to dig into your code and make appropriate changes.
Thanks!
$ go get github.com/micro/go-config
package gopkg.in/yaml.v2: unrecognized import path "gopkg.in/yaml.v2" (https fetch: Get https://gopkg.in/yaml.v2?go-get=1: read tcp 10.233.243.127:52710->35.196.143.184:443: wsarecv: An existing connection was forcibly closed by the remotehost.)
There's an uptime report link on the website, but when I follow it, it tells me:
Public Report Not Activated
They could do with updating in the light of http://blog.labix.org/2015/01/13/improvements-on-gopkg-in
I'd like to get able to ask gopkg.in for available versions of a package.
For example, I do a GET gopkg.in/stretchr/graceful.vlist
or similar, and I receive a JSON (or otherwise) response containing a list of all available versions for this repository.
This would be useful for tools. For example:
gopkg.in
imports and inform of new releasesgopkg.in
gopkg.in
importsEffectively the goal is to make it easy to discover and use gopkg.in
import paths for packages, hopefully encouraging developers to use it more.
I'm not sure if this is philosophically opposed to the gopkg philosophy, but I figured creating an issue was the best way to see if it could be done :).
I am new to Go, but my company is switching from a primarily javascript/Node.js backend to a Go backend.
With package and dependency management systems in other languages (Java, Node), I've had enough bad experiences surrounding automatically pulling in updated code that supposedly follows semantic versioning that I have completely written off any sort of automatic resolution of semantic versioning and, instead, prefer to know exactly which version I am dealing with, always.
This is also required if you want "repeatable builds". Where a "repeatable build" is defined as the output from multiple builds done on different machines (but with the same architecture) should produce the exact same output. If your build system might pull down a different version of a library, then the output can be different.
For these reasons, I'd like to request the ability to specify the full, exact version that I would like to depend on with gopkg.
I can probably help out with a PR if you point me in the right direction for what to adjust.
Are you planning on licensing this? I would definitely be interested in using this, or parts of it at least, for my personal repos as well as a possible community site I've been working on.
Can we please have a temporary workaround in gopkg.in to fix the fsnotify breakage?
I can't just rewrite all the imports in all my branches and tags and update all the vendored packages (assuming they have been fixed at all).
$ go get gopkg.in/ini.v1
# cd .; git clone https://gopkg.in/ini.v1 ./src/gopkg.in/ini.v1
Cloning into './src/gopkg.in/ini.v1'...
fatal: unable to access 'https://gopkg.in/ini.v1/': Unknown SSL protocol error in connection to gopkg.in:-9838
package gopkg.in/ini.v1: exit status 128
$ go version
go version go1.7.4 darwin/amd64
I use macOS v10.12.3 (16D17a)
This error is constant for several months, but on Linux there are no errors.
How to add projects without the v prefix ?
This is a pain point that has shown up a few times and I think we should address, so here is the rationale and a candidate plan for it.
In a few cases I wanted to share an unstable sneak peak of the next API version. The most recent case at hand was the gopkg.in/qml.v0 => v1 migration. The problem was that the new project API version was still being worked on at a fast pace, breaking every day, and at the same time there were people interested in experimenting and helping out on the new API. This forced the early release of gopkg.in/qml.v1, with an unstable qml.v1/gl subpackage, which is not great and kills the expectation of stability that we want to create. This also sounds like a common problem, that we should address for everybody with a well known pattern rather than struggling every time.
So the current plan is to introduce support for vN-dev
selector in URLs, which map to the vN*-dev
tag/branch. In the example cited, this would allow the development of v1-dev publicly, while clearly marking the content as in-development. Once the daily breakages stop, it can be tagged/copied into the v1
release appropriately and as usual.
Please feel free to provide feedback here. If there are no major uncovered points, I'll work on this soon.
I would like to import the gradfix
branch of https://github.com/srwiley/oksvg.
gopkg.in/srwiley/oksvg.gradfix
does not resolve to the gradfix
branch of https://github.com/srwiley/oksvg, instead it says
Unsupported URL pattern; see the documentation at gopkg.in for details.
Why?
Reference:
srwiley/oksvg#15 (comment)
Doing go get gopkg.in/yaml.v2
on my machine or any package from gopkg.in
fails with the error:
$ go get -v gopkg.in/yaml.v2
Fetching https://gopkg.in/yaml.v2?go-get=1
Parsing meta tags from https://gopkg.in/yaml.v2?go-get=1 (status code 200)
get "gopkg.in/yaml.v2": found meta tag main.metaImport{Prefix:"gopkg.in/yaml.v2", VCS:"git", RepoRoot:"https://gopkg.in/yaml.v2"} at https://gopkg.in/yaml.v2?go-get=1
gopkg.in/yaml.v2 (download)
# cd .; git clone https://gopkg.in/yaml.v2 C:\gocode\src\gopkg.in\yaml.v2
Cloning into 'C:\gocode\src\gopkg.in\yaml.v2'...
fatal: The remote end hung up unexpectedly
error: RPC failed; HTTP 301 curl 22 The requested URL returned error: 301
package gopkg.in/yaml.v2: exit status 128
Does it have to do with the location of my machine? Singapore.
It appears that gopkg.in prefers the go1 branch over a properly versioned branch? This seems like a bug to me. One specific reason for which I want a go1 branch is to force users to use the gopkg.in imports for master without having custom import comments in the master branch itself (which is impractical for development).
I created a test repo: https://github.com/rightscale/gopkgintest which has master, go1 and v1.0.9 branches. They all have slightly different simple.go to make them easy to identify. Here's what I get:
$ cd /tmp
tve@h:/tmp$ mkdir -p go/src
tve@h:/tmp$ cd go/src
tve@h:/tmp/go/src$ export GOPATH=/tmp/go
tve@h:/tmp/go/src$ go get -v gopkg.in/rightscale/gopkgintest.v1
Fetching https://gopkg.in/rightscale/gopkgintest.v1?go-get=1
Parsing meta tags from https://gopkg.in/rightscale/gopkgintest.v1?go-get=1 (status code 200)
get "gopkg.in/rightscale/gopkgintest.v1": found meta tag main.metaImport{Prefix:"gopkg.in/rightscale/gopkgintest.v1", VCS:"git", RepoRoot:"https://gopkg.in/rightscale/gopkgintest.v1"} at https://gopkg.in/rightscale/gopkgintest.v1?go-get=1
gopkg.in/rightscale/gopkgintest.v1 (download)
gopkg.in/rightscale/gopkgintest.v1
tve@h:/tmp/go/src$ cd gopkg.in/rightscale/gopkgintest.v1
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ git status
HEAD detached at origin/go1
nothing to commit, working directory clean
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ cat simple.go
package gopkgintest
func branch() string { return "go1" }
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ go version
go version go1.4 linux/amd64
When hitting the link:
http://gopkg.in/igm/sockjs-go.v1/sockjs
I get correct gopkg.in page.
However I have problems when referencing "v0" in the same way:
http://gopkg.in/igm/sockjs-go.v0/sockjs
I get an error:
GitHub repository at https://github.com/igm/sockjs-go has no branch or tag "v0", "v0.N" or "v0.N.M"
Also $ go get http://gopkg.in/igm/sockjs-go.v0/sockjs
fails. As far as I understand "v0" should reference "master" branch on github and I'm not completely sure but I think it worked correctly couple of days/weeks ago. Has anything changed or is it me doing something wrong?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.