Git Product home page Git Product logo

fslang-design's Introduction

The F# repository has moved

Please go to https://github.com/dotnet/fsharp/. All contributions to the F# compiler/library/tools now go there.

This repository is the old repository for alternative packagings of F#. See notes below for historical notes on these. The core logic of F# is made available as a library component called FSharp.Compiler.Service, and F# is open source, so an unlimited number of other packagings of F# are possible.

Archival: Details on the various Alternative Packagings

Archival: The FSharp.Compiler.Tools NuGet package

This repo is currently used to make the FSharp.Compiler.Tools NuGet package. This package includes the following for both .NET Core and .NET Framework/Mono:

  • the F# compiler fsc.exe
  • F# Interactive fsi.exe
  • build support,
  • a copy of FSharp.Core used to run the tools
  • related DLLs.

The NuGet packages are exactly the ones produced by AppVeyor CI, e.g. for version 4.1.2. They are pushed to https://nuget.org by someone with appropriate permissions.

The FSharp.Compiler.Tools NuGet package can be used if you wish to use the latest F# compiler on a computer without relying on the installed version of Visual Studio. Adding it via NuGet to a project will override the in-box compiler with the compiler from the NuGet package. Note: you will need to manually modify your project file once (see #676).

Archival: The fsharp Debian Linux Package

Usage: See http://fsharp.org/use/linux

apt-get install fsharp

See the mono packaging repo, which is a downstream variant of this repo, where this package is actually made.

  • There is a tag for each upstream source tag
  • There is a tag for each "debianized" package
  • Packaging metadata lives in debian/
  • install files are files installed to disk
  • cligacinstall are GAC-installed libraries
  • control is the manifest of packages
  • rules is the Makefile which handles build/install.

Jo Shields (@directhex) has done much of this work and says:

I tend to only update the published packages when a) the same update has already been pulled in on Mac by Jason, and either b) something breaks horribly in the existing version on a new Mono, or c) someone explicitly asks me to.

