scone v1.1.0
//scone, Simple Console Engine is a Windows console API, made for
easier CLI application development.
https://github.com/vladdeSV/scone
Today, at v1.1.0, some pretty big additions for scone were
introduced, the two main points being
* UI libray
* Localization
Biggest addition is the UI library, which allows for much simpler
ways to handle certain elements of an application. This includes
simple labels, text fields, options etc, which can be altered in
a variety of ways. Elements are accessed in the same manor as
android applications does it `auto t =
ui.elementById("screenText"); t.color = Color.yellow;`. Example
of login screen: http://i.imgur.com/s6eSIDW.gif
Second point is localization. Different keyboards have different
layouts. This is why .locale files are introduced, which follows
a csv pattern. Corresponding key matches a lowercase and
uppercase/shifted character (read as ubytes). For example in
en_US.locale: "key_2 2 @" can be found. Currently there is
only one .locale (en_US). These will hopefully be expanded upon
soon.
Feedback is always appreciated!
https://github.com/vladdeSV/scone/releases/tag/v1.1.0
unit-threaded v0.6.19 - preliminary support for property-based testing
http://code.dlang.org/packages/unit-threaded
After merging code from Robert's fork I added some support for
property-based testing. There's no shrinking yet and user-defined
types aren't supported. Right now most if not all primitive types
are, as well as string, wstring, dstring and arrays of any of
them. Here's a simple example that is hopefully self-explanatory:
@("sorting int[] twice yields the same result")
unittest {
import std.algorithm: sort;
check!((int[] a) {
sort(a);
auto b = a.dup;
sort(b);
return a == b;
});
}
Essentially, call `check` with a property function and it will
get run (by default) 100 times with random inputs. Multiple
parameters are supported, but the function must return bool.
I wrote this today to test cerealed, my serialization library:
@Types!(bool, byte, ubyte, short, ushort, int, uint, long, ulong,
float, double,
char, wchar, dchar,
ubyte[], ushort[], int[])
void testEncodeDecodeProperty(T)() {
check!((T val) {
auto enc = Cerealiser();
enc ~= val;
auto dec = Decerealiser(enc.bytes);
return dec.value!T == val;
});
}
That's running 100 auto-generated tests for each of those 17
types, checking that if you serialize and then deserialize you
should get the same value back. Not bad for 12 lines of code, huh?
Destroy!
Atila
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 21:18:28 UTC, Vladimir Panteleev wrote: Generally most use cases for using an image library can be divided into: 1. You have full control over the images being loaded. This is the case when you're loading graphical assets for your application which otherwise doesn't concern itself for graphical work. 2. You're writing an image editor, or some other program that processes images out of your control, i.e. supplied by the user. Generally the first case is by far the most common one (think GUI applications, video games...). In this case, since you already know or have control over the format of your images, there is no reason to burden your application with performance-killing abstraction layers - you should load and work in the format that your images already are. Additionally, if necessary, it is easy to build such a runtime abstraction layer over a templated library by creating an algebraic type from only the set of formats that you want to support. Doing the inverse is impossible. In case anyone from this thread haven't seen it, I have my own image library, which I wrote about here: https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ Hi Vladimir, thanks for your response and explanation. Also wanted to take the opportunity to say that the blog post about your library was one of the biggest motivations for me to pursue D for computer vision. Thanks a tone for your effort! :) Cheers, Relja
