derive simple constructor functions for Rust structs
License: MIT License
🦍🦍🦍🦍🦍🦍🦍🦍🦍🦍
🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀
error[E0554]: #[feature] may not be used on the beta release channel
--> C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\derive-new-0.3.0\src\lib.rs:2:1
|
2 | #![feature(proc_macro, proc_macro_lib)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
A per-field attribute which allows using either default() or a given default expression as a value and not taking the value from an argument.
Currently it will generate false positives on cases like:
struct PhantomData;
#[derive(new)]
struct Foo { bar: PhantomData }and false negatives on cases like:
use std::marker::PhantomData as PD;
#[derive(new)]
struct Foo { bar: PD }In which we no longer need to include the source text in the output (i.e., the derive is a decorator, not a modifier).
It seems like name resolution for macros has changed on nightly 2019-11-17?
hoverbear@Obsidian:~/git/derive-new$ cargo +nightly-2019-11-17 test
Compiling derive-new v0.5.8 (/home/hoverbear/git/derive-new)
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:163:7
|
163 | #[new(default)]
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:161:10
|
161 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:166:7
|
166 | #[new(default)]
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:161:10
|
161 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:186:7
|
186 | #[new(value = "1 + 2")]
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:184:10
|
184 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:189:7
|
189 | #[new(value = "vec![-42, 42]")]
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:184:10
|
184 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:209:7
|
209 | #[new(value = r#""Thud".to_owned()"#)]
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:207:10
|
207 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:211:7
|
211 | #[new(default)]
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:207:10
|
207 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:249:7
|
249 | #[new(default)] pub i32,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:247:10
|
247 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:251:7
|
251 | #[new(default)] pub T,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:247:10
|
247 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:263:7
|
263 | #[new(value = "1 + 2")] pub i32,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:261:10
|
261 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:265:7
|
265 | #[new(value = "vec![-42, 42]")] pub Vec<i8>,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:261:10
|
261 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:277:7
|
277 | #[new(value = r#""Thud".to_owned()"#)] pub String,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:275:10
|
275 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:278:7
|
278 | #[new(default)] pub String,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:275:10
|
275 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:318:11
|
318 | #[new(value = "\"fascinating\".to_owned()")] String,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:314:10
|
314 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error[E0659]: `new` is ambiguous (derive helper attribute vs any other name)
--> tests/test.rs:319:11
|
319 | #[new(default)] T,
| ^^^ ambiguous name
|
note: `new` could refer to the derive helper attribute defined here
--> tests/test.rs:314:10
|
314 | #[derive(new, PartialEq, Debug)]
| ^^^
note: `new` could also refer to the derive macro imported here
--> tests/test.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
error: aborting due to 14 previous errors
For more information about this error, try `rustc --explain E0659`.
error: could not compile `derive-new`.
To learn more, run the command again with --verbose.Works on 2019-11-16:
hoverbear@Obsidian:~/git/derive-new$ cargo +nightly-2019-11-16 test
Finished test [unoptimized + debuginfo] target(s) in 0.04s
Running target/debug/deps/derive_new-2aab09fd7c964d03
running 1 test
test test_to_snake_case ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/debug/deps/test-a81e668b709555b1
running 18 tests
test test_empty_struct ... ok
test test_enum_unit_variants ... ok
test test_more_involved_enum ... ok
test test_simple_struct ... ok
test test_simple_tuple_struct ... ok
test test_struct_phantom_data ... ok
test test_struct_lifetime_bounds ... ok
test test_struct_mixed_defaults ... ok
test test_struct_with_bounds ... ok
test test_struct_with_defaults ... ok
test test_struct_with_lifetime ... ok
test test_struct_with_values ... ok
test test_tuple_mixed_defaults ... ok
test test_tuple_phantom_data ... ok
test test_tuple_struct_lifetime ... ok
test test_tuple_with_defaults ... ok
test test_tuple_with_values ... ok
test test_unit_struct ... ok
test result: ok. 18 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Doc-tests derive-new
running 5 tests
test src/lib.rs - (line 70) ... ok
test src/lib.rs - (line 24) ... ok
test src/lib.rs - (line 92) ... ok
test src/lib.rs - (line 50) ... ok
test src/lib.rs - (line 32) ... ok
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered outIs it possible to name the ctor differently than "new"?
I have several use cases where I use the derived new only internally in my real ctor that should be used by client code. The fact that derive-new names the ctor new means I can't use that name for my handwritten ctor, but I'd like to.
Could you add the feature to name it differently?
E.g. #[derive(new = "new_internal")]
Kindly requesting to release the latest changes on the main branch. In particular, this PR is missing from the published version 0.5.9.
The main reason why I am asking is because I have wasted several hours trying to track down which package has enabled "std" when in fact I want to disabled for no_std use case. Since features are additive, if any of dependency crates enable std, I cannot use no_std at the top level.
I am getting this type of error, for example:
error[E0433]: failed to resolve: could not find `std` in the list of imported crates
--> burn-core/src/record/tensor.rs:7:10
|
7 | #[derive(new, Clone, Debug)]
| ^^^ could not find `std` in the list of imported crates
|
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0433]: failed to resolve: could not find `std` in the list of imported crates
--> burn-core/src/record/tensor.rs:15:10
|
15 | #[derive(new, Clone, Debug)]
| ^^^ could not find `std` in the list of imported crates
|
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0433]: failed to resolve: could not find `std` in the list of imported crates
--> burn-core/src/record/memory.rs:17:10
|
17 | #[derive(new, Debug, Default, Clone)]
| ^^^ could not find `std` in the list of imported crates
|
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
While I see that derive-new can create a collection of constructors for enum variants, it would be convenient for enums that always have a single new constructor, like this:
#[derive(new)]
enum Foo {
#[new]
InitialState { data: String },
SecondState{ data: Vec<u8> }
}
// Produces:
fn new(data: String) -> Foo { Foo::InitialState{data}}
error: calls in constants are limited to constant functions, struct and enum constructors
How can I make the generated new() constructor const-fn?
E.g.:
#[derive(new, Copy, Clone)]
pub struct ColorHB {
hue: Hue,
#[new(value = "1.")]
brightness: f32,
}which seem to be broken: https://travis-ci.org/nrc/derive-new/jobs/261670920
Related: #29
This crate seems very useful to me, but unfortunately it provides no way to derive const constructors, and because of that I cannot use it for my project. I can't think why this wouldn't be the default, but nonetheless, an opt-in feature flag perhaps would be really helpful.
I would like to be able to use the constructors like so:
pub struct Atom(u32);
pub const PRIMARY: Atom = Atom::new(1);
pub const SECONDARY: Atom = Atom::new(2);
pub const ARC: Atom = Atom::new(3);
pub const ATOM: Atom = Atom::new(4);
pub const BITMAP: Atom = Atom::new(5);Where Atom is used in implementing a protocol that pre-defines these constants with the corresponding IDs. That means using a const fn like so:
impl Atom {
#[must_use]
pub const fn new(id: u32) -> Self {
Self(id)
}
}#[derive(new)]
pub struct P<'a> {
pub f: &'a Fn(f32) -> String,
}
/*
error: proc-macro derive panicked
= help: message: Couldn't parse item: "failed to parse macro input:
\"pub struct P<\\\'a> {\\n pub f: &\\\'a Fn(f32) -> String,\\n}\""
*/Another example:
#[derive(new)]
pub struct P<S: Fn(f32) -> String> {
pub f: S,
}
/*
error: proc-macro derive panicked
= help: message: Couldn't parse item: "failed to parse macro input:
\"pub struct P<S: Fn(f32) -> String> {\\n pub f: S,\\n}\""
*/Any reason this should fail with this function takes 1 argument but 0 arguments were supplied expected 1 argument
#[macro_use]
extern crate derive_new;
#[derive(new)]
struct StringStruct {
#[new(value = "mystring".to_string())]
x: String,
}
fn main() {
let my_struct = StringStruct::new();
}I want to create a Struct and assign it const to the fields (ie, API endpoints), but it doesn't make sense to pass it to ::new() as well instead of referring to them as self.api_url
I'm working on a project, that requires types to be transformed into an internal representation. Usually, this is done by calling .into() on the type. It would be awesome if the generated macro would support impl Into<FieldTy> parameters.
I imagine something like this:
#[derive(new)]
struct Foo {
#[new(into)]
x: u32,
}which would generate:
impl Foo {
fn new(x: impl Into<u32>) {
Foo {
x: x.into(),
}
}
}Today, #[derive(new)] always creates a pub fn, regardless of the visibility of the struct it's applied to.
In Rust 2018, that becomes a lint error, which makes it (at present) difficult to use this crate in a crate with #[warn(rust_2018_idioms)].
Instead, the visibility of the new method should be the same as the visibility of the struct.
It might also be useful to allow the visibility to be controlled directly. Straw man:
#[derive(new)]
#[new(visibility = crate)]
struct Point {
x: u32,
y: u32,
}xref: https://bugzilla.redhat.com/show_bug.cgi?id=1921853#c3
We're in the process of adding this project as a rust-package in Fedora to resolve one of the dependencies for building the rust-mbrman package. It would be helpful if someone from the maintainers could add a license file in the crate to resolve the fedora packaging standard issue.
/cc @nrc
If a struct has too many members, cargo clippy will complain that the ctor has too many parameters:
warning: this function has too many arguments (16/7), #[warn(too_many_arguments)] on by default
--> src\search.rs:10:37
|
10 | #[derive(Clone, Debug, Deserialize, new, getters)]
| ^^^
|
= help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#too_many_arguments
Emitting a #[cfg_attr(feature = "cargo-clippy", allow(too_many_arguments))] on the ctor should do it, I think.
There's some structures I'd like to use this with, but they require tiny adjustments to input arguments when storing them in the structure, such as subtracting 1 from an integer.
Readme says the dependency needs to be declared as derive-new = "0.3", however 0.4 is the current version.
$ cargo test
Compiling derive-new v0.5.9 (/Users/cjw/workspace/derive-new)
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:237:14
|
237 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:303:14
|
303 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:333:14
|
333 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:164:14
|
164 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this trait
|
6 | use std::default::Default;
|
help: if you import `Default`, refer to it directly
|
164 | #[derive(new, PartialEq, Debug)]
|
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:212:14
|
212 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this trait
|
6 | use std::default::Default;
|
help: if you import `Default`, refer to it directly
|
212 | #[derive(new, PartialEq, Debug)]
|
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:258:14
|
258 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this trait
|
6 | use std::default::Default;
|
help: if you import `Default`, refer to it directly
|
258 | #[derive(new, PartialEq, Debug)]
|
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:287:14
|
287 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this trait
|
6 | use std::default::Default;
|
help: if you import `Default`, refer to it directly
|
287 | #[derive(new, PartialEq, Debug)]
|
error[E0433]: failed to resolve: maybe a missing crate `core`?
--> tests/test.rs:333:14
|
333 | #[derive(new, PartialEq, Debug)]
| ^^^ maybe a missing crate `core`?
|
= help: consider adding `extern crate core` to use the `core` crate
= note: this error originates in the derive macro `new` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this trait
|
6 | use std::default::Default;
|
help: if you import `Default`, refer to it directly
|
333 | #[derive(new, PartialEq, Debug)]
|
For more information about this error, try `rustc --explain E0433`.
error: could not compile `derive-new` due to 8 previous errors
Using derive-new 0.5.1 got the following error
error: proc-macro derive panicked
|
40 | #[derive(new, Serialize, Debug)]
| ^^^
|
= help: message: Invalid #[new] attribute: #[new(skip_serializing_if = ..)]
Struct definition:
#[derive(new, Serialize, Debug)]
pub struct SendMessageData<'a> {
pub chat_id: i64,
pub text: &'a str,
pub parse_mode: &'a str,
#[serde(skip_serializing_if = "Option::is_none")]
pub reply_markup: Option<InlineKeyboardMarkup<'a>>
}It would be nice if examples like this could be handled automatically if it's even possible:
#[derive(new)]
pub struct Foo<T> {
x: u32,
p: PhantomData<T>,
}
let foo = Foo::<u32>::new(42); // currently an error since it expects two parametersI'd be nice to have 'init-only' fields, so you can use them in field initialization:
#[derive(new)]
struct Test
{
#[new(init)] // <---
active: bool,
#[new(value = "Other::new(active)")]
other: Other
}Like https://docs.python.org/3/library/dataclasses.html#init-only-variables
I don't think I'd add too much complexity and I'd be really useful. The workaround for this is to declare the init-field after 'other' and to store it in the struct, which also forces a copy if the initialized class takes the parameter by value.
It could add #[allow(missing_docs)] on the generated impl.
Or it could unilaterally add a generic doc comment /// Constructs a #struct_name (not sure if quote supports this).
The docs say that
[OclPrm] Can also be implemented for custom types as long as layout and alignment are conserved between Rust and OpenCL (repr “C”).
I spend quite some time chasing a bug caused by assuming this is always true. I'm not sure if this is due to some edge case in my structs or my driver (M1 MacBook) or if this simply always the case.
I have two (assumed to be) identical structs declared in OpenCl and in Rust. The one in OpenCL C has a sizeof 48 and the one in Rust has size_of 36:
struct Light {
float3 pos;
float3 color;
float intensity;
};
// sizeof(struct Light) is 48use ocl::{prm::Float3, OclPrm};
#[repr(C)]
#[derive(Debug, PartialEq, Default, Clone, Copy, new)]
pub struct Light {
pub pos: Float3,
pub color: Float3,
pub intensity: f32,
}
unsafe impl OclPrm for Light {}
// std::mem::size_of::<Light>() is 36This causes all kinds of issues.
Including this error when using Buffer::builder().len(1).fill_val(Light::default()):
Error executing function: clEnqueueFillBuffer
Status error code: CL_INVALID_VALUE (-30)
I assume there isn't much this crate can do about this but maybe it's possible to add a note about this to the docs.
Platform { Profile: Ok(FULL_PROFILE), Version: Ok(OpenCL 1.2 (Apr 19 2022 18:44:44)), Name: Ok(Apple), Vendor: Ok(Apple), Extensions: Ok(cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event) } { Total Device Count: 1 }
I tried to use #[derive(new)] on ArmWrapper in this PR. Unfortunately I got the following error:
Compiling rustfmt-nightly v0.4.0 (file:///home/topecongiro/workspace/rustfmt)
error: proc-macro derive panicked
--> src/expr.rs:1264:10
|
1264 | #[derive(new)]
| ^^^
|
= help: message: Invalid #[new] attribute, expected #[new(..)]
error: Could not compile `rustfmt-nightly`.
To learn more, run the command again with --verbose.
A difinition of ArmWrapper:
/// A simple wrapper type against ast::Arm. Used inside write_list().
#[derive(new)]
struct ArmWrapper<'a> {
pub arm: &'a ast::Arm,
/// True if the arm is the last one in match expression. Used to decide on whether we should add
/// trailing comma to the match arm when `config.trailing_comma() == Never`.
pub is_last: bool,
/// Holds a byte position of `|` at the beginning of the arm pattern, if available.
pub beginning_vert: Option<BytePos>,
}I am using derive-new 0.5.1.
With variants A and B we should make new_a and new_b constructors taking the appropriate args.
Hi!
I tried to use this crate, and I noticed that the version uploaded on crates.io does not support enums.
I think that the problem is that you did not bump the version of the crate after adding enum support (look at the history of Cargo.toml).
I think you should increment the version to 0.4.1 and issue a cargo publish.
Thanks for this useful crate, btw!
Many times I have MyStruct::new("something".into()). I would rather not keep typing into(). Perhaps there is a way that new can take an Into.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.