cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated GSoC 2015 Ideas (markdown)

This commit is contained in:
Dennis Felsing 2015-02-20 06:57:59 +01:00
parent ab019e9ec1
commit d6f25b16c7
1 changed files with 25 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
GSoC-2015-Ideas.md
View File

@ -281,6 +281,10 @@ GLFW backend. This will allow games to be created more idiomatically and with
less overhead involved. Other new languages like Rust have similar projects
like [Piston](https://github.com/PistonDevelopers/piston).
This requires the idiomatic and platform independent implementation of 2D
graphics and 3D graphics, window management as well as audio output. By using
SDL2 we also ensure that porting to mobile platforms will be easier.
**Tasks:**
* Start implementing a high level game library on top of SDL2 and OpenGL, inspired by other game libraries like Piston and Pyglet.
* Prove the usability to write a simple Minecraft clone in the spirit of the 500 line Python/Pyglet [Minecraft](https://github.com/fogleman/Minecraft).
@ -303,10 +307,20 @@ parallel programs. These programs can run on a single computer as well as on a
whole cluster, where messages are sent over the network. Nim, with its
excellent performance/productivity ratio, would make a great language for this
use. What's missing is a Nim library to make use of the existing MPI libraries
for C. An existing C library like OpenMPI can be wrapped using `c2nim` to get a
non-idiomatic low level wrapper for MPI. Since the MPI interface is very
verbose, and to make its use feel more Nim-like, a high level library should
then be written.
for C. An existing C library like [OpenMPI](http://www.open-mpi.org/) can be
wrapped using `c2nim` to get a non-idiomatic low level wrapper for MPI. Since
the MPI interface is very verbose, and to make its use feel more Nim-like, a
high level library should then be written.
A possible source of problems is that MPI libraries often differ slightly. For
the start it will be good enough to just support one of the popular MPI
libraries like OpenMPI or MPICH. Afterwards it will be interesting how to deal
with the C preprocessor macros specifying the differences between MPI
implementations. You will need to investigate whether a solution such as [in
Julia](https://github.com/lcw/MPI.jl/blob/master/deps/make_f_const.f) will be
necessary to create a custom wrapper for each MPI implementation. Preferrably
this would be solved directly with Nim's capabilities, and the close relation
to C could come in handy here.
**Tasks**:
* Create a low level wrapper of a C library for the MPI standard using `c2nim`.
@ -328,12 +342,16 @@ then be written.
Gofmt is often cited as one of the major points for the Go programming
language. It completely eliminates the need to manually adhere to style
formatting, by automatically converting Go code into a consistent style.
formatting, by automatically converting Go code into a consistent style. This
makes the code easier to read, write and maintain as well as removes any debate
about which code style to adhere towhich code style to adhere to
Something similar would be nice to have in Nim, where we have additional
freedoms, like case insensitivity, that should be handled in a consistent way
for big projects.
for big projects. Such a project could be closely tied to the Nim compiler,
that already brings the tools to parse Nim code and represent it in AST form.
There is already a converter from AST to Nim code in
There is already a converter from AST to Nim code as well, in
[renderer.nim](https://github.com/Araq/Nim/blob/devel/compiler/renderer.nim),
that is used for `repr` as well as `c2nim`. It would make sense to use and
extend this or at least use it as inspiration.