Linux package delivery is (now) based on packages built on our public Jenkins instance, and published automatically as a post-build step, based on two inputs - a Git repository in standard Debian git packaging format (which https://github.com/mono/linux-packaging-fsharp already is), and a tarball to consider as the canonical source of the next release (giving the same tarball in subsequent builds is how you indicate packaging-only changes such as alterations to metadata in debian/)

Alexander Köplinger has admin access to Jenkins, SSH access to the Jenkins and repository servers, and has taken care of things for me in my absence in the past (but isn't a Debian packaging expert, so would be trusting that metadata changes are solid)

Archival: F# packaging in Mono + macOS

F# is packaged as part of Mono on macOS. Jason Imison says:

We use a system called BockBuild that pushes versions of F# (sometimes with patches) out with Mono for macOS (F# is bundled with mono here, not a separate package).

You can see an example build script here (if you have access, ping me if not) https://github.com/xamarin/bockbuild/blob/2017-02/packages/fsharp.py. Unfortunately, you need to know the branch name here – 2017-02 is what is going to be released with VS for Mac aka Mono 4.9.x

We build fsharp/fsharp internally so that we’re not dependent on you pushing out fixes / bumping packages. Miguel de Icaza likes to ‘own’ the code that we ship precisely to stop these kind of emergency issues.

@cartermp says:

For future reference, dependencies and code for the F# editing and F# Interactive support in Visual Studio for Mac/Xamarin Studio is here

Archival: History

See https://fsharp.org/history

F# compiler sources as initially dropped are available from fsharppowerpack.codeplex.com.

On 4 April 2014, Microsoft Open Tech published the F# compiler sources at http://visualfsharp.codeplex.com and began accepting contributions to the F# compiler/library and tools.

In 2016 the http://visualfsharp.codeplex.com repo moved to GitHub at https://github.com/Microsoft/visualfsharp.

In 2019 the .NET Foundation and the F# community unified repositories at https://github.com/dotnet/fsharp.

fslang-design's People

Contributors

0x53a avatar 7sharp9 avatar aviavni avatar baronfel avatar cartermp avatar charlesroddie avatar dsyme avatar edgarfgp avatar enricosada avatar forki avatar gusty avatar happypig375 avatar jwosty avatar kevinransom avatar kurtschelfthout avatar latkin avatar liboz avatar mexx avatar nelson-wu avatar neoeinstein avatar onurgumus avatar patrickmcdonald avatar pblasucci avatar saul avatar smoothdeveloper avatar swoorup avatar tarmil avatar tihan avatar vzarytovskii avatar whiteblackgoose avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fslang-design's Issues

Is adding more RFC's helpful?

Would be happy to send a few more PR's for approved uservoice items (a bit hard to see which ones still need to be added though).

Is this seen as helpful or does it just create admin overhead? If helpful, any in particular you would like to see?

Struct Union Compilation Failure

When attempting to compile a struct union with 2 cases in which the cases have the same arity and field types it fails with 'error: Error in pass2 for type TestUnion, error: duplicate entry '.ctor' in method table'.

I believe it is trying to compile a type with the following ctors ():
TestUnion(x : int, tag : int)
and
TestUnion(y : int, tag : int)

Instead these constructors should be combined something as follows, to illustrate the logic :

TestUnion(value : int, tag : int) =
    _tag <- tag
    // Assign correct field based on tag
    if tag = 0 then _x <- value else _y <- value

FSharp.Core planning note

The visualfsharp repo has a couple of pull requests for FSharp.Core. Before pulling these we wanted to pause for a moment and look at where we are with planning future additions, and get full community visibility and input on next steps.

Please discuss. Relevant resources are:

Proposal: 4.4.3.0 tactical release

It is proposed by @KevinRansom that we do a version 4.4.3.0 tactical release of FSharp.Core with at least the two PRs:

This seems reasonable. @KevinRansom would also like to publish incremental updates more frequently in the future (Again reasonable).

On the Slate

  1. The top actionable requests are

    a. add “task { … }”
    b. add more immutable collections
    c. improve interoperability with C#

  2. Additional approved items of note:

    a. string module enhancements
    a. Deprecate the default definition of (!) and ask users to use .Value instead or use a compat module
    b. Seq/Array/List.transpose

New requests:

Noting these requests not yet tracked by suggestions:

  1. Result module of useful functions
  2. option { … } and result { … } computation expressions
  3. AsyncResultCell (“TaskCompletionSource but for Async”)

Simplest Template for: F# RFC FS-1032 - Support for F# in the dotnet sdk

https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1002-fsharp-in-dotnet-sdk.md

The basic template for a console app looks like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
</Project>

Modify the TargetFramework tag to deal with different frameworks:
valid values include but are not limited to:

netcoreapp1.0
netstandard1.6
net45
net46
net461
net47

TargetFrameworks
The dotnetsdk allows a project to produce multiple targets use the target frameworks tag

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net45;net46;net461;net462;netcoreapp1.0;netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
</Project>

Notes:
Portable Libraries: TBD:
currently the SDK doesn't support portable library targets. Use the legacy project format for these.
Really unfortunately in FSharp.Core we rely on some APIs that require high versions of netstandard (1.6) -- so we will probably have to produce a new netstandard version of FSharp.Core for portability ... probably netstandard 1.3.

System.ValueTuple Reference
It is not necessary to include System.ValueTuple reference. Thje reason is that a package reference is automagically added during the build.

This is valuable because System.ValueTuple is kind of confusing ...

You need to reference it for net45,net46, net461, net462, net47 and coreapp1.+ and netstandard 1.6. You don't need to reference it for net471 and up or netcoreapp 2.+ or netstandard2.+.

net47 is the most vexing, because the full desktop framework contains the type but the reference assemblies do not contain the type forward.

DisableImplicitSystemValueTupleReference
To disable this, because ... reasons ...
Use the DisableImplicitSystemValueTupleReference property [true or false]

FSharp.Core reference
When building coreclr the framework automagically references the FSharp.Core using a wild card
Currently:
1.0.0-*
Once we have a netcore2.0 fsharp.core package it will likely change to 1.0.0-* for netcoreapp1.+ and netstandard1+ and 2.0.0-* for netcoreapp2+ etc.

DisableImplicitFSharpCoreReference
To disable automagic fsharp.core reference use the DisableImplicitFSharpCoreReference property [true or false]

FSharpCoreImplicitPackageVersion
To change the package version set: the FSharpCoreImplicitPackageVersion to a specific value.

TargetFSharpCorePackageIdentity
To use a different nuget package for FSharp.Core.dll use the TargetFSharpCorePackageIdentity property.

TargetFSharpCoreVersion
For desktop versions, E.g. those who want to target FSharp.Core.4.3.0.0 e.t.c use the TargetFSharpCoreVersion property. This has no effect on netstandard or netcoreapp target builds.

These proposals are implemented within the VisualFSharp repo in targets we deploy with the compiler, and so will not require coordination with the cli or sdk to implement.

The source files can be found here: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Build/Microsoft.FSharp.NetSdk.props
and here: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Build/Microsoft.FSharp.NetSdk.targets

A console app targeting multiple frameworks and the 4.4.0.0 fsharp.core

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net45;net46;net461;net462;net47</TargetFramework>
    <TargetFSharpCoreVersion>4.4.0.0</TargetFSharpCoreVersion>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
</Project>
C:\temp\fsharp.builtin>dotnet restore
  Restoring packages for C:\temp\fsharp.builtin\fsharp.builtin.fsproj...
  Generating MSBuild file C:\temp\fsharp.builtin\obj\fsharp.builtin.fsproj.nuget.g.props.
  Generating MSBuild file C:\temp\fsharp.builtin\obj\fsharp.builtin.fsproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\temp\fsharp.builtin\obj\project.assets.json
  Restore completed in 295.17 ms for C:\temp\fsharp.builtin\fsharp.builtin.fsproj.

  NuGet Config files used:
      C:\temp\fsharp.builtin\NuGet.Config
      C:\Users\kevinr\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
      https://api.nuget.org/v3/index.json
      C:\Users\kevinr\.dotnet\NuGetFallbackFolder
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

C:\temp\fsharp.builtin>dotnet build
Microsoft (R) Build Engine version 15.3.117.23532
Copyright (C) Microsoft Corporation. All rights reserved.

  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net45\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net46\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net461\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net47\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net462\fsharp.builtin.exe

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:09.58

C:\temp\fsharp.builtin>

I hope this is satisfactory

Kevin

Schedule a recurring lang design meeting

I think it's a good idea to have a scheduled recurring ( once a month? every two weeks? weekly? ) meeting to discuss about current proposals status and create actionable items like new pr or issues.
This should help to make the lang design and implementation more fluid and constant
That's not a way to rush lang implementation

The meeting should focus on one or two proposals at most. That mean new proposals and/or status of current proposal implementation (maybe an implementation pr got stuck with open issues who need answers)

The meeting agenda ( the lang proposals and pr ) should be annunced at least a week before to make it easier for everyone to join meeting prepared for the discussion

In each meeting the owner ( @dsyme obv ) should explain open points of one or two proposals and everyone can propose to:

  • make prototype implementation
  • new questions
  • answers current questions

After each meeting, discussed issues should be labelled with current status and the markdown document about the feature should be updated with accepted changes/questions, so there is a spec and changelog.

We should take notes about the meeting's discussion/actionable items/feedback (like https://github.com/rust-lang/meeting-minutes or https://github.com/dotnet/apireviews )

When i say meeting, i dont mean a long open ended discussion.
I mean a focused discussion on one/two items where everyone know the discussed items and rules. People should come prepared with gist/pr if possibile, to speedup discussion.
Discussion of other issues should not be possible. A facilitator should try to make the meeting short and focused.

[Design] countWhere

There is a suggestion that the F# library functions need a counting function with signature

('T -> bool) -> C<'T> -> int

which counts the number of elements satisfying a signature. It seems the natural name would be countWhere

countWhere: ('T -> bool) -> C<'T> -> int

This has a more efficient fused implementation than "filter" + "count".

I understand the usefulness of the functionThe biggest criticism would be that there are many other fused implementations which would also have efficient implementations, e.g. averageWhere, maxWhere, sumWhere, sumByWhere, countByWhere etc. Essentially every function in the library can be qualified by a "Where".

Thoughts?

Thanks
Don

[Design] chunkBy

This is an adhoc location for a recorded discussion of adding "chunkBy" to Seq/Array/List modules in F# 4.0 - See

Signatures:

Seq.chunkBy : ('T -> 'Key) -> seq<'T> -> seq<seq<'Key * 'T>>
List.chunkBy : ('T -> 'Key) -> 'T list -> ('Key * 'T list) list
Array.chunkBy : ('T -> 'Key) -> 'T[] -> ('Key * 'T[]) []

where elements are repeatedly collected into one chunk until the key changes, left to right. This has been a commonly requested function.

An implementation would of course be needed, with performance checks.

Please use this thread to discuss, e.g.

  • comment on proposed name
  • would we need "countChunksBy"?
  • send links to equivalent functions in other data programming libraries

Questions on Auto-quotations design

Thanks for starting to post the speclets. A few things that I still don't quite understand for the auto-quotations feature:

First-class uses

a first-class use of the method C.Plot is considered shorthand for (fun x -> C.Plot(x)) for some compiler-generated local name “x”, which will become (fun x -> C.Plot( <@ x @> )) , so the implicit quotation will just be a local value substitution. This means a pipelines use expr |> C.Plot will not capture a full quotation for expr , but rather just its value.

Does "just ... a local value substitution" mean that the compiler-generated name is or is not captured?

Applicability

The conversion only applies if the called-argument-type is type Expr for some type T, and if the caller-argument type is not of the form Expr for any U.

What does this mean for the scenario where T is Expr? i.e. static member Test([<ReflectedDefinition(true)>] values:Expr<Expr<int>>) = (...)

Will a call to above like Test(<@ x @>) not compile (since caller arg is an Expr, so no transformation is done, and untransformed Expr<int> does not match required Expr<Expr<int>>?

Overloading
(Formatting in the first code sample here is missing, difficult to understand examples)

Overall usefulness
How do developers aiming to use this feature for scenario # 2 (in Plot function, e.g. to label axes with the text of the expression) actually do it in practice? For these scenarios (where deep structure of the quotation is not even desired), the feature is too low-level. It requires highly advanced F# knowledge to implement a robust routine to recover something even close to the original F# code that composed the expression.

If this is punted to the community, will 3rd-party implementation of some quotationToFSharpCode routine be brought back into the runtime, assuming it's high-quality?

I would say that with no higher-level support, this feature can only be marketed as an advanced hook for those interested in doing deep expression tree inspection/processing. If we announce it as "enables R-like support for labeling plots!", everyone will be sorely disappointed when they realize you need expert-level chops to make that work.

Status of Observable

At the moment I'm trying to build a rename suggestion tool for the F# Power tools. We are trying to use IObservable and I'm missing a lot of basic operators.

What's the status of the Observable module. Do you want to add more functions?

[Design] Implement except on seq, array and list

As suggested in uservoice we should implement Except on seq, array and list.

The initial PR is dotnet/fsharp#253

Some decisions:

  1. Should duplicates be removed from the result? This is how Enumerable.Except works (it refers to it as a Set Difference)
  2. Should the signature be seq<'T> -> M('T) -> M('T) rather than M('T) -> M('T) -> M('T) as suggested by @forki? Probably yes
  3. If we're implementing Except, should we be also implementing Union and Intersection? These are also implemented in LINQ. Should we also allow custom comparers?

Support for TypeProvider nested types with static parameters

Can we please track support for TypeProviders providing nested types with static parameters? It seems to me it would be valuable for metaprogramming similar to how static parameterized method support is valuable compared to the language without them. It would allow a fluent-like construction of types and partially make up for the non-variable length static parameters on a single type. Is there a complicated reason that nested parameterized types cannot be supported?

You wrote "Things generally get very nasty when you have a primary set of static parameters on a type" but I'm not sure whether this refers to this support which I'm asking about. I think you're just saying that a statically-parameterized method returning a type dependent on its parameters can get complicated to think about.

An example: Internal DSLs for defining types from other languages can take advantage of the nesting type provision to label different components that aren't clearly delineated in the source language. In this example of a fictitious type provider using this fictitious feature, the Extend schema definitions can be split up as shown but could just as well be combined for defining the types in the domain, but the RequireZero domain invariant specifications which communicate individual domain invariants can need multiple statements and could not clearly be delineated in the source language without comments or manifest files referencing other files or something obnoxious like that.

type myDomain = 
    EmptyDomain
    .Extend<"CREATE TABLE Customers ...">
    .Extend<"CREATE TABLE Charges ...">
    .RequireZero<"SELECT ...", "Rule 1", "Customers may not share an email address with more than 3 other Customers.">
    .RequireZero<"SELECT ... INTO @Intermediate; SELECT TOP 1 1 FROM @Intermediate", "Rule 2", "A Customer's Charges may not total more than the Customer's CreditLimit.">

let updateCustomerName custId name= 
    myDomain.OpDefine<"UPDATE Customer SET Name= @fullname WHERE Id = @Id">(name, custId)
let updateCustomerEmail custId address = 
    myDomain.OpDefine<"UPDATE Customer SET Email = @email WHERE Id = @Id">(address, custId)
let addCharge custId amount description = 
    myDomain.OpDefine<"INSERT INTO Charges ...">(custId, amount, description)
let chargeEverybody amount description = 
    myDomain.OpDefine<"INSERT INTO Charges (...) SELECT @amount, @desc FROM Customer">(amount, description)
let adjustLimit custId delta= 
    myDomain.OpDefine<"UPDATE Customer SET CreditLimit = CreditLimit + @delta WHERE Id = @Id">(delta, custId)

updateCustomerEmail 2823 "Jim Smith" // Emits only the original update - no rules are possibly violated
updateCustomerEmail 2823 "[email protected]" // Emits the original update plus some assertion sql for Rule 1 because of potential impact
adjustLimit 2823 -500.00 // Emits the original update plus some assertion sql for Rule 2 because of potential impact
addCharge 2823 630.00 "Oculus Rift" // Emits the original update plus some assertion sql for Rule 2 because of potential impact
chargeEverybody 5.00 "Membership Fee" // Emits the original update plus some assertion sql for Rule 2 because of potential impact

// analysis and embellished sql scripts are generated at compile time.  Type safe sql statement 
// parameterization included.  Domain invariants are enforced.  Can also generate and use 
// deployed stored procs for the benefit of compiled execution plans.

The current alternative is type myDomain = Domain<"CREATE TABLE Customers ... CREATE TABLE Charges ...", "SELECT ... -- RESERVED_DELIM SELECT ... INTO @Intermediate; SELECT @Intermediate"> but this is inconvenient, even if the literal script were instead a file with those contents.

Native support for Task and Task<'T>

Hi,

I was wondering if it would make sense to add native support for Tasks in F# which doesn't require to convert a Task into an Async object back and forth all the time.

Given that most libraries in .NET (almost everything) works with Tasks (when it supports async) I think it almost doesn't make sense for having Async today other than backwards compatibility. In other words, I suggest if we could have something like task {} in F# which deprecates async {} in the future?

FSharpX has a task computation expression and someone else has further improved it in this GitHub repository, which claims to be a lot more faster than having to constantly convert between Task and Async back and forth.

What do you think of it and what caveats does it have which I might be missing at this point?

[RFC FST-1004] - Versioning discussion

This is for this RFC: https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1004-versioning-plan.md

In the RFC, there are two options for the handling of FSharp.Core. I'd like to get feedback on that.

Option 1: Version in lockstep with the F# Language, is favored by @dsyme as per this comment:

There's a lot of simplicity value to keeping the versions aligned. So I think we should probably make it that from 4.5 onwards F# minor language revisions can just be "small" or even empty (i.e. F# 4.8 might be the same language as F# 4.7 with some improvements/adjustments to FSharp.Core).

Option 2: Version independently from the F# language, is favored by @KevinRansom as per a discussion him and I had, which I documented in the RFC.

Both are centered around a central problem, which is that we can (and likely will) receive improvements to the F# core library (beyond bug fixes) faster than improvements and new features in the F# compiler.

@dsyme suggests that we should just rev the F# language version when a sufficient number of changes are made to the F# core library, which would satisfy the desire to rev FSharp.Core when these changes are merged. @KevinRansom, what are your thoughts?

Also tagging @isaacabraham, as this was a point he brought up in the related VisualFSharp issue.

tryFindBack and tryFindIndexBack

Since we currently have find/tryFind and findIndex/tryFindIndex, should we also add try versions of the proposed findBack and findIndexBack methods to the proposed collection functions?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.