ipfs / js-ipfs-bitswap Goto Github PK
View Code? Open in Web Editor NEWJavaScript implementation of Bitswap 'data exchange' protocol used by IPFS
License: Other
JavaScript implementation of Bitswap 'data exchange' protocol used by IPFS
License: Other
Avoid using: https://github.com/ipfs/js-ipfs-bitswap/blob/master/package.json#L45
Context: libp2p/js-libp2p#92
Branch | Build failing π¨ |
---|---|
Dependency | multiaddr |
Current Version | 2.2.3 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As multiaddr is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 3 commits .
1ff2328
chore: release version v2.3.0
d0b6174
chore: update contributors
ec23f14
feat: don't throw on invalid b58 string in getPeerId (#43)
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Currently, in peer-crdt, the latency of replication of logs is bound to the latency of getMany(cids)
when the blocks are not present.
Also, I think we should create benchmarks to have a baseline we can try to improve on.
Fire N number of nodes and connect all of them together
Uncaught TypeError: Big is not a function
at Stats.initialCounters.forEach (stat.js?ce0f:22)
This happens because Big.js uses now default export.
Branch | Build failing π¨ |
---|---|
Dependency | peer-book |
Current Version | 0.3.0 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As peer-book is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
As per ipfs/team-mgmt#600, please list yourself as the Lead Maintainer
Branch | Build failing π¨ |
---|---|
Dependency | libp2p-ipfs-nodejs |
Current Version | 0.17.8 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As libp2p-ipfs-nodejs is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 4 commits .
6d1aefb
chore: release version v0.17.9
775db4c
chore: update contributors
2862e35
Merge pull request #64 from ipfs/feat/option-bootstrap
179021f
feat: enable bootstrap to be an option
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Documenting things here.
Branch | Build failing π¨ |
---|---|
Dependency | async |
Current Version | 2.1.4 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
As async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you itβs very likely also breaking them.
I recommend you give this issue a very high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | libp2p-ipfs-nodejs |
Current Version | 0.17.9 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As libp2p-ipfs-nodejs is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | ipfs-repo |
Current Version | 0.11.2 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As ipfs-repo is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 4 commits .
ea308a8
chore: release version v0.11.3
96c94a1
chore: update contributors
c5162af
chore: ^ to ~
0f0d686
feat: change window to self for webworker support
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
maciej@mkg-lenovo:~/js-ipfs-bitswap$ xvfb-run npm test
> [email protected] test /home/maciej/js-ipfs-bitswap
> aegir test -t node -t browser
Test Node.js
bitswap without DHT
β connect 0 -> 1 && 1 -> 2 (89ms)
β put a block in 2, fail to get it in 0 (220ms)
bitswap with DHT
β connect 0 -> 1 && 1 -> 2 (45ms)
β put a block in 2, get it in 0 (1461ms)
bitswap with mocks
receive message
β simple block message
β simple want message
β multi peer (23513ms)
get
β fails on requesting empty block
β block exists locally
β blocks exist locally
β getMany
β block is added locally afterwards (216ms)
β block is sent after local add (1145ms)
β double get
unwant
β removes blocks that are wanted multiple times
bitswap stats
β has initial stats
β updates blocks received (508ms)
β updates duplicate blocks counters (499ms)
connected to another bitswap
β updates stats on transfer (1035ms)
β has peer stats (359ms)
Engine
β consistent accounting (623ms)
β peer is added to peers when message receiver or sent (1050ms)
β partner wants then cancels (14285ms)
β splits large block messages (896ms)
network
β instantiate the network obj
β connectTo fail
β onPeerConnected success (195ms)
β connectTo success
β ._receiveMessage success from Bitswap 1.0.0 (234ms)
β ._receiveMessage success from Bitswap 1.1.0 (232ms)
β .sendMessage on Bitswap 1.1.0 (235ms)
β dial to peer on Bitswap 1.0.0 (197ms)
β .sendMessage on Bitswap 1.1.0 (324ms)
gen Bitswap network
β retrieves local blocks (2835ms)
distributed blocks
time -- 801
β with 2 nodes (11191ms)
swarms
- 2 nodes, 2 blocks
- 10 nodes, 2 blocks
- 10 nodes, 10 blocks
- 10 nodes, 20 blocks
- 50 nodes, 2 blocks
- 100 nodes, 2 blocks
- 10 nodes, 100 blocks
Ledger
β accounts
Notifications
β hasBlock
wantBlock
β receive block
β unwant block
BitswapMessage
β .addEntry - want block
β .serializeToBitswap100
β .serializeToBitswap110
β .deserialize a Bitswap100 Message
β .deserialize a Bitswap110 Message
β duplicates
β .empty
β non full wantlist message
.equals
β true, same message
β false, different entries
BitswapMessageEntry
β exposes the wantlist entry properties
β allows setting properties on the wantlist entry
go interop
β bitswap 1.0.0 message
bitswap 1.1.0 message
- full wantlist message
- one block message
Wantlist
β length
β entries
β sortedEntries
β contains
β with cidV1
remove
β removes with a single ref
β removes with multiple refs
β ignores non existing removes
WantManager
β sends wantlist to all connected peers (10254ms)
MessageQueue
β connects and sends messages (205ms)
62 passing (1m)
9 pending
Test Browser
bitswap with mocks
1) "before all" hook
2) "after all" hook
Engine
3) consistent accounting
4) peer is added to peers when message receiver or sent
5) partner wants then cancels
6) splits large block messages
Ledger
β accounts (2ms)
Notifications
β hasBlock (2ms)
wantBlock
β receive block (3ms)
β unwant block
BitswapMessage
β .addEntry - want block (3ms)
β .serializeToBitswap100 (1ms)
β .serializeToBitswap110
β .deserialize a Bitswap100 Message (5ms)
β .deserialize a Bitswap110 Message (4ms)
β duplicates
β .empty
β non full wantlist message
.equals
β true, same message (2ms)
β false, different entries
BitswapMessageEntry
β exposes the wantlist entry properties
β allows setting properties on the wantlist entry (1ms)
go interop
β bitswap 1.0.0 message (2ms)
bitswap 1.1.0 message
- full wantlist message
- one block message
Wantlist
β length
β entries
β sortedEntries (3ms)
β contains
β with cidV1 (3ms)
remove
β removes with a single ref (1ms)
β removes with multiple refs
β ignores non existing removes
WantManager
β sends wantlist to all connected peers (965ms)
MessageQueue
β connects and sends messages (207ms)
27 passing (12s)
2 pending
6 failing
1) bitswap with mocks
"before all" hook:
WriteError: QuotaExceededError
at node_modules/aegir/src/config/karma-webpack-bundle.js:120213:34
at IDBTransaction.tx.onabort (node_modules/aegir/src/config/karma-webpack-bundle.js:37284:5)
2) bitswap with mocks
"after all" hook:
TypeError: Cannot read property 'teardown' of undefined
at Context.after (node_modules/aegir/src/config/karma-webpack-bundle.js:68644:10)
3) Engine
consistent accounting:
Error: Uncaught AssertionError: expected {} to not exist (node_modules/aegir/src/config/karma-webpack-bundle.js:72269)
4) Engine
peer is added to peers when message receiver or sent:
Error: Uncaught AssertionError: expected {} to not exist (node_modules/aegir/src/config/karma-webpack-bundle.js:72269)
5) Engine
partner wants then cancels:
Error: Uncaught AssertionError: expected {} to not exist (node_modules/aegir/src/config/karma-webpack-bundle.js:72269)
6) Engine
splits large block messages:
Error: Uncaught AssertionError: expected {} to not exist (node_modules/aegir/src/config/karma-webpack-bundle.js:72269)
Some tests are failing
Error: Some tests are failing
at Server (/home/maciej/js-ipfs-bitswap/node_modules/aegir/src/test/browser.js:12:16)
at removeAllListeners (/home/maciej/js-ipfs-bitswap/node_modules/karma/lib/server.js:380:7)
at Server.<anonymous> (/home/maciej/js-ipfs-bitswap/node_modules/karma/lib/server.js:391:9)
at Object.onceWrapper (events.js:313:30)
at emitNone (events.js:111:20)
at Server.emit (events.js:208:7)
at emitCloseNT (net.js:1671:8)
at _combinedTickCallback (internal/process/next_tick.js:135:11)
at process._tickCallback (internal/process/next_tick.js:180:9)
npm ERR! Test failed. See above for more details.
Branch | Build failing π¨ |
---|---|
Dependency | cids |
Current Version | 0.4.0 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
As cids is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you itβs very likely also breaking them.
I recommend you give this issue a very high priority. Iβm sure you can resolve this πͺ
The new version differs by 5 commits .
1a8e4e5
chore: release version v0.4.1
aa43141
chore: update contributors
dceaaee
chore: ^ to ~
401ee20
Merge pull request #18 from ipld/greenkeeper/multihashing-async-0.4.0
97c461f
chore(package): update multihashing-async to version 0.4.0
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | debug |
Current Version | 2.6.1 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
As debug is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you itβs very likely also breaking them.
I recommend you give this issue a very high priority. Iβm sure you can resolve this πͺ
The new version differs by 7 commits .
017a9d6
release 2.6.2
23bc780
fix DEBUG_MAX_ARRAY_LENGTH
065cbfb
Add backers and sponsors from Open Collective (#422)
918d686
Revert "add Slackin invite badge"
f46d671
add Slackin invite badge
580a7a1
changed slackin url
9f33c9a
added slackin
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
As noted in #76 (comment)
I don't see any code to coalesce messages in the messages queues, which means the more peers we have, the more buffering it will happen, to the point where the message to reset the wantlist might be added even before the previous having been sent and nothing is clearing the message queue.
This will improve performance and reduce the memory usage by a lot
Branch | Build failing π¨ |
---|---|
Dependency | libp2p-ipfs-nodejs |
Current Version | 0.21.0 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As libp2p-ipfs-nodejs is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 4 commits .
b6daf27
chore: release version v0.21.1
35aa9d5
chore: update contributors
833ec65
[wip] swarm parallel (#88)
717b337
chore: update deps
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | multiaddr |
Current Version | 2.2.0 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As multiaddr is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 3 commits .
66eac24
chore: release version v2.2.1
b6cef3d
chore: update contributors
4a97f09
chore: update aegir
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | libp2p-ipfs-nodejs |
Current Version | 0.18.1 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As libp2p-ipfs-nodejs is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 3 commits .
cab089a
chore: release version v0.18.2
1b88e98
chore: update contributors
d17a5f1
chore: update deps
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
We don't use it that much and it brings in 127.8 KB
of size into the bundle.
Ref: #76
Why have two classes for WantListEntry? The BitSwapMessage Entry only has one more property cancel, can't we just extend the other and add that property?
Branch | Build failing π¨ |
---|---|
Dependency | peer-id |
Current Version | 0.8.1 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As peer-id is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
I've asked this in this issue #76
Congratulations on having the top result at duckduckgo.com query: bitswap protocol
.. Can you add a link to the main page to help users find more high level docs on the topic? tq
Hey @dignifiedquire i have some questions re impl. Forgive silliness, first time i look at it.
provierRequestTimeout
spelling - https://github.com/ipfs/js-ipfs-bitswap/blob/master/src/constants.js#L7parallel
and each
=> run-parallel
series
and eachSeries
=> run-series
parallelLimit
and eachLimit
=> run-parallelLimit
setImmediate
=> global.setImmediate
(shimmed through core-js already)queue
=> need more researchAs asked here: #76
Is a MessageQueue per peer the best approach? Why not piggyback on want list updates and just check what the peer wants and attach the blocks necessary?
It might be tad expensive to have a message queue for each peer, especially with a lot of Peer Churn
Branch | Build failing π¨ |
---|---|
Dependency | peer-info |
Current Version | 0.8.4 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As peer-info is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 5 commits .
21700b8
chore: release version v0.8.5
2f2a9ff
chore: update contributors
3b6b3b0
chore: update deps
40c75b1
isPeerInfo (#48)
186774d
chore: update deps
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
I feel that it requires a huge cognitive investment to dial into bitswap, before #76 there was not documentation making it hard to understand what is what. Also, there are a lot of design decisions that simply aren't clear from reading the code and once you start describing them, you realise that it can be so much more improved (as also noted in #76).
I would like for bitswap to reach a state where it is just obvious to understand how it works, how to improve it and how to use different bitswap strategies. I know there is some interest in the community to experiment with variations of bitswap.
I know this is a very abstract request, but there are some action items that we can start with:
Branch | Build failing π¨ |
---|---|
Dependency | ipfs-block |
Current Version | 0.5.4 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
As ipfs-block is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you itβs very likely also breaking them.
I recommend you give this issue a very high priority. Iβm sure you can resolve this πͺ
The new version differs by 5 commits .
e05695f
chore: release version v0.5.5
d7c1d17
chore: update contributors
5daf7c6
chore: ^ to ~
18a7d28
fix(package): update multihashing-async to version 0.4.0 (#27)
ca1db3b
docs(api): add it
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | async |
Current Version | 2.2.0 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
As async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you itβs very likely also breaking them.
I recommend you give this issue a very high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
I think we should define some performance requirements for bitswap (like, for example: "for 10 bitswaps exchanging 1000 blocks between themselves, they must execute this in X seconds or less"), and then apply these to the already existing test/benchmarks
.
This is almost done (test/benchmarks
already can be parametrised to spawn a network of x nodes exchanging y blocks), so I think this is just a matter of defining the baseline to:
a) prevent performance regressions
b) incorporate improvements
@victorbjelkholm @vmx Thoughts on this?
Branch | Build failing π¨ |
---|---|
Dependency | peer-book |
Current Version | 0.3.1 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As peer-book is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | benchmark |
Current Version | 2.1.3 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As benchmark is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | multihashing-async |
Current Version | 0.4.4 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
As multihashing-async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you itβs very likely also breaking them.
I recommend you give this issue a very high priority. Iβm sure you can resolve this πͺ
The new version differs by 5 commits .
8ebf348
chore: release version v0.4.5
6f10df7
chore: update contributors
c3ea0b8
chore: update deps
3efb676
murmur3 should output 128 bit instead of 32 (#21)
71aa4d3
chore: use dirty-chai
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
stats (exchanged byteCount and so on) kind of don't have any self-guards to overflowing
I believe that we should have a way for stats to be disabled and at the same time, make it so they are updated asynchronously, these are just shared values that are mutated with incrementations, which makes it very safe to defer.
Another things is to use a bignum library, otherwise it will get weird in long-running nodes.
We want all these tests ported: https://github.com/ipfs/go-ipfs/blob/master/exchange/bitswap/bitswap_test.go
Depends on #8
go-ipfs seams to rebroadcast the want list on a fixed interval.
In JS, there is a rebroadcastDelay
defined in src/constants.js
, but it's not being used.
Should we implement a rebroadcast?
If all the changes in the waitlist get broadcasted, why would a node get out of sync (unless the transport is somehow unreliable, which would be a more troubling issue...)?
@whyrusleeping do you have any insight on this?
Due to CI being suuuper slow the browser tests time out while cleaning up databases. Resulting in a browser restart, making CI report red :( .Need to figure out how to fix this :(
We need these stats per peer because of ipfs-inactive/dynamic-data-and-capabilities#3 and ipfs/js-ipfs#1198.
As noted in: #76
The decision engine buffers the blocks in memory when it informs the message queue that there is one more block to send, this means that if thousands of transfers are being performed, every block will stay in memory till the message gets sent. A better approach would be to only read from disk when the message is going to be sent.
With this, we might loose some perf by having to go read from disk, but that is why I created this issue ipfs/js-ipfs-repo#110 to add a LRU cache on the repo.
Ref ipfs/kubo#3182
Hey @diasdavid and the IPFS team, I'm building something that requires getting a notification from bitswap._notification
and noticed that it doesn't have more generic events, events are triggered with a string that includes the block.cid
usually. so creating a listener that listens to all block:*
isn't that straightforward.
What if instead of using something like eventemitter2
that adds wildcard and other functionalities , we can just trigger a more generic event like so
// current implementation (notification.js)
hasBlock (block) {
const str = `block:${block.cid.buffer.toString()}`
this._log(str)
this.emit(str, block)
}
// proposed change
hasBlock (block) {
const str = `block:${block.cid.buffer.toString()}`
this._log(str)
this.emit(str, block)
// generic event
this.emit('block', block)
}
What do you think?? Is this something you'd be interested in adding or not?
Branch | Build failing π¨ |
---|---|
Dependency | multiaddr |
Current Version | 2.2.2 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As multiaddr is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 5 commits .
d632745
chore: release version v2.2.3
1939b35
chore: update contributors
cbfcbdb
chore: update deps
08d5d5d
[WIP] feat: adding p2p-circuit proto (#41)
e7e53b9
test: use dirty-chai
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency | aegir |
Current Version | 11.0.0 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As aegir is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
The new version differs by 4 commits .
1b9c612
chore: release version v11.0.1
2ebaf98
chore: update contributors
dfa06cc
chore: update yarn.lock
e82ae5f
fix(config): update webpack.js to be compatible with [email protected]
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Need to
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.