Re: How my little brother try D

[Walter Bright via Digitalmars-d]

On 4/2/2016 2:29 PM, Daniel Kozak wrote:

And probably we should fixed copy method to not remove files with same
src and dst path :)


https://issues.dlang.org/show_bug.cgi?id=15865

[Issue 15865] std.file.copy(from, to) deletes the file if from and to specify the same file

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15865

Walter Bright  changed:

   What|Removed |Added

URL||https://github.com/D-Progra
   ||mming-Language/phobos/blob/
   ||master/std/file.d#L3181

--

[Issue 15865] New: std.file.copy(from,to) deletes the file if from and to specify the same file

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15865

  Issue ID: 15865
   Summary: std.file.copy(from,to) deletes the file if from and to
specify the same file
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

It does this because on non-Windows systems, the implementation creates the
'to' file before reading the 'from' file.

Severity bumped to 'major' because deleting files is not nice.

--

Re: How my little brother try D

[jmh530 via Digitalmars-d]

On Saturday, 2 April 2016 at 22:54:09 UTC, Lass Safin wrote:


You're right in how it isn't obvious for non-techy people. I do 
suppose it would be doable without breaking any old code 
(unless for some arcane reason the code depends on static 
assert(!__traits(allMember, std.file).canFind("move"))...), so 
why not create a PR with "alias move = rename" inside?


If I were looking at the documentation with fresh eyes, I would 
be just as confused as the OP's brother. It's not about being 
non-techy. Someone had an issue with the documentation and 
commenting on their inexperience won't improve the documentation. 
The documentation has no examples. It doesn't mention file paths 
at all. I.e., easy to get confused.


Moreover, posix systems have mv, which can move and rename. mv is 
a crappy name, but at least if the function would have the same 
semantics as mv, they could have named it move instead of rename. 
Seems like a silly breaking change at this point, so they should 
just improve the docs.

Re: string to uppercase

[Nicholas Wilson via Digitalmars-d-learn]

On Sunday, 3 April 2016 at 03:05:08 UTC, stunaep wrote:
Is there any easy way to convert a string to uppercase? I tried 
s.asUpperCase, but it returns a ToCaserImpl, not a string, and 
it cant be cast to string. I also tried toUpper but it wasnt 
working with strings


asUpperCase returns a range that you can iterate over like
auto upper = someString.asUpperCase;
foreach(c; upper)
{
 //do stuff
}

toUpper works with both characters (standard, w and d) as well as 
(w|d| )strings, please post the use case that doesn't work.


There is also toUpperInPlace that will modify the string.

Nic

string to uppercase

[stunaep via Digitalmars-d-learn]

Is there any easy way to convert a string to uppercase? I tried 
s.asUpperCase, but it returns a ToCaserImpl, not a string, and it 
cant be cast to string. I also tried toUpper but it wasnt working 
with strings

Decompressing bzip2

[stunaep via Digitalmars-d-learn]

I am trying to use the bzip2 bindings that are available on 
code.dlang.org/packages, but I am having a really hard time using 
it due to the pointers. It needs to be an array once it's 
decompressed.


Here is what I have:

import std.stdio;
import bzlib;

void main(string[] args)
{

   File f = File("./test.bz2");
   ubyte[] data = new ubyte[f.size];
  f.rawRead(data);
   writeln(data);

   ubyte* output;
   uint avail_out;
   bz_stream* stream = new bz_stream();
   stream.avail_out = avail_out;
   stream.next_out = output;

   int init_error = BZ2_bzDecompressInit(stream, 0, 0);
   int bzipresult = BZ2_bzDecompress(stream);

   stream.avail_in = cast(uint) data.length;
   stream.next_in = cast(ubyte*) data;

   bzipresult = BZ2_bzDecompress(stream);
   int read = stream.total_out_lo32;
   BZ2_bzDecompressEnd(stream);
   delete stream;
   writeln(output);
}


It's not working at all so any help would be very much 
appreciated.

Re: We gunna be rich

[Charles via Digitalmars-d]

On Saturday, 2 April 2016 at 19:12:19 UTC, Suliman wrote:
Do you have any plans to public 2 edition of The D Programming 
Language book?


I'd buy it.

Re: We gunna be rich

[Lass Safin via Digitalmars-d]

On Saturday, 2 April 2016 at 21:03:28 UTC, Patience wrote:
On Saturday, 2 April 2016 at 15:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello all, I've created an Amazon Affiliates link for the D 
Language Foundation (dlang-20). Subsequently I've changed 
https://wiki.dlang.org/Books to use it. Please follow up with 
changing dlang.org to also use the links, and also let me know 
if you need affiliate links for any other products. Thanks! -- 
Andrei


Wait, how is this going to make me be rich? I think you left 
that part out?


1. More money for Developers (pun heavily intended)
2. More incentive to work
3. Better language
4. More people know about it
5. You're now a computer wizard and everyone's trying to hire you
6. Profit

Re: How my little brother try D

[Lass Safin via Digitalmars-d]

On Saturday, 2 April 2016 at 21:29:27 UTC, Daniel Kozak wrote:
Few days ago, my little brother (13 years old) ask me about 
writing some small utility. He needed find all files with 
selected extensions and move them to some another location. He 
asked me about using D or C# for it. My answer was: try both 
and you will see which one suited you better.

[...]
Maybe it would be nice to have alias for rename method or have 
better doc for rename. And probably we should fixed copy method 
to not remove files with same src and dst path :)


You're right in how it isn't obvious for non-techy people. I do 
suppose it would be doable without breaking any old code (unless 
for some arcane reason the code depends on static 
assert(!__traits(allMember, std.file).canFind("move"))...), so 
why not create a PR with "alias move = rename" inside?

How my little brother try D

[Daniel Kozak via Digitalmars-d]

Few days ago, my little brother (13 years old) ask me about 
writing some small utility. He needed find all files with 
selected extensions and move them to some another location. He 
asked me about using D or C# for it. My answer was: try both and 
you will see which one suited you better.


