On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check those plans !!

If I had time I'd like to attempt a DbI audio library for compile-time audio graphs. This would solve the problem of making complex algorithm work with any number of channels without too much overhead.

The problem is, the nodes I've written until now (without abstraction) are just too diverse. The equivalent for the input range would have only optional properties which is weird. I think it would need some kind of added semantics based on the parameter names perhaps?

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check those plans !!

-test out the iOS LDC port
-get some work done on osx shared libs if I can find the time
-continue porting/gluing all my bits of code together to try and make an app framework(dispatcher/event-system, graphics, scene graph, etc..)

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check those plans !!

I want to release beta version of GUI Framework, build tool and IDE for D.

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check those plans !!

- Writing documentation and real world examples for my projects. The goal is to convince others to use D for statistics and econometrics. (The target users are far less technical than those targeted by Mir.)

- File bugs for missing Phobos documentation.

- Experiment with compiling a subset of R to D. R parses itself, so I don't actually have to do anything on that end, but I don't have much experience with what comes next. The motivation is to do things like operating on all rows of a matrix. Basic operations should be easy. D will become a very attractive option if I can put together something useful.

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check those plans !!

After getting my CUDA and OpenCL modifications into LDC, write a sane driver library over the top of them, device standard library and thrust like ( but better obviously :), with UFCS so you can chain calls) library of prewritten kernels to accelerate numerical applications.

I also plan to release a subsection of my honours thesis as documentation for vibe.d of how to set up an image server on your RaspberryPi and use it to remotely take photos and view them.

On 03/01/2017 7:17 AM, Basile B. wrote:
> On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
>> Write your plan here, and let's take a rendez-vous next year, to check
>> those plans !!
>
> My own plan is still related to runtime-info based serialization. I know
> that people  inject the bloat each time they want serialization:
>
> write object: template bloat
> read object: template bloat
> object inspector: template bloat
> object binding: template bloat
>
> What I'd like to show is that whatever is the context, you don't need
> the template bloat. Simply thanks to the runtime type info.

Then we need to talk!
IRC preferably.

On 03/01/2017 4:16 AM, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check
> those plans !!

Lets see.

1. Finish my honors.
2. Get my assembly lib actually in a usable state
3. Get SPEW ready to go on multiple platforms
4. Have decent OpenGL bindings
5. Image library usable for a GUI toolkit

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
> Write your plan here, and let's take a rendez-vous next year, to check those plans !!

write some more libraries and ports nobody will ever use.

1/ Carry on doing my 3D engine pet project, slowly but steadily.
2/ Small tool to automatically backup some files on an USB drive upon insertion (with a GUI).
3/ An audio/video streaming framework (a light gstreamer). I want to make it fast, with low memory footprint, suitable for embedded system, and especially make all the synchronization part easy for a potential plugin developer (no deadlock, no crash because an object is destroyed too early).
4/ Do some D stuff for ARM architecture...

I'm close to releasing a web-app built fully in vibe-d.

I'm thinking of attempting a native android app using D based on the same project as above.

Continue my 2D game dev project (which is going super slow lately).