ohsorry / make-it-so Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/make-it-so
Automatically exported from code.google.com/p/make-it-so
I am getting the following error message when running the makeitso while
parsing my solution file.
"
Fatal error: Failed to parse solution trading-platform_vs2008.sln ['call'
failed to call function after 20 tries.]."
I have attached the error logs as well as solution file for your reference.
I am using VS 2008 to compile C++ programs.
Please do provide the fixed code as soon as possible.
Original issue reported on code.google.com by [email protected]
on 13 Dec 2013 at 8:09
Attachments:
What steps will reproduce the problem?
1. Unload at least one of your projects in solution (Properties -> Unload
project)
2. Save solution
3. Run make-it-so
What is the expected output? What do you see instead?
Conversion is expected, but whole conversion of solution is aborted due to the
exception.
What version of the product are you using? On what operating system?
1.2, Windows 7, VS2010
Please provide any additional information below.
I provided a patch, which checks some basic properties of the project and if
the project appears to be unloaded (unfortunately there's no direct property),
the current project is simply skipped from conversion and a warning is sent to
the command line.
Original issue reported on code.google.com by [email protected]
on 14 Oct 2013 at 10:10
Attachments:
MakeISo is not compatile with VisualStudio2012 VCXPROJ
Original issue reported on code.google.com by [email protected]
on 19 Nov 2013 at 8:36
gcc's linker is (annoyingly) fussy about the order that static libraries are
given to it if there are dependencies between them.
We need to fix this.
Original issue reported on code.google.com by [email protected]
on 11 Jan 2012 at 10:05
When compiling a dll/shared object project that references a static library,
the current command line settings cause link errors due to there being no -fPIC
option set for static library projects.
Original issue reported on code.google.com by [email protected]
on 5 Feb 2014 at 6:59
What steps will reproduce the problem?
1. Parse solution, converted from vs 2012 by simply replacing "12.00" by
"11.00" in first line(see attachment)
What is the expected output? What do you see instead?
I expect that all projects in solution will be parsed, but that one wasn't.
Can't understand, why. Output from Makeitso was redirected to log(see
attachment), but there are no error messages about skipping due to an error, or
something like that.
What version of the product are you using? On what operating system?
1.2.0, because 1.2.1 crashes on startup. Windows 7, x86_64
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 24 Oct 2013 at 11:45
Attachments:
Write MakeItSoConfig wiki page
Original issue reported on code.google.com by [email protected]
on 28 Nov 2011 at 9:40
Allow the tests to run in parallel:
- Make the TestRunner launch multiple MakeItSo and cygwin windows.
- Run make with the -j option
Original issue reported on code.google.com by [email protected]
on 30 Nov 2011 at 10:53
By default Make-it-So will generate targets for both Debug and Release
configurations. That means both of them are compiled when launching a build and
results in a huge waste of time when building large projects.
The aim would be to add an option to the config file when you only want one
target (Debug/Release) to be generated.
Original issue reported on code.google.com by florian.sainjeon
on 28 Nov 2013 at 10:59
What steps will reproduce the problem?
1. Create a random VC project which contains at least one source file which is
marked as "excluded from build" (this can be set to any sourcefile per
configuration in "configuration properties/common" of the files' properties.)
2. let makeItSo create the makefile
3. search the generated makefiles for the source which shouldn't be compiled
What is the expected output? What do you see instead?
Instead of not seeing a compilation directive for the source file in the
generated makefile, the flag "exclude from build" (per build configuration)
seems to be ignored and compilation directives are generated.
What version of the product are you using? On what operating system?
MakeItSo_1.2.2
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 17 Nov 2014 at 3:50
When generating your application, make will basically follow each step in the
Makefile and execute them.
However even when all files are up to date, il will invoke the "ar rcs" step in
the generation which is a huge waste of time for large projects.
To improve this, here's what I successfully tried by manually changing noe of
my project's makefile:
_____ CHANGE THIS _____
.PHONY: Debug Release
Debug: create_folders [List of .o files]
ar rcs [path to generated lib/exe] [list of .o files]
[same for Release]
_____ TO THIS _____
.PHONY: Debug Release
Debug: create_folders [path to generated lib/exe]
[path to generated lib/exe]: [List of .o files]
ar rcs [path to generated lib/exe] [list of .o files]
----------------------
This allow make not to generate everything if there's no change in the project.
Original issue reported on code.google.com by florian.sainjeon
on 19 Dec 2013 at 9:29
What steps will reproduce the problem?
MakeitSo Version 1.2.0
1. run makeitso -file=RhmDxfDwgCheckCsv.sln (Attachment)
2.
It may be, the problem is with placeholders for system variables that are
defined in a CMD file:
set GILIB = M: \
set VSRHMENV = D: \ SANDBOX \ RHMTRUNK
...
rem RhmCore
set RHMCOREH =% VSRHMENV% \ RhmCore
set RHMBASEH =% VSRHMENV% \ RhmGenBase
set RHMERRH =% VSRHMENV% \ RhmErrCodes
set RHMRXH =% VSRHMENV% \ RhmRegex
set PATH =% PATH%; ...; ...
rem use vstudio
"C: \ Program Files \ Common Files \ Microsoft Shared \ MSENV \ VSLauncher.exe"
"RhmDxfDwgCheckCsv.sln"
rem or MSBUILD
C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ msbuild [pathto] \
RhmDxfDwgCheckCsv.vcxproj / p: configuration = debug / t: rebuild
[...]
The aim then is the automatic code generation via makeitso and gcc also for
linux...
3. What is the expected output? What do you see instead?
Parsing rhmdxfdwgcheckcsv.sln
- parsing project RhmDxfDwgCheckCsv
- FAILED (Ung�ltiger URI: Das URI-Format konnte nicht bestimmt werden.)
- parsing project RhmDxfDwgCheckCsv_Test
- FAILED (Ung�ltiger URI: Das URI-Format konnte nicht bestimmt werden.)
Parsing succeeded.
Creating makefile...
Creating makefile succeeded.
What version of the product are you using? On what operating system?
MakeitSo Version 1.2.0, WinXPProf
I have tried to meeting closer to the problem of using the debug Repsitory
(VS2008 and VS2010), but the version from the repository behaves differently:
[SolutionParser.cs - VS2010]
case ProjectType.CPP_PROJECT:
{
//...
VCProject vcProject = Utils.call(() => (project.Object as VCProject));
//Error: vcProject is NULL!!!
...
}
Please provide any additional information below.
I would like to participate to help solve the path-token-problem within the
vcxproj. The realization of makeitso.config is too static and hardly applicable
here.
Thank you for this exellent work and your efforts..
Bernd
Original issue reported on code.google.com by [email protected]
on 22 Mar 2012 at 2:35
Attachments:
When we implicitly link libraries from projects we depend on, we should try to
find the configurations with the best match name - using the Levenshtein thing.
At the moment we only match on exact matches, I think.
Original issue reported on code.google.com by [email protected]
on 23 Dec 2011 at 9:38
What steps will reproduce the problem?
If you have separated Visual Studio's project and source files into different
folders the object and definition files will not be generated with valid names.
Example) Say source is located "../src/foobar.c"
the generated make file will try to output "gccDebug/../src/foobar.o" which
does not work.
Quick fix I did for this is by modifying the MakeItSo source in
MakefileBuilder_Project_CPP.cs (I'm using a C framework) and stripping the
relative path component from the target files by:
foreach (string filename in m_projectInfo.getFiles())
{
var fileNameOnly = Path.GetFileName(filename);
string path = String.Format("{0}/{1}", intermediateFolder, fileNameOnly);
string objectPath = Path.ChangeExtension(path, ".o");
...
and further down
foreach (string filename in m_projectInfo.getFiles())
{
// We work out the filename, the object filename and the
// dependencies filename...
var fileNameOnly = Path.GetFileName(filename);
string path = String.Format("{0}/{1}", intermediateFolder, fileNameOnly);
string objectPath = Path.ChangeExtension(path, ".o");
string dependenciesPath = Path.ChangeExtension(path, ".d");
...
Original issue reported on code.google.com by [email protected]
on 3 Jul 2013 at 12:04
This issue comes when the .sln file is not in the root folder where all
projects are stored.
For large projects and numerous dependencies its useful to keep dependencies
outside of the base project folder
What is the expected output?
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c
../../modules/juce_audio_basics/effects/juce_IIRFilter.cpp
$(Debug_Include_Path) -o
gccDebug/modules/juce_audio_basics/effects/juce_IIRFilter.o
What do you see instead?
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c
../../modules/juce_audio_basics/effects/juce_IIRFilter.cpp
$(Debug_Include_Path) -o
gccDebug/../../modules/juce_audio_basics/effects/juce_IIRFilter.o
Original issue reported on code.google.com by [email protected]
on 10 Dec 2013 at 1:26
If the command-line is unrecognized (i.e, including --help, /? etc) we should
display the basic help.
This can should the command-line options, and also the url of the wiki.
Original issue reported on code.google.com by [email protected]
on 11 Dec 2011 at 2:29
What steps will reproduce the problem?
1. Create a C++ project with source files not using ".cpp" or ".c".
2. ???
3. Profit
What is the expected output? What do you see instead?
The expected output is "proper" makefiles. The actual output is "improper"
makefiles.
What version of the product are you using? On what operating system?
Visual Studio 2008, Windows XP
Please provide any additional information below.
The parsing for C++ projects checks if the file extensions match:
.c
.cpp
Unfortunately, common C++ source file extensions include (according to "man
g++"):
.cc
.cp
.cxx
.cpp
.CPP
.c++
.C
I modified the code to include the following extensions:
.cxx
.cc
Note I made the changes mostly as a quick fix for my own purposes -- A more
complete fix might include the common extensions and allow additional
extensions from the config file?
Original issue reported on code.google.com by [email protected]
on 5 Jan 2012 at 1:32
Attachments:
since the project is not maintained, just a tip. If you want to support any
inherited values (from property sheets, for example) just replace the use of
VCConfig.Evaluate with IVCRulePropertyStorage.GetEvaluatedPropertyValue
like:IVCRulePropertyStorage rule =
(IVCRulePropertyStorage)vcConfiguration.Rules.Item("CL");
string strAdditionalIncludeDirectories =
rule.GetEvaluatedPropertyValue("AdditionalIncludeDirectories");
for getting all additional include directories
Original issue reported on code.google.com by [email protected]
on 29 Oct 2014 at 1:30
-
Original issue reported on code.google.com by [email protected]
on 14 Feb 2012 at 9:41
The config should allow you to specify that a project should not be converted.
For example, you may have a project that is Windows-specific and you do not
want to convert it in a Linux build
Original issue reported on code.google.com by [email protected]
on 11 Dec 2011 at 2:23
Write HowToReportProblems wiki page
Original issue reported on code.google.com by [email protected]
on 28 Nov 2011 at 8:16
For both C++ and C# projects you should be able to specify the compiler version
in the MakeItSo.config file.
This could be a different version from the default, or you may need to specify
the compiler if it is not on the path for some reason.
Original issue reported on code.google.com by [email protected]
on 25 Dec 2011 at 9:24
When converting complex solutions, parsing projects that have been configured
to be ignored can waste a huge amount of time.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2013 at 10:08
Attachments:
What steps will reproduce the problem?
1. I am using 3 C# project and one C++ project in the solution
2. MakeItSo successfully parsed all the project but after that it is throwing a
fatal error.
3. Fatal error: Failed to parse solution dataacq.sln [Unable to cast object of
type
'MakeItSoLib.ProjectInfo_CSharp' to type 'MakeItSoLib.ProjectInfo_CPP'.].
What is the expected output? What do you see instead?
Expecting the makefile to be created for the project
What version of the product are you using? On what operating system?
MakeITSo 1.2 and Visual Studio 2010
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 6 Dec 2012 at 5:27
Write converting solutions for Cygwin wiki page. Link from main page?
Original issue reported on code.google.com by [email protected]
on 28 Nov 2011 at 8:18
make-it-so ignores PropertySheets.
I tried to add code to check PropertySheets to make-it-so.
I think it is easy, because there is code to get PropertySheets in
SolutionParser_VS2008/ProjectParser_CPP.cs.
I attach patch file for SolutionParser_VS2010/ProjectParser_CPP.cs.
If there is no problem, could you add code to check PropertySheets.
Best Regards
Original issue reported on code.google.com by [email protected]
on 27 Dec 2013 at 4:36
Attachments:
I took the liberty to implement vs2012 support.
Now there's support for DirectoriesSetting, that is "VC++ Directories Settings"
that moved from "Options" to "Project Settings" (that was on vs2010).
I also implemented support for changing the linker/assembler.
And I added support for the configuration alias named 'All', this is to
simplify the config xml when you need to use same arguments on Build and on
Release.
Original issue reported on code.google.com by [email protected]
on 4 Nov 2014 at 5:15
Attachments:
What steps will reproduce the problem?
1. I am using Windows 7 and when I do a make, I get the following error.
******
mkdir -p bin/monoDebug
The syntax of the command is incorrect.
******
This is because of the fact that Windows uses \ as a path separator and we have
/ in the command. I don't think this is a real bug, but is there some kind of a
workaround for this?
What is the expected output? What do you see instead?
******
mkdir -p bin/monoDebug
The syntax of the command is incorrect.
******
What version of the product are you using? On what operating system?
1.2.0
Please provide any additional information below.
Windows 7 Home Basic
Original issue reported on code.google.com by [email protected]
on 5 Feb 2013 at 10:06
Folder names with spaces don't work - at least in the 'clean' step. I'm not
sure about compiling.
Should check:
- Compiling
- Output folders
- Intermediate folders
- Solution root folder
- Project root folder
Original issue reported on code.google.com by [email protected]
on 30 Nov 2011 at 9:38
What steps will reproduce the problem?
1.when I run makeitso.exe produce
Index was outside the bounds of the array.
Parsing .\finalUUID.sln
Fatal error: Failed to parse solution .\finalUUID.sln [Visual Studio 2010 cannot
be loaded].
What is the expected output? What do you see instead?
Need makefile
What version of the product are you using? On what operating system?
1.2.2 , Visual Studio (32 bit platform), Windows 7 64bit os
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 4 Jul 2014 at 3:53
Attachments:
I downloaded makeitso from the featured download link and unzipped it in a
directory on the PATH. When running it (under Win7 64bit) without any
parameters I'm getting the following output:
>>>
Parsing .\myproject.sln
Fatal error: Could not load file or assembly 'EnvDTE, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified.
<<<
Given the purpose of this project, it shouldn't be unusual that I don't have
VisualStudio installed. I did a web search for the error message above and
everything I found mentions devenv.exe. Could it be that this is not a Release
build?
Thanks for your help (and coming up with this project!)!
Original issue reported on code.google.com by [email protected]
on 21 Mar 2012 at 7:12
i wanna make this project better .make it visual operation.
Original issue reported on code.google.com by [email protected]
on 20 Jun 2012 at 2:18
All our projects have 32 and 64 bit builds, these equate to Win32 and x64
platform types. For both platform types the configuration names are the same
(Release and Debug).
When I convert the projects all the makefiles end up with two Debug and two
Release target configurations with nothing to identify them uniquely.
To fix please replace the following line in ProjectParser_CPP.cs for both 2008
and 2010:
configurationInfo.Name = Utils.call(() => (vcConfiguration.ConfigurationName));
With this code:
// Get target name (e.g. Release|Win32)
string pipeString = Utils.call(() => (vcConfiguration.Name));
// Replace '|' with '_'
var pipe_index = pipeString.IndexOf("|");
configurationInfo.Name = pipeString.Substring(0, pipe_index);
configurationInfo.Name += "_";
configurationInfo.Name += pipeString.Substring(pipe_index + 1);
This will generate makefiles with target names Release_Win32, Release_x64,
Debug_Win32 and Debug_x64.
Since this will break exiting usage you might want to make it a command line
option to use this new convention.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2012 at 6:33
When generating the makefile, the "Library_Path" and "Libraries" sections are
generated correctly, but these are not used in the output command line options
for CPP_DLL projects (as they are in CPP_EXECUTABLE projects).
This causes any static library references to be undefined in the resulting
shared object file.
Original issue reported on code.google.com by [email protected]
on 5 Feb 2014 at 6:52
Even if a project is a static library, you may want to build a .so in the Linux
version instead of a .a
We could add an option to do this.
Original issue reported on code.google.com by [email protected]
on 1 Jan 2012 at 2:00
What steps will reproduce the problem?
1. Create a random VC project which contains at least one source file with the
file ending 'C' but which is marked as "compile as C++ code" (this can be set
to any sourcefile per configuration in "configuration
properties/c_c++/extended/type of compilation" of the files' properties.)
2. let makeItSo create the makefile
3. search the generated makefiles for the c-source which should be compiled as
c++ code
What is the expected output? What do you see instead?
Instead of seeing $(C_COMPILER) used to compile these sort of files, i'm
expecting to see $(CPP_COMPILER) there.
What version of the product are you using? On what operating system?
MakeItSo_1.2.2
Please provide any additional information below.
I assume the opposite (compile file with cpp-ending as c source) being equally
impossible atm.
Original issue reported on code.google.com by [email protected]
on 18 Nov 2014 at 3:29
While not explicitly documented, Visual Studio allows commas to be used to
delimit Additional Directories. Many of our projects are set up this way. An
error is generated by MakeItSo when commas are used.
To fix please replace the following line in ProjectParser_CPP.cs for both 2008
and 2010:
List<string> additionalLibraryDirectories = Utils.split(strAdditionalLibraryDirectories, ';');
with this line:
List<string> additionalLibraryDirectories = Utils.split(strAdditionalLibraryDirectories, ';', ',');
Original issue reported on code.google.com by [email protected]
on 12 Sep 2012 at 6:19
sln2mak does something with them??
254 m_MakFWriter.WriteLine("%.res: %.rc");
255 m_MakFWriter.WriteLine("\t$(RC) $(CPPFLAGS) -o $@ -i $<");
256 m_MakFWriter.WriteLine("");
Original issue reported on code.google.com by [email protected]
on 12 Jan 2012 at 7:04
As title.
Original issue reported on code.google.com by [email protected]
on 30 Dec 2011 at 10:28
________ What steps will reproduce the problem?
Let's say you have the following architecture:
MainApp
|-- Source
| |--- MainSource1.cpp
| |--- MainSource2.cpp
| `--- DependancyFile.cpp
|-- Include
| |--- MainInclude1.h
| `--- MainInclude2.h
`-- SecondaryApp <------------------------- Doing a "make" on this one
|--- SecondaryApp.makefile
|--- Source
| |--- SecondarySource1.cpp
| `--- SecondarySource2.cpp
`--- Include
|--- SecondaryInclude1.h
`--- SecondaryInclude2.h
Now imagine you're building your SecondaryApp and you included the
MainSource1.cpp in your solution because you need it. The MainApp doesn't need
to be built, hence why there isn't any makefile.
When building SecondaryApp, DependancyFile.d and .o won't be placed in the
SecondaryApp/gccDebug directory but in the SecondaryApp/source directory.
________ What is the expected output? What do you see instead?
Have the *.d and *.o files placed in the correct directory (as indicated before)
________ How to fix it?
- Change the Debug/Release Configuration (basically just remove the ../)
- Change the file output and input paths when compiling the file
Example based on my work - Change this:
# Builds the Debug configuration...
.PHONY: Debug
Debug: create_folders ./gccDebug/../source/DependancyFile.o
./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o
g++ ./gccDebug/../source/DependancyFile.o ./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o $(Debug_Library_Path) $(Debug_Libraries) -Wl,-rpath,./ -o ../../serveur/gccruntime/SecondaryApp.exe
# Compiles file ../source/DependancyFile.cpp for the Debug configuration...
-include ./gccDebug/../source/DependancyFile.d
./gccDebug/../source/DependancyFile.o: ../source/DependancyFile.cpp
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c ../source/DependancyFile.cpp $(Debug_Include_Path) -o ./gccDebug/../source/DependancyFile.o
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -MM ../source/DependancyFile.cpp $(Debug_Include_Path) > ./gccDebug/../source/DependancyFile.d
!! ------------ BY THIS ------------ !!
# Builds the Debug configuration...
.PHONY: Debug
Debug: create_folders ./gccDebug/source/DependancyFile.o
./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o
g++ ./gccDebug/source/DependancyFile.o ./gccDebug/source/SecondarySource.o ./gccDebug/source/SecondaryMain.o $(Debug_Library_Path) $(Debug_Libraries) -Wl,-rpath,./ -o ../../serveur/gccruntime/SecondaryApp.exe
# Compiles file source/DependancyFile.cpp for the Debug configuration...
-include ./gccDebug/source/DependancyFile.d
./gccDebug/source/DependancyFile.o: ../source/DependancyFile.cpp
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -c ../source/DependancyFile.cpp $(Debug_Include_Path) -o ./gccDebug/source/DependancyFile.o
$(CPP_COMPILER) $(Debug_Preprocessor_Definitions) $(Debug_Compiler_Flags) -MM ../source/DependancyFile.cpp $(Debug_Include_Path) > ./gccDebug/source/DependancyFile.d
Original issue reported on code.google.com by florian.sainjeon
on 2 Oct 2013 at 9:07
I want to build a makefile using makeitso but it ends up giving me that error
Original issue reported on code.google.com by [email protected]
on 9 Dec 2014 at 12:43
Executables and libraries in C as well as C++.
Original issue reported on code.google.com by [email protected]
on 30 Nov 2011 at 9:50
What steps will reproduce the problem?
1. Consider a solution file with a project file and project file inherit from a
property file [vsprops]
2. The include paths from the property file is not getting inherited into the
project file
3.
<Tool
Name="VCCLCompilerTool"
Description="Building the project $(ProjectName)"
AdditionalIncludeDirectories="$(SolutionDir)..\api\OpenMAX\Khronos;
$(SolutionDir)..\api\OpenMAX\QCOM;
$(SolutionDir)VFEDriver\VFEDriverWin\inc;
$(SolutionDir)..\platform\OSAbstraction\inc;
/>
4. The <AdditionalIncludeDirectories> from the property file is not getting
into the inherited project file.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Visual Studio 2008, Windows 7
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 6 Mar 2012 at 8:50
I don't know if Makefiles allow this but it could be worth checking.
____ What steps will reproduce the problem?
1. Generate your makefiles through Make-it-So
2. Build your app on Linux
3. Change something in a project which depends on an already generated
library/exe project, and launch make again.
____ What is the expected output?
When building a project, I don't expect Make to actually rebuild every library
(previously generated by Make-it-So) my project depends on.
In my case: I have an app which depends on 1 exe and 2 libraries, which
themselves depend on 5 other libraries, and so on. And everytime I do a make on
my app, the "ar rcs" part is called which can be long with large libraries.
Someone should check if there's some way to indicate in the Makefile not to
execute this part if nothing has changed since the last build.
Original issue reported on code.google.com by florian.sainjeon
on 27 Nov 2013 at 1:57
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.