After few hours he came to me and said that C# is better. When I 
asked why he answered me that in D there is no std.file.move 
method (I know there is a rename method but it is not obvious) so 
he has to use std.file.copy and std.file.remove. And when he try 
it with just std.file.copy (so he does not use remove yet) he end 
up with remove all files anyway. When std.file.copy is used with 
same src and dst (this was caused by anoher mistake) it removes 
original file and does not make the new one.


Maybe it would be nice to have alias for rename method or have 
better doc for rename. And probably we should fixed copy method 
to not remove files with same src and dst path :)

Re: We gunna be rich

[Patience via Digitalmars-d]

On Saturday, 2 April 2016 at 15:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello all, I've created an Amazon Affiliates link for the D 
Language Foundation (dlang-20). Subsequently I've changed 
https://wiki.dlang.org/Books to use it. Please follow up with 
changing dlang.org to also use the links, and also let me know 
if you need affiliate links for any other products. Thanks! -- 
Andrei


Wait, how is this going to make me be rich? I think you left that 
part out?

Re: We gunna be rich

[Pradeep Gowda via Digitalmars-d]

On Saturday, 2 April 2016 at 15:43:53 UTC, Andrei Alexandrescu 
wrote:

D  Language Foundation (dlang-20).


There are a couple of things that we can do to increase awareness 
of the Foundation and ways to contribute to it:


1. Link to the foundation website. (do we have one?)
2. On the foundation website/page provide information on how to 
contribute to the foundation, including but not limited to paying 
by paypal, and monthly subscriptions. I donate regularly to a 
charitable foundation this way and in my opinion, the easiest way 
to give money.
3. Add the link to the Foundation website in the "Community" 
drop-down menu on the top-navigation.

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[jkpl via Digitalmars-d-learn]

On Saturday, 2 April 2016 at 18:32:03 UTC, Steven Schveighoffer 
wrote:
I honestly think you are better off just generating random 
arrays, even if it results in some overlap (unlikely to be 
relevant).


-Steve


Yes I know, I've realized how it's silly. just foreach(xn; 0 .. 
range) foreach(xn; 0 .. range) foreach(xn; 0 .. range) 
foreach(xn; 0 .. range) is enough. But still silly in term of 
complexity. I have to go for a heuristic approach. UNtil that I 
still use a prng.

Re: We gunna be rich

[Suliman via Digitalmars-d]

On Saturday, 2 April 2016 at 15:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello all, I've created an Amazon Affiliates link for the D 
Language Foundation (dlang-20). Subsequently I've changed 
https://wiki.dlang.org/Books to use it. Please follow up with 
changing dlang.org to also use the links, and also let me know 
if you need affiliate links for any other products. Thanks! -- 
Andrei


Do you have any plans to public 2 edition of The D Programming 
Language book?

Re: Address of an element of AA

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/2/16 10:22 AM, Temtaime wrote:

Hi !
I can't find this in specs.

If i add an element to AA:
aa[10] = 123;

