raku / ecosystem Goto Github PK
View Code? Open in Web Editor NEWRaku ecosystem – modules and more
Home Page: https://modules.raku.org/
Raku ecosystem – modules and more
Home Page: https://modules.raku.org/
Seen in http://ecosystem-api.p6c.org/projects.json
Reload after a few seconds fixed it. I wonder if this happened because the first time I happened to access the file while it was being written to the disk or if there is some other problem.
There are 3 of them which show up when searching for test. They should probably be removed.
Some Perl 6 distributions listed on modules.perl6.org contain multiple modules, but those are currently unsearchable.
For example, say you want to test the output of your program. You search for keyword "test" and browse the available offerings. You find nothing and you proceed to write Test::Output, just so a couple of days later someone points out IO::Capture::Simple distribution that actually includes Test::IO::Capture module, but alas, it doesn't show up in search results.
Which causes errors such as this one. Spec admits both source-url
and support/source
.
Hopefully this can be a group effort to try and get these failing packages passing. Feel free to add issues and link them here. If you aren't a collaborator with the repo, just reply and somebody else can add it to this main list :-) Thank you all!
Log links are to specific lines in a Travis CI build that attempts to install all modules. This list is incomplete because this takes a very long time to do.
See here for full log:
UPDATE
I have a new format for the tests I am running on hack.p6c.org
There is a json file that's named for the date/time the test starts, and then a folder which contains log files for each module's installation. The JSON shows the exitcode, status and 'ok' or 'nok'. If the test times out there were be something indicating it there as well.
http://hack.p6c.org/~samcv/ecosystem-tests/
Undeclared routine:
eval_lives_ok used at line 5. Did you mean 'eval-lives-ok', 'eval-dies-ok'?
t/ok.t .. No subtests run
Could not find MONKEY_TYPING at line 1 in:
/home/samcv/.zef/store/data-pretty.git/c5b3922c37e3b97c9f0910e2ad5e468e9463e894/lib
An exception occurred while evaluating a BEGIN
at /home/samcv/.zef/store/perl6-pod-strip.git/2bb9b9dc3d593cbddc53092dcc3519b2a666afeb/t/test.t:2
Exception details:
Dynamic variable @*INC not found
in block at t/test.t line 2
Dynamic variable @*INC not found
in method plugins at /home/sena/.zef/store/perl6-pluggable.git/2cb08cb57ed133e11577442d3ab0c4da63e593eb/lib/Pluggable.pm6 (Pluggable) line 8
in method test at t/01-tests.t line 17
in block <unit> at t/01-tests.t line 70
Potential difficulties:
Useless use of hash composer on right side of hash assignment; did you mean := instead?
at /home/samcv/a/zef/site#sources/D33B2CF81EB010BB6A219D2AF5F873163A6DBF44 (FastCGI::Protocol):143
Some distributions have a version string that includes an v
, but that is incorrect, since it creates a version that is, first, less than any version without the V (so if you need 0.0.1+ it will fail), and second, it explicitly includes the v in it.
So my proposal would be to check for those strings starting now, and flag them as incorrect.
Maybe run a test over existing distributions too, and create automatically issues and/or PRs.
For instance
use *
over all modules, or at least the ones in the "provides" section of META6.json
Despite the PR saying explicitly you need to list a license or explain why not. It wouldn't be impossible to match the license field against the PR, but anyway the test returning "license is correct" instead of a warning because there's no license is probably LTA.
This allows super quick access to the actual thing being added for anyone who is following the repo. Perhaps we could add it as a suggestion in the repo and/or start asking PRs to add it?
For the time being, there are two File::Zip. By default, zef seems to install the one with the highest version. Since one of them does not have an author key, it can't be selected in any way. Can we solve this at the ecosystem level by forcing distributions with the same name to have a name field, or should we kick it forward to zef to solve that kind of thing?
Testing of new distributions added to the ecosystem is not, well, tested. It's a single script, which is to a large extent Test::Meta but includes other things (and maybe should include others like duplicates #517 or, going forward, security issues. This leads to accidental discovery of problems such as #549, caused mainly to the absence of a proper test set.
So It would be convenient to create, under the Raku organization, a Test::Ecosystem module (and corresponding Docker container) that would take care of this. It would have the basic functionality the test script's got now, plus any other we could think of.
Right now if all copies from CPAN are removed, I guess it's removed here too. However, it's not written anywhere how to remove modules from the ecosystem, or who can do it.
It seems pretty obvious that the author is the one that should do it, and probably via the same method that was used to list it: modify META.list; however, it's not really written anywhere.
In some cases, modules are listed by the author as "DEPRECATED", but they are still available in the ecosystem. It's not clear if that's the author's intention or there was simply no explicit way of removing them. Could the DEPRECATED mark be a sign for the ecosystem administrator to delete it?
I think so.
But, anyway, I guess it's better if it's clearly written, in the same way that module adoption is explicitly written here.
The module documentation page says that p6c will become obsolete. But it's not clear when, and how that will be done. That's causing confusion among module creators, and also people here in this repo that don't know whether merging pull requests or not.
A roadmap along the lines of
Maybe that's decided and set in stone somewhere; in that case, it's just a matter of linking from this README or adding it here.
Now that @melezhik 's rakudist system is in place, could we maybe add something like that to check for external dependencies? Right now everything with an external library is failing.
Generic P6 modules database does not update or updates from wrong branch/commit.
Files projects.json and projects1.json are frozen on @Kaiepi modules (that were removed in July).
I have quick investigation and found out, that first ./updatelist.pl works locally (new modules included):
...
https://raw.githubusercontent.com/Demayl/perl6-Sys-IP/master/META6.json 200
https://raw.githubusercontent.com/tmtvl/neural-net/master/META6.json 200
https://raw.githubusercontent.com/antoniogamiz/Perl6-TypeGraph/master/META6.json 200
https://raw.githubusercontent.com/antoniogamiz/Pod-Utilities/master/META6.json 200
https://raw.githubusercontent.com/kjkuan/Proc-Feed/master/META6.json 200
https://raw.githubusercontent.com/dmaestro/Module-Pod/master/META6.json 200
https://raw.githubusercontent.com/oposs/jsonhound/master/META6.json 200
https://gitlab.com/pheix/lzw-revolunet-perl6/raw/master/META6.json 200
Second ./server/updatelist.pl works locally too (new modules included):
https://raw.githubusercontent.com/Demayl/perl6-Sys-IP/master/META6.json 200
https://raw.githubusercontent.com/tmtvl/neural-net/master/META6.json 200
https://raw.githubusercontent.com/antoniogamiz/Perl6-TypeGraph/master/META6.json 200
https://raw.githubusercontent.com/antoniogamiz/Pod-Utilities/master/META6.json 200
https://raw.githubusercontent.com/kjkuan/Proc-Feed/master/META6.json 200
https://raw.githubusercontent.com/dmaestro/Module-Pod/master/META6.json 200
https://raw.githubusercontent.com/oposs/jsonhound/master/META6.json 200
https://gitlab.com/pheix/lzw-revolunet-perl6/raw/master/META6.json 200
The 1st idea: something wrong with ./updatelist.pl on server. This script grabs META.list from github. Maybe it's patched.
The 2nd idea: repo was cloned to server, checked out on exact commit and ./server/updatelist.pl parses this frozen META.list.
The 3rd idea: any other bug source))))
zef uses projects1.json:
===> Updating cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json
===> Updating p6c mirror: http://ecosystem-api.p6c.org/projects1.json
===> Updated p6c mirror: http://ecosystem-api.p6c.org/projects1.json
===> Updated cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json
----------------------------------------------------
Content Storage |Distribution Count
----------------------------------------------------
Zef::Repository::LocalCache |10
Zef::Repository::Ecosystems<p6c> |861
Zef::Repository::Ecosystems<cpan>|1393
----------------------------------------------------
So, all new modules, added after 21, May are not available via this utility. Strange, that's none noticed that fact.
If a module cannot be reached because the host server is down, the module won't be included in projects1.json and projects.json. And the module manager(zef) would not be able to find the module, although the module exists, it just could not be accessed.
Apparently projects1.json is generated in server/updatelist.pl and projects.json is generated in updatelist.pl.
It seems zef has 4 mirrors for getting the list of modules, first two of which are projects1.json and projects.json.
This is down: http://ecosystem-api.p6c.org/projects1.json which leads to docker builds and travis tests timing out. Perl6.org has been redirected elsewhere, can we redirect this elsewhere too?
If an executable program is installed as part of a module via zef (panda not yet tried), the
Usage: ./create-md.p6 ...
Usage: /usr/local/rakudo.d/share/perl6/site/resources/F6AB9B901B7071FBDB38FB8A77B549440AC84EE0 ...
Usage: ./create-md.p6 ...
Usage: /usr/local/rakudo.d/share/perl6/site/resources/F6AB9B901B7071FBDB38FB8A77B549440AC84EE0 ...
I also tried '$?FILE' but got the same results.
In the interim I will just hard-code the script name inside the file.
When zef installs the bin file, save the original file name and use its name to redefine $*PROGRAM and $*PROGRAM-NAME.
Because they are not recognized as a tar file, and they fail this way
As seen, for instance, here
After the rearrangement of distributions by alphabetical order, tests have been run again on many (or all, not sure) distributions, resulting in these failures
The following urls failed:
https://raw.githubusercontent.com/perl6/Blin/master/META6.json
https://raw.githubusercontent.com/perl6/DBIish/master/META6.json
https://raw.githubusercontent.com/perl6/Perl6-MIME-Base64/master/META6.json
https://raw.githubusercontent.com/perl6/form/master/META6.json
https://raw.githubusercontent.com/perl6/perl6-lwp-simple/master/META6.json
https://raw.githubusercontent.com/perl6/perl6-pod-to-bigpage/master/META6.json
https://raw.githubusercontent.com/perl6/whateverable/master/META6.json
https://raw.githubusercontent.com/perlpilot/benchmark/master/META.info
https://raw.githubusercontent.com/perlpilot/p6-AI-FANN/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-Astro-Sunrise/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-HexDump-Tiny/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-IO-Notification-Recursive/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-Locale-US/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-Math-Trig/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-Questhub/master/META6.json
https://raw.githubusercontent.com/perlpilot/p6-Test-Class/master/META6.json
https://raw.githubusercontent.com/pierre-vigier/Perl6-Data-MessagePack/master/META6.json
https://raw.githubusercontent.com/pierre-vigier/Perl6-HTTP-Signature/master/META6.json
https://raw.githubusercontent.com/prodotiscus/perl6-Dictionary-Create/master/META6.json
As an immediate action, we should maybe try and notify their authors. As a more long-term thing, and looking at improving the state of the ecosystem we should maybe run a GitHub action or something periodically, and decide on a solution for them.
For instance, here. [email protected]
fails to download.
Additionally, in this case there are two different source URLs, one of which is usable. We could maybe check them both if that's the case.
Right now, it just looks for new lines and tests them; but it fails in the case lines are deleted, for instance, or in simply other cases where the underlying software is going to be changed.
In that sense, the testing script should also become a module that should be tested independently for all possible cases that might arise. Right now it's not totally clear it's testing correctly, and in many cases (for instance, external dependencies) we just "let it pass" (we have to locally test, anyway). That case is going to be difficult to cover, but in many others it shouldn't
E.g. Module 007 stargazers has a link to https://github.com/masak/007stargazers
It is missing a slash and should be like https://github.com/masak/007/stargazers
. It is the same for the link to issues.
In this case should be https://github.com/masak/007/issues
instead of https://github.com/masak/007issues
.
For example, it failed on this PR, but it doesn't look like there are any issues in it.
Seems the travis checking thing is choking on this dist due to it listing a .zip and not a git repo as source-url? Also, briefly looking through the source of the travis checker, I see along with assuming source URL is always a git repo, it's also assuming source-url
field is the only one it's specified in.
Actually, source-url
is an ecosystem extension and "proper" way to specify source is via "support": { "source": ...
key, so the checker needs to check that too.
If there's anything else, like a tar file of any other kind of source, it will not work. This is related to #528.
Probably we should use something a bit smarter, and be able to work with as many source-urls as zef
. I'm not totally sure that zef
provides that service as a library, will need to investigate (or extract corresponding code).
For instance, it happened with Fcntl.
For some reason, source-urls that start with git:
are used throughout many modules, and they fail to install, as is shown here, for instance. We should check that when they are added to the ecosystem, at least those that are added here.
I shared a new module (System::DiskAndUpdatesAlerts) at
, but this module does not yet appear at modules.perl6.org.
Right now the
https://modules.perl6.org/update.log
has not been updated since Sun Aug 6 23:04:07 2017
Any ideas? Thanks.
The Travis CI script does not zef build
new modules before zef test
ing them. This can cause tests to fail. (For instance, see https://travis-ci.org/perl6/ecosystem/builds/472346894#L1435 where the file being used does not exist because it is normally generated in the build phase, which is skipped. Note that this issue is independent of any "hack" I mentioned in #422 corresponding to that build failure -- the missing file is a program needed by all tests of the module, because the module is an interface to that program.)
I use Build.pm, which is executed by zef build
, to generate resources
files. These files are needed for the module to function and to pass its tests. The Travis script skips the build phase between installing dependencies and testing the module:
my $zef = run "zef", "install", "--depsonly", "--/build", ".";
ok $zef.exitcode eq 0, "Able to install deps";
$zef = run "zef", "test", ".";
ok $zef.exitcode eq 0, "Package tests pass";
My understanding is that this is a legitimate use of Build.pm. zef
includes the build phase when you install a module.
It is not as easy as adding a zef build
invocation because that fails when no build file exists. I'm not sure how standardized the build procedure is. According to zef source the build file can be called Build.pm
or Build.pm6
and the whole thing is a giant ball of shit
.
The build failure linked in the first paragraph is from SAT::Solver::MiniSAT:
$ git clone https://github.com/taboege/p6-SAT-Solver-MiniSAT
$ cd p6-SAT-Solver-MiniSAT
What the Travis script does:
$ zef install --depsonly --/build .
All candidates are currently installed
$ zef test .
===> Testing: SAT::Solver::MiniSAT:ver<0.0.1>
# Failed test 'SAT::Solver::MiniSAT module can be use-d ok'
# at t/00-use.t line 8
# ===SORRY!=== Error while compiling /tmp/p6-SAT-Solver-MiniSAT/lib/SAT/Solver/MiniSAT.pm6 (SAT::Solver::MiniSAT)
# An exception occurred while evaluating a BEGIN
# at /tmp/p6-SAT-Solver-MiniSAT/lib/SAT/Solver/MiniSAT.pm6 (SAT::Solver::MiniSAT):35
# Exception details:
# Failed to find '/tmp/p6-SAT-Solver-MiniSAT/resources/minisat' while trying to do '.mode'
# in code at /tmp/p6-SAT-Solver-MiniSAT/lib/SAT/Solver/MiniSAT.pm6 (SAT::Solver::MiniSAT) line 35
# in code at /tmp/p6-SAT-Solver-MiniSAT/lib/SAT/Solver/MiniSAT.pm6 (SAT::Solver::MiniSAT) line 35
#
#
# Looks like you failed 1 test of 2
With zef build
:
$ zef install --depsonly --/build .
All candidates are currently installed
$ zef build .
# compilation noise from minisat...
$ zef test .
===> Testing: SAT::Solver::MiniSAT:ver<0.0.1>
===> Testing [OK] for SAT::Solver::MiniSAT:ver<0.0.1>
The Most Wanted Modules List needs a clean up.
Networking
and Data Formats
could be better placed in a Web Development
category.This is an RFC for adding Native dependency fields to META6.json.
This proposal is meant to hopefully be extensible, and be similar in character to how the metadata is already stored and laid out.
It is meant to be mostly distro neutral.
bin # meant to be findable in the path and be the name of the binary
lib # meant to be something such as a .so object
name # human readable name
A package manager could confirm that something is installed in a distro neutral way by checking the binary and lib paths.
Optionally you could also include package manager specific packaging names, and for Windows since the files may not be found in a binary or library path, the actual path of the installed program/lib could be given. The 'default' key is meant to be a default that should be attempted if the distros package manager is not listed. May want to use a different name for this, and more input on this because it's kind of ambiguous what it is the default of, though it was intended to be the default to check on a linux distribution, so the default option may not be good to include in the first specification for a native-dependencies standard.
Any comments on this proposal would be great. Me and @the-eater discussed it on IRC and hopefully we can get even more input on this from the community at large.
For packages for example python packages, that could be listed as the package manager being 'pip' or something akin to that and let the perl6 package manager even ask to install these dependencies. This would hopefully create a much better user experience ultimately, and in the more short term, let the package manager let the user know that the dependency may not be installed, and give them its name and other useful information.
"native-dependencies": [
{
"name": "curl",
"bin": [
"curl"
],
"lib": [
"libcurl"
],
"support": {
"site": "https://curl.haxx.se/"
},
"version": "4.0+",
"package-manager": {
"default": {
"curl": "*"
},
"apt": {
"curl": "4.0+"
}
},
"distribution": {
"windows": {
"location": {
"bin": {
"curl": [
"C://Program Files/curl/curl.exe"
]
},
"lib": {
"libcurl": [
"C://Program Files/curl/library/curl/curl32.dll"
]
}
See the full sample JSON file here:
https://gist.github.com/samcv/ed59c2bf070c3c544be25fe199f63881
I seem to have ended up one of my modules, Archive-SimpleZip, appearing twice in modules.perl6.org.
I suspect that this is because, until recently, I had the module registered via the p6c (using the instructions in Upload your module to p6c . I've subsequently uploaded the module to CPAN (Upload your module to CPAN).
Assuming that this issue is caused by a dual registration, I think there needs to be some documentation on how to get rid of the duplicate entry.
When there are entries to specific commits for a module in the META.list, the latest should be used for the url for that module in the generated modules list on modules.perl6.org.
If I got this right, someone uploading a distribution that provides Foo::Bar will name-clash with another distribution whose name is Foo:Bar or simply provides that module too. So we should issue a warning stating that fact, or maybe thrown an error.
Right now it's using rakudobrew, which is discouraged, and takes around 15 minutes to build. Using either docker containers (which can be tagged for versions) or @nxadm's distros would be infinitely faster, better, and also eating our own dog food.
This is the original PR. It's a matter of changing a couple of files in Ruby. I can do that.
I think that zef admits them, so this is probably a META6 issue, but I'll have to check if that's the case.
http://feather.perl6.nl:3000/projects.json returns no data
During recent install this message scrolled by:
*** The stability canary says: (nothing, it was driven away by harsh weather)
***
*** It seems you are running perl version 5.026000, likely the "official" or
*** "standard" version. While there is nothing wrong with doing that,
*** standard perl versions 5.022 and up are not supported by JSON::XS.
*** While this might be fatal, it might also be all right - if you run into
*** problems, you might want to downgrade your perl or switch to the
*** stability branch.
***
*** If everything works fine, you can ignore this message.
Just eliminate them in the test script.
https://raw.githubusercontent.com/perl6/ecosystem/master/META.list
Includes:
https://raw.githubusercontent.com/MARTIMM/unicode-precis/master/META.info
Which currently looks like this
{
"author": "Marcel Timmerman",
"authors": [
"Marcel Timmerman"
],
"depends": [
],
"description": "Implements PRECIS framework, rfc7564 and others. Obsoletes stringprep and saslprep",
"license": "The Artistic License 2.0",
"name": "Unicode::PRECIS",
"perl": "6.c",
"provides": {
"Unicode::PRECIS": "lib/Unicode/PRECIS.pm6",
"Unicode::PRECIS::FreeForm": "lib/Unicode/PRECIS/FreeForm.pm6",
"Unicode::PRECIS::FreeForm::OpaqueString": "lib/Unicode/PRECIS/FreeForm/OpaqueString.pm6",
"Unicode::PRECIS::Identifier": "lib/Unicode/PRECIS/Identifier.pm6",
"Unicode::PRECIS::Identifier::UsernameCaseMapped": "lib/Unicode/PRECIS/Identifier/UsernameCaseMapped.pm6",
"Unicode::PRECIS::Identifier::UsernameCasePreserved": "lib/Unicode/PRECIS/Identifier/UsernameCasePreserved.pm6",
"Unicode::PRECIS::Tables": "lib/Unicode/PRECIS/Tables.pm6"
},
"source-url": "git://github.com/MARTIMM/unicode-stringprep.git",
"version": "v0.3.0"
}
The _source-url_ is wrong and 404's - it would be nice for the system maintaining the master list to verify this sort of thing automatically.
I have a new module Physics::Unit and since https://docs.raku.org/language/modules say CPAN/PAUSE upload is preferred, I have done that already.
Should I ALSO do a pull request here to get my new module in the IRC and on the https://modules.raku.org listing??
There are currently two modules in the list:
For example, Cro::ZeroMQ depends on Net::ZMQ… although it's unclear which one. From what I understand, it is https://github.com/arnsholt/Net-ZMQ.
@GabrielaSH, @arnsholt can you please figure it out? Even if technically it might not be an issue, it confuses the hell out of me and I'm sure I'm not the only one.
Right now, zef takes whatever is in the URL pointed to by source-url, as far as I can tell. Distributions are not forced to release via tags, or to announce those releases via META.list. Besides, we don't check for changes in META6.json.
There should be a way of announcing or saying which version is the official. Just adding a version number that should correspond to a tag (and to the version in META6.json) should be enough. Besides, now "version squatting" is possible: just release a new distribution with a later version, and the ecosystem will get yours.
I am kind of aiming at CPANTS, but not only. A sweep and test of all distros would be nice, but as far as I can tell, this is what zef does; that's good and well, but it's not within the ecosystem, or available to the general public (or to other possible dependencies management tools)
The Module BSON is not shown in the modules list anymore at http://modules.perl6.org/
and I get the following error when installing MongoDB which depends on it
> panda install MongoDB
resolve stage failed for MongoDB: Dependency BSON is not present in the module ecosystem
...
I am now at the newest panda and perl6/moar version
https://travis-ci.org/perl6/form has never run even through it has .travis.yml
I have automated most of the pull requests below, to ones where it is indisputable what the License of the project was, either due there only being one LICENSE and it matching copies of those licenses almost exactly, or the metadata for license
key was set to something such as "The Artistic License 2.0" or the URL of the Artistic License or something ambiguous and able to be automated.
I am posting this here since I have finished the automated stage and going forward most of the rest will probably have to be checked manually to check what license they actually are (for those that have a LICENSE type file), or for those which don't opening an issue for the project.
Artistic-2.0
Though it is not yet in S22, the way to denote a dual license using the SPDX spec is as below:
Common with GPL licenses. Example: GPL-3.0+
. You can use a +
after the license name to denote this. The +
syntax is universal, and can technically be applied to any license, though in practice an "or later" clause is most often found in GPL (though please note GPL-3.0 means ONLY GPL-3.0, GPL-3.0 does not imply that you may use any later version).
Example using the licensing of the Perl 5 project, which is dual licensed under Artistic 1.0 as sourced from the Perl site and the GPL-1.0 (or greater):
Artistic-1.0-Perl OR GPL-1.0+
Detailed information about the ones which do not yet have Pull Requests can be seen in this JSON here:
https://gist.github.com/samcv/9177c43f2a78049248fcb954c63d28e5
Note: jonathanstowe has stated he would not like any PR regarding metadata to his projects
This list contains all non-standard identifiers, and a very small number which have no license at all (added manually and not computer generated like the non-standard identifier ones were).
Note repeated from above: jonathanstowe has stated he would not like any PR regarding metadata to his projects
See:
https://modules.raku.org/dist/Acme::ಠ_ಠ:cpan:ELIZABETH/lib/Acme/à²%C2%A0_à²%C2%A0.pm6
This page shows an empty code as if Acme::ಠ_ಠ.pm6 is empty.
There are Perl and Perl 6 modules, and it might get a bit confusing.
It's been requested for Bailador: Bailador/Bailador#28; maybe it would be nice to come up with some common README template that we can put in modules for people who found them somehow but have no idea how our Perl 6 ecosystem works.
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.