wilkie / djehuty Goto Github PK

JPEG decoder is missing a progressive decoding stage.

Because what goes on in private can be so wrong and you might not even know it.

Change all instances of Arraylist to List

It hasn't been maintained AT ALL. It needs a day or two worth of work :(

Because of changes to List and ArrayList, DSpec does not build.

It would be nice to be able to build and use our testing framework :)

The idea is to have building of applications be automated, scriptable, and packaged via git repo.

A package manager (such as mausoleum) would use git to grab the modules necessary to build the app.

This process is not exactly known... and it is probably very crucial.

Comments...?

Not all of the Core package has spec tests (/spec/core/*)

Each module should be testable in some capacity.

It would be useful to see the expected and actual values for the tests. The simplest way would probably be changing should(str == "foo"); to expected("foo"); actual(str);. Since not all cases are usefully tested that way, perhaps both mechanisms should be available.

runtests executes with 7 seconds on windows and linux - this takes 48 minutes on OS X. Similarly other apps run slow on OS X.

due to changes to Console.

It doesn't crop the redundant space correctly.

I was going to write some tests, but as it is now, runtest provides some cryptic output (lines with a red F or a green space, which I'm guessing mean failure and success of unspecified tests) and segaults after 25 lines.

Specification Tests for each of the modules in the Resource package (/specs/resource/*)

This would be a nice module. The Networking package is lacking without it.

The MP3 decoder must not be exactly 100%. On the MP3 fazed.dreamer.mp3 in the repo, there are a few pops in the beginning. Should probably cross reference the PCM output from this decoder with one that is known to work.

Tests are good for the soul. They should test all functionality of each module.

How to document the abstraction to users?

Probably have to roll our own and perhaps create a D frontend up through the syntactic stage.

Discuss.

How to document the framework consistently for developers.

Discuss.

How will packages (Core, Io, Gui, Math.Probability, etc, etc) be maintained and pulled? Ideally, people can reimplement packages to suit different needs, and can be pulled and compiled into any given app as a configuration.

Different repos? Emulate ruby gems? Blessed repos for generic default implementations?

Discuss.