Will [10] be always the same (of course i don't remove that key) ?

Thanks for a reply.
I think specs should be enhanced.


Depends on your definition of "always". As long as you don't add or 
remove keys, it will remain at the same place. Adding other keys can 
cause a rehash, and removing keys (even if it isn't that one) can cause 
a rehash.


Note: in the current implementation, it WILL remain in the same 
location, even on a rehash. This is because the AA is implemented as an 
array of pointers to elements. A rehash does not reallocate the 
elements. But this is NOT guaranteed to stay this way in the future.


Note: reason the spec does not say this is because we don't want to 
constrain the implementation to behave a certain way.


-Steve

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/2/16 5:47 AM, jkpl wrote:

gives: core.exception.OutOfMemoryError@src/core/exception.d(693): Memory
allocation failed



Probably because randomCover needs to allocate a bool for all the 
elements it has already covered, so you are allocating 32 * 4G bools. 
How much RAM do you have? Note that D's GC is conservative, so false 
pointers, especially for large arrays also can cause problems.


I'll note that even if it worked, this code will never complete in your 
lifetime, or even your great great grandchild's lifetime. I don't 
understand the point of doing this.


I'll also note that if you just want to test a *subset* of all the 
possible inputs (given the length of time taken to test all these), you 
probably want to change different elements each time through the loop. 
Your code spends a long time testing the same elements in the first 
slots. Given your test code is just looking at the first element, this 
isn't very good test coverage.


I honestly think you are better off just generating random arrays, even 
if it results in some overlap (unlikely to be relevant).


-Steve

Best way to explicitly control the attributes of a template function

[tsbockman via Digitalmars-d]

Jack Stouffer and I have been working on a pull request for 
Phobos to enable runtime dispatch for field and property access:

https://github.com/D-Programming-Language/phobos/pull/4070
(It's useful when directly porting code from dynamic languages 
like Python.)


Working with fields in this fashion is pretty easy, but I've hit 
a snag for property methods: if even one of the available 
property methods is impure, unsafe, etc., then the dispatch 
function must also be impure/unsafe/whatever.


In order for the dispatch function to be usable in 
pure/@safe/etc. code, it needs to filter out those property 
methods which are not. This is simple enough - except that 
*which* attributes are required cannot be inferred from the 
context; it must be explicitly specified by the user of the 
dispatch template - somehow...


A naive way to do it would be this:

template example(string attrs = "pure @safe nothrow @nogc")
{
mixin("void example() " ~ attrs ~ " { /* do something */ 
}");

}

Which could then be used like this:

example!"pure @safe @SomeUDA"();

That's pretty ugly though, since it requires that all template 
functions with explicit attribute control be implemented as 
string mixins.


Is there a better way to do this? If not, I think consideration 
should be given (long-term) to adding an "attribute set" 
construct as a new type of template parameter.

Re: Any reason as to why this isn't allowed?

[Lass Safin via Digitalmars-d]

On Saturday, 2 April 2016 at 16:58:14 UTC, Paul O'Neil wrote:

On 04/02/2016 09:02 AM, Lass Safin wrote:

class C {
 ~this() {}
 immutable ~this() {}
}

This gives a conflict error between the two destructors.


What do you expect the difference to be?  I'm not sure what I 
expect the semantics of destroying an immutable object to be.


It's more that I wish the immutable destructor to be empty, thus 
never destroying it properly.


I just don't really see the reason as to why we can have 
immutable and mutable constructors but not immutable and mutable 
destructors.


Though currently it is possible if I create two functions, one 
immutable and one not, then set the value inside the vtable 
manually within two constructors, again, one immutable and one 
not.

Re: Any reason as to why this isn't allowed?

[Paul O'Neil via Digitalmars-d]

On 04/02/2016 09:02 AM, Lass Safin wrote:

class C {
 ~this() {}
 immutable ~this() {}
}

This gives a conflict error between the two destructors.


What do you expect the difference to be?  I'm not sure what I expect the 
semantics of destroying an immutable object to be.

Re: We gunna be rich

[Jack Stouffer via Digitalmars-d]

On Saturday, 2 April 2016 at 15:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello all, I've created an Amazon Affiliates link for the D 
Language Foundation (dlang-20). Subsequently I've changed 
https://wiki.dlang.org/Books to use it. Please follow up with 
changing dlang.org to also use the links, and also let me know 
if you need affiliate links for any other products. Thanks! -- 
Andrei


Does the D Language Foundation work with Amazon Smile?

Re: Could we reserve void[T] for builtin set of T ?

[Andrei Alexandrescu via Digitalmars-d]

On 04/01/2016 02:29 PM, Jonathan M Davis via Digitalmars-d wrote:

On Friday, April 01, 2016 15:52:49 matovitch via Digitalmars-d wrote:

Indeed, just wanted to point that out. (I guess that's why the
set was introduced before the unordered one in the c++ stl as
well). I feel like containers are an old topic. Last time I asked
I was told : wait for the allocators. What is the advancement on
this side ? Are there any plan at writing more containers for
phobos ? (I know that I am in the bad position of
complaining...but if there is no obstacle...I am ready to write a
draft of hashset in D, although surely not to phobos standards)


Now that Andrei has finished the allocators, he's redesigning the
containers, and supposedly, std.container is going to be replaced with what
he's working on (it'll probably called something like std.collection). How
far along he is, or when he'll actually present anything approaching a final
design, I don't know. He's posted a container or two for discussion
previously, but they were more esoteric things, and he was clearly still
working on a lot of the overall design of how the containers in general
would be put together (e.g. how they would handle Big-O in their API). Once
Andrei is farther along, I'm sure that he'll be looking for contributions
towards filling out a full set of containers based on his general container
API, but for now I'd suggest that folks just use the EMSI containers.


Work on containers has been on hold for three reasons:

1. Paper submission to a conference (more details soon)

2. DConf organizing stuff

3. RCString work, which can proceed in the current language

4. Work on a DIP that allows safe reference counting.

I am confident we'll have good results for all of the above (and 
containers too).



Andrei

Re: No aa.byKey.length?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, April 02, 2016 15:38:30 Ozan via Digitalmars-d-learn wrote:
> On Friday, 1 April 2016 at 20:50:32 UTC, Yuxuan Shui wrote:
> > Why?
> >
> > This is annoying when I need to feed it into a function that
> > requires hasLength.
>
> aa.keys.length

That allocates an array. Doing that would be like doing
aa.byKeys().array().length. And associate arrays already have length. You
can do

auto len = aa.length;

The problem is when you want to operate on a range, and the function that
you want to pass it to wants length on the range. If byKeys returned a range
with length, then that would work, but since it doesn't, it doesn't. Having
other ways to get the length doesn't help.

- Jonathan M Davis

[Issue 9797] to!int() cannot convert hexadecimal numbers

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9797

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #6 from Jonathan M Davis  ---
I would point out that while to!int("0x123"); isn't going to work,
to!int("123", 16); will. e.g.

import std.conv;

void main()
{
auto str = to!string(42, 16);
assert(str == "2A", str);
auto i = to!int(str, 16);
assert(i == 42);
}

So, if you check for 0x and strip it off before feeding the string to to!int,
then it will do the conversion. It just won't work with the prefix on it. And
while having to!int check for the prefix as well as anything else that's valid
in a numeric literal in D might be nice in some cases, it would slow down
to!int for everything else, which really isn't a good tradeoff given how much
to!int is used. A conversion function specifically for literals might make
sense, but I have to concur that doing it with std.conv.to isn't worth it.

--

Re: Can we check the arguments to format() at compile time?

[Andrei Alexandrescu via Digitalmars-d]

On 04/01/2016 07:26 PM, Alex Parrill wrote:

On Friday, 1 April 2016 at 21:25:46 UTC, Yuxuan Shui wrote:

Clang has this nice feature that it will warn you when you passed
wrong arguments to printf:

#include 
int main(){
long long u = 10;
printf("%c", u);
}

clang something.c:
something.c:4:15: warning: format specifies type 'int' but the
argument has type 'long long' [-Wformat]

With the CTFE power of D, we should be able to do the same thing when
the format string is available at compile time. Instead of throwing
exceptions at run time.


Not as-is, because the format string is a runtime argument and not a
compile-time constant.

Consider:

 writefln(rand() >= 0.5 ? "%s" : "%d", 123);

It's certainly possible with a new, templated writef function.
Hypothetically:

 writefln_ctfe!"%s"(1234); // would fail


What happened to the work that added a compile-time string to writef? -- 
Andrei

We gunna be rich

[Andrei Alexandrescu via Digitalmars-d]

Hello all, I've created an Amazon Affiliates link for the D Language 
Foundation (dlang-20). Subsequently I've changed 
https://wiki.dlang.org/Books to use it. Please follow up with changing 
dlang.org to also use the links, and also let me know if you need 
affiliate links for any other products. Thanks! -- Andrei

Re: No aa.byKey.length?

[Ozan via Digitalmars-d-learn]

On Friday, 1 April 2016 at 20:50:32 UTC, Yuxuan Shui wrote:

Why?

This is annoying when I need to feed it into a function that 
requires hasLength.


aa.keys.length

Re: Address of an element of AA

[Ozan via Digitalmars-d-learn]

On Saturday, 2 April 2016 at 14:22:01 UTC, Temtaime wrote:

Hi !
I can't find this in specs.

If i add an element to AA:
aa[10] = 123;

Will [10] be always the same (of course i don't remove that 
key) ?


Thanks for a reply.
I think specs should be enhanced.


Running following

int aa[int];

aa[10] = 123;
auto p = [10];
writeln(*p);

aa[11] = 121; // add Element
writeln(*p);

aa[10] = 1; // change Element
writeln(*p);

aa.rehash; // reorganize
writeln(*p);

aa.remove(10);
aa[10] = 3; // remove & add Element
writeln(*p);

results in

123 // correct
123 // correct
1 // correct
1 // correct because I'm lucky
1 // wrong

What Alis said is "rehash", a combination of remove/add or any 
other reorganisation, which could change memory usage and data 
locations.

By the way...why do you need a pointer to an AA-Element?

Regards, Ozan

[Issue 15859] opApply resolution on attributes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15859

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull, rejects-valid
   Hardware|x86_64  |All
   Severity|minor   |normal

--- Comment #2 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5621

--

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[Ali Çehreli via Digitalmars-d-learn]

[Probably a repost.]

On 04/02/2016 01:20 AM, jkpl wrote:

Let's say I have a ubyte[256]. I want to test all the possible values
this array can have on a function.


nextPermutation():

  https://dlang.org/phobos/std_algorithm_sorting.html#nextPermutation

Ali

Re: Address of an element of AA

[Ali Çehreli via Digitalmars-d-learn]

On 04/02/2016 07:22 AM, Temtaime wrote:

Hi !
I can't find this in specs.

If i add an element to AA:
aa[10] = 123;

Will [10] be always the same (of course i don't remove that key) ?

Thanks for a reply.
I think specs should be enhanced.


No, the underlying buffer can be relocated when the hash table is 
reconstructed e.g. when there are sufficiently many elements in the array.


Ali

Re: Can we check the arguments to format() at compile time?

[Johan Engelen via Digitalmars-d]

On Friday, 1 April 2016 at 21:25:46 UTC, Yuxuan Shui wrote:
Clang has this nice feature that it will warn you when you 
passed wrong arguments to printf:


#include 
int main(){
long long u = 10;
printf("%c", u);
}

clang something.c:
something.c:4:15: warning: format specifies type 'int' but the 
argument has type 'long long' [-Wformat]


With the CTFE power of D, we should be able to do the same 
thing when the format string is available at compile time. 
Instead of throwing exceptions at run time.


I thought LDC already did that when `-check-printf-calls` is 
passed, but the implementation is unfinished and it does not do 
any checking at the moment.

Re: "Squash and merge" on GitHub

[Kagamin via Digitalmars-d]

Wasn't there the "Committed of behalf" feature?

[Issue 15864] chmgen triggers exception in std.regex

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15864

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #1 from Dmitry Olshansky  ---
Would love to have regex pattern as test case.

--

Address of an element of AA

[Temtaime via Digitalmars-d-learn]

Hi !
I can't find this in specs.

If i add an element to AA:
aa[10] = 123;

Will [10] be always the same (of course i don't remove that 
key) ?


Thanks for a reply.
I think specs should be enhanced.

Re: "Squash and merge" on GitHub

[Jonathan M Davis via Digitalmars-d]

On Saturday, April 02, 2016 01:18:47 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 4/2/16 12:36 AM, Jack Stouffer wrote:
> > On Saturday, 2 April 2016 at 03:58:27 UTC, Daniel Murphy wrote:
> >> On 2/04/2016 7:28 AM, Vladimir Panteleev wrote:
> >>> 4. We should use the autotester's auto-merge feature anyway.
> >>
> >> Can we disable both and force everyone to use the autotester?
> >
> > Yes, you can take away everyone but the auto-tester's merge rights.
>
> Actually that might be a good setup. We'd need an escape hatch for a
> small circle, and control over the autotester. Also we'd need to make
> the autotester work with all repos. -- Andrei

While it sounds like a good idea in theory, I question that it's worth it.
Almost always, committers are already merging using the autotester, so I
don't think that we actually have a problem here. And there are definitely
cases where you _need_ to merge stuff without the autotester (primarily
because you end up with commits in different repos that depend on each other
to avoid breaking the build). The "small circle" with full commit access
would presumably solve that problem, but then you'd be stuck waiting for
them whenever there was a set of PRs in that boat, which risks creating
another bottleneck. In practice, in may not be a problem (especially since
PRs like that are fairly rare, and they usually involve folks who would
probably be in the small circle anyway), but since we don't really have a
problem with folks skipping the autotester, I'm not sure that it's worth
going through the trouble.

Another thing to consider is that - as Vladimir points out - currently the
autotester commits with the commiter's account and not with a separate one,
and that's not just an implementation issue. It's also an accountability
issue. Right now, because of how the autotester does the merge, you can see
who did it in the commit log. But if the autotester does the commit with its
own account, how do you then figure out who did the merge? Would we have to
have a separate log in the autotester to tell us? Do you have to know which
PR it went with to see the comment in github? Right now, if a committer
starts misbehaving, you can easily see that in the commit logs, and it's
easy to see their name in the messages that github sends when a merge is
done. We lose that if the autotester merges with its own account.

So, I'm inclined to think that while forcing the restriction on merging via
the autotester might be a good idea on the surface, it's actually a bad idea
when you get down to the details. And enforcing it via social policy has
worked well overall thus far.

- Jonathan M Davis

Any reason as to why this isn't allowed?

[Lass Safin via Digitalmars-d]

class C {
~this() {}
immutable ~this() {}
}

This gives a conflict error between the two destructors.

Re: Units of Measurement Library: units-d

[crimaniak via Digitalmars-d-announce]

On Friday, 1 April 2016 at 22:54:53 UTC, Simen Kjaeraas wrote:

...
I kinda agree. And looking at 
https://dlang.org/spec/traits.html, I see there's __MODULE__, 
which would probably be a better choice than __FILE__.


 I think adding something like __UNIQUE_NAME__ to predefined 
constants will allow to avoid all these perversions. The only 
thing to think here about uniqueness scope.

[Issue 15864] New: chmgen triggers exception in std.regex

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15864

  Issue ID: 15864
   Summary: chmgen triggers exception in std.regex
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: blocker
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

chmgen
Processing 32-64-portability.html
Error while processing file: ./32-64-portability.html

core.exception.AssertError@std\regex\internal\parser.d(1487): Assertion failure

0x004460BB in _d_assert
0x004206AD in void std.regex.internal.parser.optimize!(char).optimize(ref
std.regex.internal.ir.Regex!(char).Regex) at C:\Users\vagr
ant\clones\dmd\src\..\..\phobos\std\regex\internal\parser.d(1533)
0x0041D647 in @trusted void
std.regex.internal.parser.lightPostprocess!(char).lightPostprocess(ref
std.regex.internal.ir.Regex!(char
).Regex) at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\regex\internal\parser.d(1444)
0x0041D172 in @safe std.regex.internal.ir.Regex!(char).Regex
std.regex.internal.parser.makeRegex!(immutable(char)[]).makeRegex(std.regex.internal.parser.Parser!(immutable(char)[]).Parser)
at C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\regex\internal\parser.d(33)
0x0041272C in @property @safe std.regex.internal.ir.Regex!(char).Regex
std.regex.internal.parser.Parser!(immutable(char)[]).Parser.program() at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\regex\internal\parser.d(1370)
0x0040E25C in @safe std.regex.internal.ir.Regex!(char).Regex
std.regex.regexImpl!(immutable(char)[]).regexImpl(immutable(char)[],
const(char)[]) at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\regex\package.d(326)
0x0042116B in D3std10functional114__T7memoizeS95 at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\functional.d(1039)
0x0040E205 in @trusted std.regex.internal.ir.Regex!(char).Regex
std.regex.regex!(immutable(char)[]).regex(immutable(char)[], const(char)[]) at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\regex\package.d(318)
0x004337EA in
D6chmgen106__T2reVAyaa43_283c6120283f3a283f3a5c772b3d5c225b5e225d2a5c22293f5c732a292a687265663dEE1BFCF2FC6C71F56EF1636FA25862EC
at C:\Users\vagrant\clones\dlang.org\chmgen.d(497)
0x00402A9A in _Dmain at C:\Users\vagrant\clones\dlang.org\chmgen.d(122)

Happens w/ dmd 2.070.2.

--

[Issue 15857] incorrect checkimports mismatch for overload sets

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15857

--- Comment #3 from Jacob Carlborg  ---
I guess since this is currently only a deprecation it isn't _that_ bad. Would
it be realistic to fix the bug before it's turned in to a real error?

What is considered equality for a symbol, the fully qualified name? Can that be
used instead of comparing identity?

Is there a workaround that I can use?

--

[Issue 15857] incorrect checkimports mismatch for overload sets

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15857

--- Comment #2 from Martin Nowak  ---
Unfortunately we don't have any complete symbol equality test in the compiler
(even __traits(isSame) doesn't completely work), so fixing this bug is a bit
out of scope.

--

Re: Any usable SIMD implementation?

[Martin Nowak via Digitalmars-d]

On 04/02/2016 10:19 AM, Iain Buclaw via Digitalmars-d wrote:
>> > __builtin_ia32_loadups
>> > __builtin_ia32_storeups
> Any agnostic way to... :-)

I'm already using vector types for most operations, so it's somewhat
portable.
But for whatever reason D doesn't allow multiplication/division w/
integral vectors (departing from GCC/clang) and I can't perform
unaligned loads, so I have to resort to intrinsics for that.

Re: Can we check the arguments to format() at compile time?

[Jacob Carlborg via Digitalmars-d]

On 2016-04-02 01:40, Yuxuan Shui wrote:


That's kind of ugly. Now I really wish D can unify template arguments
and function arguments known at compile time.


Sounds like AST macros.

--
/Jacob Carlborg

Re: Could we reserve void[T] for builtin set of T ?

[Jacob Carlborg via Digitalmars-d]

On 2016-03-31 21:24, deadalnix wrote:

Pretty much as per title. I has that in the back of my mind for a while.
Would that work ?


An alternative syntax for declaring a set could be:

[int] set;

Not sure if that conflicts with any existing syntax.

--
/Jacob Carlborg

Re: Could we reserve void[T] for builtin set of T ?

[Jacob Carlborg via Digitalmars-d]

On 2016-03-31 21:57, Walter Bright wrote:

On 3/31/2016 12:44 PM, H. S. Teoh via Digitalmars-d wrote:

Ah, makes sense.  But what would aa[x] return?


A bool indicating membership.


And how would you add elements to it?


aa[x] = true;  // add member x
aa[x] = false; // remove member x
x in aa; // compile error


Looks really weird to me. I was thinking something like this:

void[int] set;

set ~= 3;
set ~= 4;
set.remove(3);
bool present = 4 in set; // returns a bool and not a pointer

--
/Jacob Carlborg

Re: pass a struct by value/ref and size of the struct

[ZombineDev via Digitalmars-d-learn]

On Saturday, 2 April 2016 at 09:28:58 UTC, ZombineDev wrote:

On Wednesday, 23 March 2016 at 19:39:49 UTC, kinke wrote:

On Tuesday, 22 March 2016 at 07:35:49 UTC, ZombineDev wrote:
If the object is larger than the size of a register on the 
target machine, it is implicitly passed by ref


That's incorrect. As Johan pointed out, this is somewhat true 
for the Win64 ABI (but it firstly copies the argument before 
passing a pointer to it!), but it's not for the 32-bit x86 and 
x86_64 System V (used on all non-Windows platforms) ABIs. 
System V is especially elaborate and may pass structs up to 
twice the size of a register in 2 registers. Bigger structs 
passed by value are blitted into the function arguments stack 
in memory. They are then accessed by the callee via a stack 
offset, that's correct, but I wouldn't call that 
implicit-by-ref-passing, as copying does take place, unless 
the optimizer decides it's unnecessary.


So passing structs > 64-bit by value on Win64 never pays off 
(there's always an indirection); using `const ref(T)` where 
possible makes sure you at least elide the copy. But then 
again, you'll very soon find out that it's not really an 
option as rvalues cannot be passed byref in D, something a lot 
of people [including myself if not already obvious :)] hate 
about D.


Thank you and Johan for the detailed explanation. You're 
efforts on improving LDC are much appreciated.
My intentions were to say that taking structs by value 
shouldn't be as expensive as in C++, because of the way D 
handles copy construction, especially if there is no 
user-defined postblit (which is quite common), and also because 
separate compilation is used more rarely.
But probably I shouldn't have said that about the size of 
registers as it depends very much on the ABI and it's not true 
in general (as you pointed out).


BTW, how does LDC handle the `auto ref` and `in` parameter 
attributes for templated functions (that obviously have their 
source code available)? Can they be used to prevent indirection 
when the structure can be passed in registers and to prevent 
copying when passing by registers is not possible?


I find that (at least from a usability standpoint) auto ref works 
quite well:


// UniqueRef has disabled this(this)
UniqueRef!Resource r;

void use()(auto ref UniqueRef!Resource r);

// borrows
use(r);

// passes ownership of rvalues
use(UniqueRef!Resource())

// transfers ownership
use(move(r));
// r == UniqueRef.init here

//=

auto ref add(V)(auto ref V v1, auto ref V v2);

// default this(this)
Vec3f vec1;

// accepts both lvalues and rvalues
auto res = add(vec1, Vec3f(1, 2, 3.14));

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[jkpl via Digitalmars-d-learn]

gives: core.exception.OutOfMemoryError@src/core/exception.d(693): 
Memory allocation failed

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[jkpl via Digitalmars-d-learn]

On Saturday, 2 April 2016 at 09:11:34 UTC, jkpl wrote:
On Saturday, 2 April 2016 at 08:48:10 UTC, rikki cattermole 
wrote:

On 02/04/2016 9:36 PM, jkpl wrote:
On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole 
wrote:

Okay that is a problem then.


Yes clearly!

Maybe this, a bit better:


foreach (b0; randomCover(iota(0,256)))
foreach (b1; randomCover(iota(0,256)))
...
foreach (b255; randomCover(iota(0,256)))
{
...
}


Still not the right approach,


import std.stdio;
import std.random;
import std.range;

void testRunner(bool function(ubyte[128]) test)
{
uint[32] arr;

foreach (v0;  randomCover(iota(0U,uint.max)))
foreach (v1;  randomCover(iota(0U,uint.max)))
foreach (v2;  randomCover(iota(0U,uint.max)))
foreach (v3;  randomCover(iota(0U,uint.max)))
foreach (v4;  randomCover(iota(0U,uint.max)))
foreach (v5;  randomCover(iota(0U,uint.max)))
foreach (v6;  randomCover(iota(0U,uint.max)))
foreach (v7;  randomCover(iota(0U,uint.max)))
foreach (v8;  randomCover(iota(0U,uint.max)))
foreach (v9;  randomCover(iota(0U,uint.max)))
foreach (v10; randomCover(iota(0U,uint.max)))
foreach (v11; randomCover(iota(0U,uint.max)))
foreach (v12; randomCover(iota(0U,uint.max)))
foreach (v13; randomCover(iota(0U,uint.max)))
foreach (v14; randomCover(iota(0U,uint.max)))
foreach (v15; randomCover(iota(0U,uint.max)))
foreach (v16; randomCover(iota(0U,uint.max)))
foreach (v17; randomCover(iota(0U,uint.max)))
foreach (v18; randomCover(iota(0U,uint.max)))
foreach (v19; randomCover(iota(0U,uint.max)))
foreach (v20; randomCover(iota(0U,uint.max)))
foreach (v21; randomCover(iota(0U,uint.max)))
foreach (v22; randomCover(iota(0U,uint.max)))
foreach (v23; randomCover(iota(0U,uint.max)))
foreach (v24; randomCover(iota(0U,uint.max)))
foreach (v25; randomCover(iota(0U,uint.max)))
foreach (v26; randomCover(iota(0U,uint.max)))
foreach (v27; randomCover(iota(0U,uint.max)))
foreach (v28; randomCover(iota(0U,uint.max)))
foreach (v29; randomCover(iota(0U,uint.max)))
foreach (v30; randomCover(iota(0U,uint.max)))
foreach (v31; randomCover(iota(0U,uint.max)))
{
arr = [v0,v1,v2,v3,v4,v5,v6,v7,v8,v9,
   v10,v11,v12,v13,v14,v15,v16,v17,v18,v19,
   v20,v21,v22,v23,v24,v25,v26,v27,v28,v29,
   v30, v31
];

writeln(arr);

//if (test(cast(ubyte[128]) arr))
return;
}
}

bool test(ubyte[128] arr)
{
if (arr[0] == 0U)
return true;
else
return false;
}

void main()
{
testRunner();
}

Re: pass a struct by value/ref and size of the struct

[ZombineDev via Digitalmars-d-learn]

On Wednesday, 23 March 2016 at 19:39:49 UTC, kinke wrote:

On Tuesday, 22 March 2016 at 07:35:49 UTC, ZombineDev wrote:
If the object is larger than the size of a register on the 
target machine, it is implicitly passed by ref


That's incorrect. As Johan pointed out, this is somewhat true 
for the Win64 ABI (but it firstly copies the argument before 
passing a pointer to it!), but it's not for the 32-bit x86 and 
x86_64 System V (used on all non-Windows platforms) ABIs. 
System V is especially elaborate and may pass structs up to 
twice the size of a register in 2 registers. Bigger structs 
passed by value are blitted into the function arguments stack 
in memory. They are then accessed by the callee via a stack 
offset, that's correct, but I wouldn't call that 
implicit-by-ref-passing, as copying does take place, unless the 
optimizer decides it's unnecessary.


So passing structs > 64-bit by value on Win64 never pays off 
(there's always an indirection); using `const ref(T)` where 
possible makes sure you at least elide the copy. But then 
again, you'll very soon find out that it's not really an option 
as rvalues cannot be passed byref in D, something a lot of 
people [including myself if not already obvious :)] hate about 
D.


Thank you and Johan for the detailed explanation. You're efforts 
on improving LDC are much appreciated.
My intentions were to say that taking structs by value shouldn't 
be as expensive as in C++, because of the way D handles copy 
construction, especially if there is no user-defined postblit 
(which is quite common), and also because separate compilation is 
used more rarely.
But probably I shouldn't have said that about the size of 
registers as it depends very much on the ABI and it's not true in 
general (as you pointed out).


BTW, how does LDC handle the `auto ref` and `in` parameter 
attributes for templated functions (that obviously have their 
source code available)? Can they be used to prevent indirection 
when the structure can be passed in registers and to prevent 
copying when passing by registers is not possible?

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[jkpl via Digitalmars-d-learn]

On Saturday, 2 April 2016 at 08:48:10 UTC, rikki cattermole wrote:

On 02/04/2016 9:36 PM, jkpl wrote:
On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole 
wrote:

Okay that is a problem then.


Yes clearly!

Maybe this, a bit better:


foreach (b0; randomCover(iota(0,256)))
foreach (b1; randomCover(iota(0,256)))
...
foreach (b255; randomCover(iota(0,256)))
{
...
}

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[rikki cattermole via Digitalmars-d-learn]

On 02/04/2016 9:36 PM, jkpl wrote:

On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole wrote:

On 02/04/2016 9:20 PM, jkpl wrote:

Let's say I have a ubyte[256]. I want to test all the possible values
this array can have on a function.


Actually I'd use a hex string.

So:
static ubyte[256] DATA = cast(ubyte[256])x"00 01 02 03";
I'm sure you get the idea. That can be created easily enough.


No I don't get the idea. I think that I haven't well explained. By
static array I meant "not dynamic". The 256^256 combinations must be
generated on the same ubyte[256], which is a variable, during the
program execution.


Okay that is a problem then.
Stick with generating it I think, can't hard code that number of 
combinations.

[Issue 15863] .length for AA.byKey

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15863

ZombineDev  changed:

   What|Removed |Added

   Keywords||pull
 CC||petar.p.ki...@gmail.com

--

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[jkpl via Digitalmars-d-learn]

On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole wrote:

On 02/04/2016 9:20 PM, jkpl wrote:
Let's say I have a ubyte[256]. I want to test all the possible 
values

this array can have on a function.


Actually I'd use a hex string.

So:
static ubyte[256] DATA = cast(ubyte[256])x"00 01 02 03";
I'm sure you get the idea. That can be created easily enough.


No I don't get the idea. I think that I haven't well explained. 
By static array I meant "not dynamic". The 256^256 combinations 
must be generated on the same ubyte[256], which is a variable, 
during the program execution.

Re: Idiomatic way to generate all possible values a static array of ubyte can have

[rikki cattermole via Digitalmars-d-learn]

On 02/04/2016 9:20 PM, jkpl wrote:

Let's say I have a ubyte[256]. I want to test all the possible values
this array can have on a function.

Currently I fill it for each new test with std.random.uniform but I'm
sure that I loose some time with randomizing and with the tests that are
repeated. Is there a simple way to do this ? Without thinking much, it
seems that the loops to generate this would be seriously awefull.

By thinking a bit more maybe with a fixed-size big integer it would
work, since the value could be casted as the right array type (as long
as its length is power of 2) ?


Actually I'd use a hex string.

So:
static ubyte[256] DATA = cast(ubyte[256])x"00 01 02 03";
I'm sure you get the idea. That can be created easily enough.

Idiomatic way to generate all possible values a static array of ubyte can have

[jkpl via Digitalmars-d-learn]

Let's say I have a ubyte[256]. I want to test all the possible 
values this array can have on a function.


Currently I fill it for each new test with std.random.uniform but 
I'm sure that I loose some time with randomizing and with the 
tests that are repeated. Is there a simple way to do this ? 
Without thinking much, it seems that the loops to generate this 
would be seriously awefull.


By thinking a bit more maybe with a fixed-size big integer it 
would work, since the value could be casted as the right array 
type (as long as its length is power of 2) ?

Re: Any usable SIMD implementation?

[Iain Buclaw via Digitalmars-d]

On 2 Apr 2016 9:45 am, "Martin Nowak via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 2 April 2016 at 06:13:24 UTC, Iain Buclaw wrote:
>>
>> I would just let the compiler optimize / vectorize the operation, but
then again that it is probably just me who thinks these things.
>
>
> It's intended to replace the array ops in druntime, relying on vecorizers
won't suffice, e.g. your example already stops working when I pass dynamic
instead of static arrays.
>
>
>> I'm not aware of any intrinsic to load unaligned data. Only to assume
alignment.
>
>
> __builtin_ia32_loadups
> __builtin_ia32_storeups

Any agnostic way to... :-)

Re: "Squash and merge" on GitHub

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 2 April 2016 at 03:58:27 UTC, Daniel Murphy wrote:

On 2/04/2016 7:28 AM, Vladimir Panteleev wrote:


4. We should use the autotester's auto-merge feature anyway.



Can we disable both and force everyone to use the autotester?


Not an answer to your question, but after accidentally bypassing 
the autotester a few times (lack of habit due to working on other 
GitHub projects), I wrote this for myself:


http://dump.thecybershadow.net/6265c3ae18e8bf7a176d00e5e22ff395/NoMergeButton.user.js

Re: D goes business! Bindings for SAP NetWeaver RFC SDK

[Lars Johansson via Digitalmars-d-announce]

On Saturday, 1 August 2015 at 22:09:16 UTC, Kai Nacke wrote:

On Thursday, 2 July 2015 at 10:40:08 UTC, Kai Nacke wrote:

Hi all!

My latest project is D bindings for the SAP NetWeaver RFC SDK.

The first code is available at 
https://github.com/redstar/sapnwrfc-d. It is currently only a 
port of the main header file but I plan to add a high-level 
API, too. See the README for current limitations and ideas.


I create a tag for the DUB registry as soon as I got the first 
working example.


Regards,
Kai


I finally managed to create a sample application. The library 
is now in the DUB registry, too.


Regards,
Kai


Hi Kai,
I'm for the zillionth time starting to learn D. I just started 
with 'The D programming language' after that I will explore the 
possibilities to access SAP from D. A good SAP is important for 
my sucess with D. Will you maintain and develop the SAP interface?

Re: Direntries seems to on other drives. (windows)

[Vladimir Panteleev via Digitalmars-d-learn]

On Friday, 1 April 2016 at 02:05:23 UTC, Taylor Hillegeist wrote:


Even though i just checked for a valid path.



[...]


	if(!args[1].buildNormalizedPath.isValidPath){writeln("Path is 
invalid! "); return;}


From https://dlang.org/library/std/path/is_valid_path.html :

It does *not* check whether the path points to an existing file 
or directory; use std.file.exists for this purpose.


You are using the wrong function for the job.

The simple explanation is that the path you specified doesn't 
actually exist.

Re: Any usable SIMD implementation?

[Martin Nowak via Digitalmars-d]

On Saturday, 2 April 2016 at 06:13:24 UTC, Iain Buclaw wrote:
I would just let the compiler optimize / vectorize the 
operation, but then again that it is probably just me who 
thinks these things.


It's intended to replace the array ops in druntime, relying on 
vecorizers won't suffice, e.g. your example already stops working 
when I pass dynamic instead of static arrays.


I'm not aware of any intrinsic to load unaligned data. Only to 
assume alignment.


__builtin_ia32_loadups
__builtin_ia32_storeups

[Issue 15859] opApply resolution on attributes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15859

--- Comment #1 from qs.il.paperi...@gmail.com ---
(In reply to qs.il.paperinik from comment #0)
> struct X
> {
> int opApply(int delegate(string) dg)
> {
> return dg("impure");
> }
> 
> int opApply(int delegate(string) pure dg) pure
> {
> return dg("pure");
> }
> }
> 
> void main()
> {
> X x;
> string result;
>
> [ ... ] 
>
> /+ (1)
> foreach (string s; x)
> {
> result = s;
> }
> writeln(result); // x.opApply matches more than one declaration
> +/
> /+ (2)
> foreach (string s; x)
> {
> result = s;
> write("");
> }
> writeln(result); // x.opApply matches more than one declaration
> +/
> }

For (1) this is true to some extent. The constructed delegate is pure, but can
be matched to the non-pure version of opApply.
For (2) the compiler rejects valid because the delegate is impure and can only
match the impure opApply.

--

Re: Any usable SIMD implementation?

[Iain Buclaw via Digitalmars-d]

On 2 Apr 2016 12:40 am, "Martin Nowak via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 03/31/2016 10:55 AM, ZombineDev wrote:
> > [2]: https://github.com/D-Programming-Language/phobos/pull/2862
>
> Well apparently stores w/ dmd's weird core.simd interface don't work, or
> I can't figure out (from the non-existent documentation) how to use it.
>
> ---
> import core.simd;
>
> void test(float4* ptr, float4 val)
> {
> __simd_sto(XMM.STOUPS, *ptr, val);
> __simd(XMM.STOUPS, *ptr, val);
> auto val1 = __simd_sto(XMM.STOUPS, *ptr, val);
> auto val2 = __simd(XMM.STOUPS, *ptr, val);
> }
> ---
>
> LDC at least has some intrinsics once you find ldc.gccbuiltins_x86, but
> for some reason comes with it's own broken ldc.simd.loadUnaligned
> instead of providing intrinsics.
>
> ---
> import core.simd, ldc.simd;
>
> float4 test(float* ptr)
> {
> return loadUnaligned!float4(ptr);
> }
> ---
>
> /home/dawg/dlang/ldc-0.17.1/bin/../import/ldc/simd.di(212): Error: can't
> parse inline LLVM IR:
> %r = load <4 x float>* %p, align 1
>^
> expected comma after load's type
>
> So are 3 different untested and unused APIs really the current state of
> SIMD?
>
> -Martin
>

I would just let the compiler optimize / vectorize the operation, but then
again that it is probably just me who thinks these things.

http://goo.gl/XdiKZX

I'm not aware of any intrinsic to load unaligned data. Only to assume
alignment.

Iain.

Re: "Squash and merge" on GitHub

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 2 April 2016 at 05:18:47 UTC, Andrei Alexandrescu 
wrote:

On 4/2/16 12:36 AM, Jack Stouffer wrote:

On Saturday, 2 April 2016 at 03:58:27 UTC, Daniel Murphy wrote:

On 2/04/2016 7:28 AM, Vladimir Panteleev wrote:


4. We should use the autotester's auto-merge feature anyway.



Can we disable both and force everyone to use the autotester?


Yes, you can take away everyone but the auto-tester's merge 
rights.


Actually that might be a good setup. We'd need an escape hatch 
for a small circle, and control over the autotester. Also we'd 
need to make the autotester work with all repos. -- Andrei


Currently it seems that the autotester uses the committer's 
account to perform the merge (probably as an additional security 
measure that only committers can merge via the autotester). It 
would need some changes.