Re: how to assign to shared obj.systime?
On Friday, 10 July 2020 at 03:01:20 UTC, mw wrote: On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote: Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are: /usr/include/dmd/phobos/std/datetime/systime.d(659,17): opAssign()(auto ref const(SysTime) rhs) of course, better without casting. looks like we still have to cast: https://forum.dlang.org/post/lehfwimpolhrmkfmt...@forum.dlang.org as of 2020, sigh.
Re: Send empty assoc array to function
On Friday, 10 July 2020 at 03:59:37 UTC, Mike Parker wrote: On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote: Interesting. Often in D discussion, an argument pops up that the language should be protecting against hidden breakages from API changes. This would be an example of that happening. void foo(int[int] bar), someone calls it with a null, suddenly the signature changes to void foo(int* bar) and you will be sending a null pointer and possibly breaking the app. Meh. You could say the same about foo(int[]), or foo(SomeClass). AAs are reference types. Reference type instances can be null. Besides, when it comes to breakage, the discussions I've seen are about breaking changes in the language/compiler. There are opportunities in most (if not all) programming languages to introduce silent breakage when a library maintainer changes a public-facing API. And when it happens, that's not the fault of the language, but the library maintainer.
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote: Interesting. Often in D discussion, an argument pops up that the language should be protecting against hidden breakages from API changes. This would be an example of that happening. void foo(int[int] bar), someone calls it with a null, suddenly the signature changes to void foo(int* bar) and you will be sending a null pointer and possibly breaking the app. Meh. You could say the same about foo(int[]), or foo(SomeClass). AAs are reference types. Reference type instances can be null.
Re: how to assign to shared obj.systime?
On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote: Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are: /usr/include/dmd/phobos/std/datetime/systime.d(659,17): opAssign()(auto ref const(SysTime) rhs) of course, better without casting.
how to assign to shared obj.systime?
```
import std.datetime;
class A {
SysTime time;
}
void main() {
shared A a = new A();
SysTime time;
a.time = time;
}
```
Error: template std.datetime.systime.SysTime.opAssign cannot
deduce function from argument types !()(SysTime) shared,
candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):
opAssign()(auto ref const(SysTime) rhs)
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 20:08:47 UTC, Anonymouse wrote:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
I always did foo((int[int]).init);
Isn't that just 'null'.
I want to make note that you cannot pass null, modify the aa, and
expect the parent stack to see those changes. Since you aren't
using a variable that is null you are fine.
Re: Unexpected copy constructor behavior
On 7/9/20 6:08 PM, psycha0s wrote:
import std.stdio;
struct Foo {
int value;
this(int n)
{
value = n;
writeln("constuctor ", );
}
~this()
{
writeln("destuctor ", );
}
this(ref return scope Foo other)
{
value = other.value;
writeln("copy constuctor ", );
}
}
void main()
{
writeln("begin");
auto foo1 = Foo(1);
auto foo2 = foo1;
writeln("---");
foo2 = foo1;
writeln("===");
writeln("end");
}
Looking at the generated AST, it's because the compiler is adding an
auto-generated opAssign, which accepts a Foo by value. It is that object
that is being created and destroyed. Your objects aren't moving.
Here is what AST looks like for main:
void main()
{
writeln("begin");
Foo foo1 = foo1 = 0 , foo1.this(1);
try
{
Foo foo2 = foo2 = 0 , foo2.this(foo1);
try
{
writeln("---");
foo2.opAssign(((Foo __copytmp434 = __copytmp434 = 0 ,
__copytmp434.this(foo1);) , __copytmp434));
writeln("===");
writeln("end");
}
finally
foo2.~this();
}
finally
foo1.~this();
return 0;
}
-Steve
Re: Unexpected copy constructor behavior
I just didn't expect that the address of a "this" reference may change.
Unexpected copy constructor behavior
I was learning copy constructors and got a really weird result.
It looks like a copy constructor and a destuctor of two unknown
objects are called. Could somebody please explain it to me?
import std.stdio;
struct Foo {
int value;
this(int n)
{
value = n;
writeln("constuctor ", );
}
~this()
{
writeln("destuctor ", );
}
this(ref return scope Foo other)
{
value = other.value;
writeln("copy constuctor ", );
}
}
void main()
{
writeln("begin");
auto foo1 = Foo(1);
auto foo2 = foo1;
writeln("---");
foo2 = foo1;
writeln("===");
writeln("end");
}
The output:
begin
constuctor A3D3EFF860
copy constuctor A3D3EFF864
---
copy constuctor A3D3EFF880 // <--
destuctor A3D3EFF808 // <--
===
end
destuctor A3D3EFF864
destuctor A3D3EFF860
Re: Send empty assoc array to function
On 7/9/20 5:13 PM, JN wrote: On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote: On 7/9/20 4:04 PM, JN wrote: Hmm, foo(null) seems to work, but is it correct way to do it? Yes, that is correct. Interesting. Often in D discussion, an argument pops up that the language should be protecting against hidden breakages from API changes. This would be an example of that happening. void foo(int[int] bar), someone calls it with a null, suddenly the signature changes to void foo(int* bar) and you will be sending a null pointer and possibly breaking the app. This is a stretch. This means you NEVER call it with an actual associative array (Which would fail to compile), and that foo never expects to get a null pointer. Even if it does break, it breaks by segfaulting and not corrupting your program. All this, plus the author of foo cares nothing for his users, who now suddenly have non-compiling code. -Steve
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer
wrote:
On 7/9/20 4:04 PM, JN wrote:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
Hmm, foo(null) seems to work, but is it correct way to do it?
Yes, that is correct.
-Steve
Interesting. Often in D discussion, an argument pops up that the
language should be protecting against hidden breakages from API
changes. This would be an example of that happening.
void foo(int[int] bar), someone calls it with a null, suddenly
the signature changes to void foo(int* bar) and you will be
sending a null pointer and possibly breaking the app.
Re: Send empty assoc array to function
On 7/9/20 4:31 PM, Max Samukha wrote: On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote: Yes, that is correct. Why isn't [] accepted as an empty AA literal? Because it's an empty dynamic array literal. If D were to accept an empty AA literal, I'd expect it to be [:]. -Steve
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote: Yes, that is correct. -Steve Why isn't [] accepted as an empty AA literal?
Re: Send empty assoc array to function
On 7/9/20 4:04 PM, JN wrote:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
Hmm, foo(null) seems to work, but is it correct way to do it?
Yes, that is correct.
-Steve
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
I always did foo((int[int]).init);
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote: foo( [] ) doesn't Should work in principle, but you can foo(null) to work around.
Re: Send empty assoc array to function
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
Hmm, foo(null) seems to work, but is it correct way to do it?
Send empty assoc array to function
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
Re: What's the point of static arrays ?
On Thursday, 9 July 2020 at 18:51:47 UTC, Paul Backus wrote: Note that using VLAs in C is widely considered to be bad practice, and that they were made optional in the C11 standard. If you want to allocate an array on the stack, the best way is to use a static array for size below a predetermined limit, and fall back to heap allocation if that limit is exceeded. An easy way to do this in D is with `std.experimental.allocator.showcase.StackFront`. I know but I at least really like them because they solve a few obstacles for me. If you have a maximum allowed size, then they should be alright but opinions differ here. I do not recommend allocating a 'max' static size if you don't use just a fraction of it. The reason is that will possibly break out more stack pages than necessary leading to unnecessary memory consumption, especially if you initialize the entire array. This is another reason I like VLAs.
Re: What's the point of static arrays ?
On Thursday, 9 July 2020 at 18:02:02 UTC, IGotD- wrote:
Static arrays are great because as already mentioned, they are
allocated on the stack (unless it is global variable something,
then it ends up in the data segment or TLS area).
As C/C++ now allows dynamically sized static arrays (for stack
only), shouldn't D allow this as well.
Now you have to do.
import core.stdc.stdlib;
void myFunc(size_t arraySize)
{
void *ptr = alloca(arraySize);
ubyte[] arr = cast(ubyte[])ptr[0..arraySize];
}
it would be nice if we could just write
ubyte[arraySize] just like in C.
Note that using VLAs in C is widely considered to be bad
practice, and that they were made optional in the C11 standard.
If you want to allocate an array on the stack, the best way is to
use a static array for size below a predetermined limit, and fall
back to heap allocation if that limit is exceeded. An easy way to
do this in D is with
`std.experimental.allocator.showcase.StackFront`.
Re: What is up with Vibe-d
On Thursday, 9 July 2020 at 18:16:58 UTC, CraigDillabaugh wrote: So is Vibe-d still being actively maintained? I noticed there have been no new releases in a while, and the forums are a bit of a disaster (unless you love porn I suppose): https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ Looks like the latest release was 0.9.0-rc.1, about two weeks ago: https://github.com/vibe-d/vibe.d/releases/tag/v0.9.0-rc.1
Re: What's the point of static arrays ?
On Thu, Jul 09, 2020 at 06:02:02PM +, IGotD- via Digitalmars-d-learn wrote: [...] > Is this the reason that ubyte[arraySize] doesn't create a dynamic > array with size arraySize? > > Now you need to do. > > ubyte[] arr; > arr.length = arraySize; Nah, just do this: arr = new ubyte[arraySize]; Mission accomplished. ;-) T -- I am Ohm of Borg. Resistance is voltage over current.
What is up with Vibe-d
So is Vibe-d still being actively maintained? I noticed there have been no new releases in a while, and the forums are a bit of a disaster (unless you love porn I suppose): https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/
Re: What's the point of static arrays ?
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote:
...
Static arrays are great because as already mentioned, they are
allocated on the stack (unless it is global variable something,
then it ends up in the data segment or TLS area).
As C/C++ now allows dynamically sized static arrays (for stack
only), shouldn't D allow this as well.
Now you have to do.
import core.stdc.stdlib;
void myFunc(size_t arraySize)
{
void *ptr = alloca(arraySize);
ubyte[] arr = cast(ubyte[])ptr[0..arraySize];
}
it would be nice if we could just write
ubyte[arraySize] just like in C.
Now this operation is not safe, but could be allowed in @system
code.
Is this the reason that ubyte[arraySize] doesn't create a dynamic
array with size arraySize?
Now you need to do.
ubyte[] arr;
arr.length = arraySize;
Like ubyte[arraySize] is reserved for the same usage as in C.
Re: Working with pointers/adresses
On Thu, Jul 09, 2020 at 05:24:33PM +, matheus via Digitalmars-d-learn wrote:
[...]
> I wonder if the question was more like intended to display the value
> using pointers, ie:
>
> import std.stdio;
>
> void main(){
> int i;
> readf("%d\n", i);
> int *p =
> writeln(*p);
> }
>
> Because accessing arbitrary memory location seems very weird.
[...]
Unless the goal was to write an OS? ;-)
T
--
It only takes one twig to burn down a forest.
Re: Working with pointers/adresses
On Thursday, 9 July 2020 at 17:24:33 UTC, matheus wrote:
On Wednesday, 8 July 2020 at 20:33:39 UTC, Paul Backus wrote:
import std.stdio;
void main()
{
int i;
readf("%d\n", i); // read a number
ubyte* p = cast(ubyte*) i; // convert it to a pointer
writeln(*p); // write the data at that address to the
console
}
Note that this program will almost certainly crash if you try
to run it, since modern computers do not allow programs to
read and write arbitrary memory locations.
I wonder if the question was more like intended to display the
value using pointers, ie:
import std.stdio;
void main(){
int i;
readf("%d\n", i);
int *p =
writeln(*p);
}
Because accessing arbitrary memory location seems very weird.
Matheus.
Or maybe he wanted to do this:
import std.stdio;
void main(){
int i;
readf("%d\n", i);
ulong address = cast(ulong)
ubyte* p = cast(ubyte*)address;
writeln(*p);
}
Matheus.
Re: Working with pointers/adresses
On Wednesday, 8 July 2020 at 20:33:39 UTC, Paul Backus wrote:
import std.stdio;
void main()
{
int i;
readf("%d\n", i); // read a number
ubyte* p = cast(ubyte*) i; // convert it to a pointer
writeln(*p); // write the data at that address to the
console
}
Note that this program will almost certainly crash if you try
to run it, since modern computers do not allow programs to read
and write arbitrary memory locations.
I wonder if the question was more like intended to display the
value using pointers, ie:
import std.stdio;
void main(){
int i;
readf("%d\n", i);
int *p =
writeln(*p);
}
Because accessing arbitrary memory location seems very weird.
Matheus.
Re: What's the point of static arrays ?
On Thursday, July 9, 2020 10:21:41 AM MDT H. S. Teoh via Digitalmars-d-learn wrote: > > - Assignment copies the whole array, as in int[5] a; auto b = a; > > Sometimes this is desirable. Consider the 3D game example. Suppose > you're given a vector and need to perform some computation on it. If it > were a dynamic array, you'd need to allocate a new array on the heap in > order to work on it without changing the original vector. With a static > array, it's passed by value to your function, so you just do what you > need to do with it, and when you're done, either discard it (== no work > because it's allocated on the stack) or return it (== return on the > stack, no allocations). I recall that at one point, I wrote brute-force sudoku solver, and initially, I'd used dynamic arrays to represent the board. When I switched them to static arrays, it was _way_ faster - presumably, because all of those heap allocations were gone. And of course, since the sudoku board is always the same size, the ability to resize the array was unnecessary. In most programs that I've written, it hasn't made sense to use static arrays anywhere, but sometimes, they're exactly what you need. - Jonathan M Davis
Re: Working with pointers/adresses
On Thursday, 9 July 2020 at 16:16:53 UTC, Quantium wrote: I have one more question. I tested the programm, as you said, it worked rarely because of OS restrictions. If I compile that code to dll, and run it through dll launcher, should it work? The OS restrictions don't care whether your program is in a dll or not, so you will get more or less the same results (though the specific addresses that do and don't work might change).
Re: Working with pointers/adresses
On Thu, Jul 09, 2020 at 04:16:53PM +, Quantium via Digitalmars-d-learn wrote: > I have one more question. I tested the programm, as you said, it > worked rarely because of OS restrictions. If I compile that code to > dll, and run it through dll launcher, should it work? No, it's subject to the same restrictions. Why should it be otherwise? T -- Let's call it an accidental feature. -- Larry Wall
Re: What's the point of static arrays ?
On Thu, Jul 09, 2020 at 12:12:06PM +, wjoe via Digitalmars-d-learn wrote: > + The size is known at compile time. > > vs. > > - Can neither grow nor shrink them > - Can't append elements > - Can't remove elements Consider a 3D game in which you represent vectors as static arrays of 4 elements (homogenous representation). In this case, it's a plus to not be able to append/remove elements, because the rest of the code expects vectors that are exactly 4 elements long. > - Can't slice them > - Can't range them Sure you can. > - Assignment copies the whole array, as in int[5] a; auto b = a; Sometimes this is desirable. Consider the 3D game example. Suppose you're given a vector and need to perform some computation on it. If it were a dynamic array, you'd need to allocate a new array on the heap in order to work on it without changing the original vector. With a static array, it's passed by value to your function, so you just do what you need to do with it, and when you're done, either discard it (== no work because it's allocated on the stack) or return it (== return on the stack, no allocations). > - Size is limited by stack > - Stack overflow issues You *can* allocate static arrays on the heap, in which case they become closer to dynamic arrays. Generally, the cases for which static arrays are useful are when the size isn't huge; for huge arrays it makes more sense to just use dynamic arrays. You can also have classes that contain large static arrays: in this case, the usefulness comes from having the array embedded in the class object itself, rather than being a separate heap allocation + another level of indirection. [...] > Considering the many downsides why would I ever want to choose a > static over a dynamic array ? It depends on your needs. If you know you're always going to be trading in vectors of a fixed size, like 4-element vectors in aforementioned 3D game, then there's no need to put extra GC (or whatever allocator) pressure on your code, just trade in T[4]. You also skip bounds checks in many cases, since the length is known at compile-time. You get by-value semantics, which is generally much easier to reason about than by-reference semantics. You avoid an extra level of indirection, which can matter in hotspots. If your arrays are going to change in length, then static arrays aren't what you need; just use dynamic arrays. They serve different purposes. T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Re: Working with pointers/adresses
I have one more question. I tested the programm, as you said, it worked rarely because of OS restrictions. If I compile that code to dll, and run it through dll launcher, should it work?
Re: What's the point of static arrays ?
On 7/9/20 5:12 AM, wjoe wrote:
Considering the many downsides why would I ever want to choose a static
over a dynamic array ?
In addition to what others said, dynamic arrays can be more expensive
both in space and time.
Time: Dynamic array elements are accessed through an extra pointer
compared to static arrays. Depending on the usage pattern of the data,
that extra indirection may be slower (e.g. due to the extra load on the
CPU's cache).
Space: Every dynamic array is represented by the pair of one pointer
(void*) one length (size_t) e.g. 2 * 8 = 16 bytes on a 64-bit system.
Assuming the array is just 3 floats, which is a common type used for
RGB, 3D coordinates, etc. (3 * 4 = 12 bytes), then those 16 bytes are
more than the data itself.
I wrote the following program (as a fun morning exercise, before coffee
:o) ) to display bytes used by different kinds of variables:
import std.stdio;
import std.range;
import std.algorithm;
import std.traits;
size_t bytesUsed(T)(T var) {
static if (isDynamicArray!T) {
enum dynamicArrayOverhead = (void[]).sizeof;
// Double check:
static assert (dynamicArrayOverhead == size_t.sizeof + (void*).sizeof);
return dynamicArrayOverhead + var.map!(element =>
bytesUsed(element)).sum;
} else static if (isAssociativeArray!T) {
static assert (false, "I don't know the implementation of AAs.");
} else static if (is (T == struct)) {
// BUG: Ignores alignment
size_t total;
foreach (member; var.tupleof) {
total += bytesUsed(member);
}
return total;
} else static if (is (T == class)) {
// BUG: Ignores alignment
size_t total;
foreach (member; var.tupleof) {
total += bytesUsed(member);
}
enum classOverhead = (void*).sizeof * 2;
return classOverhead + total;
} else {
return var.sizeof;
}
// BUG: union?
}
unittest {
struct S {
int[] arr;
void* ptr;
}
assert(bytesUsed(S([1, 2, 3])) == size_t.sizeof + (void*).sizeof + 3
* int.sizeof + 8);
}
void info(alias var)() {
writefln!"'%s' is %s and uses %s bytes."(var.stringof,
typeof(var).stringof, bytesUsed(var));
}
void main() {
// This is an efficient data structure:
alias Color = float[3]; // red, green, blue
alias DayColors = Color[7];
// Comparing it to the dynamic array equivalent:
DayColors a;
auto b = makeDayColors();
info!a;
info!b;
}
float[] makeColor() {
// Syntax confusion alert: Return type is *not* a static array. :/
return new float[3];
}
float[][] makeDayColors() {
float[][] result = new float[][7];
foreach (ref e; result) {
e = makeColor();
}
return result;
}
Ali
Re: What's the point of static arrays ?
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote: Also GC but it's possible to make a dynamic array implementation which avoids the GC. It's easy to make a dynamic array without using the GC. Did you mean "implementation which avoids memory management"? I'm not considering supposed performance benefits/penalties because these need to be profiled. Considering the many downsides why would I ever want to choose a static over a dynamic array ? Sometimes the amount of elements is known at compile time so you don't need to waste CPU cycles for memory allocation/freeing. This can be really important when you work on a performance-critical code.
Re: What's the point of static arrays ?
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote:
I'm not considering supposed performance benefits/penalties
because these need to be profiled.
Considering the many downsides why would I ever want to choose
a static over a dynamic array ?
Simply put: static arrays are not dynamic arrays, and if you try
to use one as the other you're going to be disappointed.
Usually, you use static arrays when you interface with something
else that does it - generally a file format or a C library. For
the most part you're right, you should probably use a dynamic
array instead.
Now, as for your points:
- Can neither grow nor shrink them
- Can't append elements
- Can't remove elements
These are the same as the first point.
- Can't slice them
- Can't range them
Sure you can:
unittest {
import std.stdio;
import std.algorithm;
int[10] a = [1,2,3,4,5,6,7,8,9,10];
// Note I'm slicing the static array to use in range
algorithms:
writeln(a[].map!(b => b+2));
// Slicing works:
auto b = a[3..6];
b[] = 7;
writeln(a);
}
- Assignment copies the whole array, as in int[5] a; auto b = a;
This is often a factor in choosing a static array. It's not
better or worse, just different. And sometimes it's different in
exactly the way you need.
- Size is limited by stack
- Stack overflow issues
So allocate your static array on the heap if this is a problem?
Some of the cons could be considered a feature.
Also GC but it's possible to make a dynamic array
implementation which avoids the GC.
Basically none of the drawbacks you refer to are actual
drawbacks, but instead part of what makes static arrays useful.
Static arrays are not a poor man's dynamic arrays, they're a
different beast, doing different things.
--
Simen
What's the point of static arrays ?
+ The size is known at compile time. vs. - Can neither grow nor shrink them - Can't append elements - Can't remove elements - Can't slice them - Can't range them - Assignment copies the whole array, as in int[5] a; auto b = a; - Size is limited by stack - Stack overflow issues Some of the cons could be considered a feature. Also GC but it's possible to make a dynamic array implementation which avoids the GC. I'm not considering supposed performance benefits/penalties because these need to be profiled. Considering the many downsides why would I ever want to choose a static over a dynamic array ?
Re: App/lib config system
On Thursday, 9 July 2020 at 06:57:22 UTC, Kagamin wrote: If you suspect there's a contradiction in requirements, you need to specify them with better precision. What are the contradictions in the requirements? I don't see any. -- /Jacob Carlborg
Re: App/lib config system
If you suspect there's a contradiction in requirements, you need to specify them with better precision.
