Re: Dub hanging for a long time
I do not use antivirus. It's floated error. I can't reproduce it. But sometime it's appears again.
Re: Issue with template function
On Friday, 6 February 2015 at 17:40:31 UTC, ketmar wrote: On Fri, 06 Feb 2015 17:09:28 +, Charles wrote: readString(toBytes!string(test),0,4).writeln; if you'll take a look into druntime sources, you'll find that string is just an alias to `immutable(char)[]`. so you actually doing thing: readString(toBytes!(immutable(char)[])(test),0,4).writeln; i bet that this is not what you meant. ;-) Thanks!
Re: Some notes on Rust
On Fri, Feb 6, 2015 at 12:08 AM, Paulo Pinto via Digitalmars-d digitalmars-d@puremagic.com wrote: For example no need to check if a variable is inside a specific range, if the type only allows that range. Are you referring specifically to Ada here? Otherwise, how would ML-based languages allow for this in a way that your traditional OO languages would not? -- Ziad
Re: Dub hanging for a long time
On 7/02/2015 8:55 p.m., Suliman wrote: Several times I encounter problem when DUB is hanging for a long time It's look like that when I tun DUB from folder of current project it's do not show me nothing, just move cursor on next line for a long time. http://img.ctrlv.in/img/15/02/07/54d5c37f6d3c3.png running dub from any other location is fine. If to wait some times (about 1 minutes) it's begin build project. After it next running dub from project dir work mediately. Does anybody encounter such problem? Try disabling anti-virus ext. Something seems to be messing up execution.
Dub hanging for a long time
Several times I encounter problem when DUB is hanging for a long time It's look like that when I tun DUB from folder of current project it's do not show me nothing, just move cursor on next line for a long time. http://img.ctrlv.in/img/15/02/07/54d5c37f6d3c3.png running dub from any other location is fine. If to wait some times (about 1 minutes) it's begin build project. After it next running dub from project dir work mediately. Does anybody encounter such problem?
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 00:31:41 UTC, H. S. Teoh wrote: This does not take into the account the fact that a @trusted function may call other, non-@trusted, functions. When one of those other functions changes, the @trusted function necessarily needs to be reviewed again. However, under the current implementation, this is not done because when the other, non-@trusted, function is modified, nobody thinks to re-review the @trusted function. They may not even be in the same module. There is no mechanism in place to raise a warning flag when a @trusted function's dependencies are modified. Thus, the proof of safety of the @trusted function has been invalidated, but trust continues to be conferred upon it. So what you should ask for is a way to sign @trusted with a timestamp that indicates when it was last proven to be safe, e.g.: @trusted(2015-01-01T12:30:12z) Then ask for a fine grained dependency tracking tool that can extract changes from git. Such a dependency tracking tool could be a nice stepping stone for faster compilation (sub-file-level recompilation). So there is synergies in this. The proposal to confuse @trusted/@safe with requiring @system within @trusted it not a language issue. It is a process issue and can be done with lint-like tooling. Keep @trusted/@safe/@system simple. Enough convoluted semantics in D already.
Re: Module for manual memory management
On 2015-02-04 21:55, Walter Bright wrote: No need to reinvent this: https://github.com/D-Programming-Language/phobos/blob/master/std/file.d line 194 Just for the record, you can get a link to the exact line by clicking on the line number in the left margin and the copying the link from the address bar. -- /Jacob Carlborg
Re: @trust is an encapsulation method, not an escape
On 2/6/15 8:43 PM, Andrei Alexandrescu wrote: On 2/6/15 3:21 PM, weaselcat wrote: On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote: No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions. This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! this sounds interesting, is anyone going to make a DIP for it? Consider the previous code: https://github.com/D-Programming-Language/phobos/blob/accb351b96bb04a6890bb7df018749337e55eccc/std/file.d#L194 that got replaced with: https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L194 With the system proposal we're looking at something like: Please understand, Nobody is saying let's replace incorrect code with the same incorrect code with different tags! The idea is to properly identify which code needs more scrutiny, and keep the mechanical checking of @safe where we can. -Steve
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 11:32:41 UTC, Steven Schveighoffer wrote: The idea is that @trusted code still has to be reviewed for memory issues, but is mechanically checked for most of the function for obvious @safe violations. It limits to a degree the scrutiny one must apply to the @trusted function. Remember, the whole point of a @trusted function is that it's manually verified. This is the wrong way to do it and this is a tooling issue, not a language issue. The right way to do it is this: 1. annotate the @trusted region manually where it is needed 2. mechanically verify the whole @trusted region Of course, then you also need a theorem prover... You are trying to do this: 1. mechanically verify the whole @trusted region 2. manually verify the whole @trusted region, but be sloppy about it here an there 3. Ooops, we were sloppy in the wrong spot... Not good.
[Issue 14137] std.socket.getAddressInfo breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14137 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Severity|enhancement |major --- Comment #1 from David Nadlinger c...@klickverbot.at --- Actually a permalink now: https://github.com/D-Programming-Language/phobos/blob/041db2d8fac2b1cf5169be7188ea537a01f27586/std/socket.d#L996-L997 --
Re: Zero-length static array spec
On Saturday, 7 February 2015 at 12:10:45 UTC, Iain Buclaw wrote:
Some cod scenarios:
1. Comparisons of == fold into 'false' (unless comparing to
self)
2. Comparisons of != fold into 'true' (unless comparing to
self)
3. Conversion to dynamic arrays is { .length=0, .ptr=arr0 }
What does arr0 refer to?
And assuming that a0.ptr and a1.ptr would end up being the same
in your proposal, do you really want to have a situation where
a0.ptr == a1.ptr a0.length == a1.length but a0 != a1?
David
Using reduce with user types
I can use filter algorithm with my types easily.
struct A
{
string value;
int count;
}
void main( string[] args )
{
A[] aArr;
aArr ~= A(HTTP, 3);
aArr ~= A(HTTPS, 2);
aArr ~= A(UNKNOWN_TCP, 4);
aArr.filter!( a = a.count == 2);
But I couldn't compile when I want to use reduce algorithm. I
simply want to get the sum of count variables inside of A[].
auto sum = aArr.reduce!((a,b) = a.count + b.count);
The line above gives
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(770):
Error: cannot implicitly convert expression (__lambda3(result,
front(_param_1))) of type int to A
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(791):
Error: template instance app.main.reduce!((a, b) = a.count +
b.count).reduce!(A, A[]) error instantiating
source\app.d(363):instantiated from here: reduce!(A[])
How can I achieve summing count variables inside A[]?
Best Regards
Kadir Erdem Demir
Ps: The problem caused by my lack of D basics I admit, the reason
I can't look up references more before ask question I am in a
bit tight schedule. Sorry for my dummy questions.
static alias this
Consider this simple example
A)-
struct StaticRegister {
static private uint _value;
@property static uint value() { return _value; }
@property static void value(uint v) { _value = v; }
}
void main(string[] s) {
StaticRegister = 1;
assert(StaticRegister == 1);
}
---
This gives two errors for each line in `main` (exactly what I
expected).
test.d(8): Error: StaticRegister is not an lvalue
test.d(9): Error: incompatible types for ((StaticRegister) ==
(1)):
cannot use '==' with types
However, if I modify the example by adding an `alias this` ...
B)-
struct StaticRegister {
static private uint _value;
@property static uint value() { return _value; }
@property static void value(uint v) { _value = v; }
alias value this;
}
void main(string[] s) {
StaticRegister = 1;
assert(StaticRegister == 1);
}
---
... the assignment error is eliminated, but the read is not.
test.d(11): Error: incompatible types for ((StaticRegister) ==
(1)):
cannot use '==' with types
I argue that either both errors should be eliminated, or neither
should be eliminated. One could also argue that some variation
of the following should be required...
* static alias value this;
* alias static value this;
* alias value static this;
... to distinguish it from non-static `this`
Now, in the example below, `this` is referring to the type itself
in a static context
C)---
import std.stdio;
struct StaticRegister {
static string GetType() { return typeof(this).stringof; }
}
void main(string[] s) {
writeln(StaticRegister.GetType());
}
---
So, it follows that the example below should work... and it does
D)---
struct StaticRegister {
static private uint _value = 0;
@property static uint value() { return _value; }
@property static void value(uint v) { _value= v; }
static uint GetValue() {
return this.value;
}
}
void main(string[] s) {
assert(StaticRegister.GetValue() == 0);
}
---
So, why does `alias this` in a static context (See example B
above) only half-work? Bug? If not, what's the design rationale?
Thanks,
Mike
[Issue 14139] GIT HEAD : PI now has wrong value
https://issues.dlang.org/show_bug.cgi?id=14139 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- I can't reproduce this... --
Re: Zero-length static array spec
On 2015-02-07 at 00:42, David Nadlinger wrote:
Imagine you have this in your program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that they are distinct,
but you don't end up allocating 100 bytes of stack memory?
Forgive my ignorance and perhaps not seeing the whole picture, but when I read
this:
A static array with a dimension of 0 is allowed, but no space is allocated for
it. It's useful as the last member of a variable length struct...
i am convinced that a0, ..., a99 are not variables but rather *labels* and
should point to *the same address* of whatever could be put in that place (with
1-byte alignment). I do not understand why would they ever point to different
places. Wouldn't that make them useless when used in structs like the following
one (or to access stack, like above)?
struct Packet {
int a, b, c, length;
ubyte[0] data;
ubyte[0] payload; // just a superfluous alias to data
}
unittest {
Packet p;
assert(p.sizeof == 16);
assert(p + 1 == cast(void*) p.data);
assert(p + 1 == cast(void*) p.payload);
}
As for passing it around, it doesn't make sense, it is like passing an argument
of type void, so shouldn't be allowed. Only a pointer to a zero-length array or
a specified element would be fine:
foo(p.data)// fine, ubyte*
bar(p.data[i]) // fine, ubyte (or memory violation)
xxx(p.data) // ERROR, makes no sense, shouldn't compile
Re: strange work of GC
If a destroy method is used together with GC inside of my app,it makes my app unstable. In this case I need to choose how to destroy my objects: 1) always manually by method destroy, but without GC; 2) or always automatically by GC, but without using the destroy method. In the first case I need to know how can I disable the automatic GC in my app? In the second case - how can I disable the destroy method calls inside of my app?
[Issue 4650] Static data that must be scanned by the GC should be grouped
https://issues.dlang.org/show_bug.cgi?id=4650 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de --- There is a minimal support for this for ELF object files: strings and some floating point constants are emitted to the .text segment. --
[Issue 4650] Static data that must be scanned by the GC should be grouped
https://issues.dlang.org/show_bug.cgi?id=4650 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de --- Similar functionality for COFF and OMF: https://github.com/D-Programming-Language/dmd/pull/4390 --
Re: @trust is an encapsulation method, not an escape
On 2/6/15 4:36 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote:
In the proposal, @trusted code is actually considered the same as
@safe, but allows @system escapes.
But that can't work:
@trusted_is_safe {
auto tmp = get_hardware_config();
@system{
mess_up_hardware_config();
}
// now this unsafe call is called in a @safe context, but is unsafe...
// DMD does not catch this, so @trusted_is_safe is broken
call_safe_code_that_now_is_messed_up();
@system{
restore_hardware_config(tmp);
}
}
The idea is that @trusted code still has to be reviewed for memory
issues, but is mechanically checked for most of the function for obvious
@safe violations. It limits to a degree the scrutiny one must apply to
the @trusted function.
Remember, the whole point of a @trusted function is that it's manually
verified.
-Steve
Re: Issue with template function
On Friday, 6 February 2015 at 17:09:29 UTC, Charles wrote:
I'm trying to create a template function that can take in any
type of array and convert it to a ubyte array. I'm not
concerned with endianness at the moment, but I ran into a
roadblock when trying to do this with strings. It already works
with ints, chars, etc.
Here's the relevant test code:
module byteReader;
public import std.system : Endian;
ubyte[] toBytes(T)(T[] arr)
{
if (arr == null)
{
return null;
}
ubyte[] result = new ubyte[arr.length];
foreach (key, val; arr)
{
result[key] = cast(ubyte) val;// This is line 16
}
return result;
}
string readString(ubyte[] buffer, uint offset, uint length)
{
assert( buffer.length = offset + length );
char[] chars = new char[length];
foreach(key, val; buffer[offset .. offset + length])
{
chars[key] = cast(char) val;
}
return cast(string)chars;
}
void main() {
import std.stdio;
readString(toBytes!char(['t','e','s','t']),0,4).writeln;
readString(toBytes!string(test),0,4).writeln;//
This is line 39
}
Here's the output:
byteReader.d(16): Error: cannot cast val of type string to
type ubyte
byteReader.d(39): Error: template instance
byteReader.toBytes!string error instantiating
Are you wanting to to convert each element in arr to a byte thus
truncating and losing data (when T.sizeof != 1)?
as in
toBytes([1,2,3, 42, 500 /*this will be truncated to 244
*/]);// T == int here
or are you wanting to convert each element to a ubyte array and
then concatenate it to the result.
as is
ubyte[] toBytes(T)(T[] arr)
{
ubyte[T.sizeof] buf;
if (arr is null)
{
return null;
}
ubyte[] result = new ubyte[arr.length * T.sizeof];
foreach (i, val; arr)
{
buf[] = cast(ubyte[T.sizeof])(arr[i])[0 .. T.sizeof]
result ~= buf;
}
return result;
}
?
Re: Zero-length static array spec
On 6 February 2015 at 23:42, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 6 February 2015 at 23:37:30 UTC, Iain Buclaw wrote:
Simple, you implement it by allocating no memory. :)
Let me put it a different way. Imagine you have this in your program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that they are
distinct, but you don't end up allocating 100 bytes of stack memory?
David
There are no addresses for them, you can't do *anything* with them at runtime.
Some cod scenarios:
1. Comparisons of == fold into 'false' (unless comparing to self)
2. Comparisons of != fold into 'true' (unless comparing to self)
3. Conversion to dynamic arrays is { .length=0, .ptr=arr0 }
You cannot assign memory/address to them directly, but you can assign
it indirectly. This 'indirect assignment' can only really work if it
were the last member of a struct. Example usage -
http://goo.gl/uAbxKN - something like a pointer-based dynamic array.
Labels probably do best describe their exact behaviour.
Iain.
Re: Zero-length static array spec
On 7 February 2015 at 10:56, FG via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2015-02-07 at 00:42, David Nadlinger wrote:
Imagine you have this in your program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that they are
distinct, but you don't end up allocating 100 bytes of stack memory?
Forgive my ignorance and perhaps not seeing the whole picture, but when I
read this:
A static array with a dimension of 0 is allowed, but no space is allocated
for it. It's useful as the last member of a variable length struct...
i am convinced that a0, ..., a99 are not variables but rather *labels* and
should point to *the same address* of whatever could be put in that place
(with 1-byte alignment). I do not understand why would they ever point to
different places. Wouldn't that make them useless when used in structs like
the following one (or to access stack, like above)?
struct Packet {
int a, b, c, length;
ubyte[0] data;
ubyte[0] payload; // just a superfluous alias to data
}
unittest {
Packet p;
assert(p.sizeof == 16);
assert(p + 1 == cast(void*) p.data);
assert(p + 1 == cast(void*) p.payload);
}
As for passing it around, it doesn't make sense, it is like passing an
argument of type void, so shouldn't be allowed. Only a pointer to a
zero-length array or a specified element would be fine:
foo(p.data)// fine, ubyte*
This is OK - gets passed as ubyte*
bar(p.data[i]) // fine, ubyte (or memory violation)
This is OK - gets passed as ubyte - though will throw arrayBounds
error unless -noboundschecks.
xxx(p.data) // ERROR, makes no sense, shouldn't compile
This is OK - gets passed as ubyte[] - the dynamic array will have a
length of '0' and the ptr to p.data.
Iain.
[Issue 14140] New: Bad codegen when variable used as default argument
https://issues.dlang.org/show_bug.cgi?id=14140 Issue ID: 14140 Summary: Bad codegen when variable used as default argument Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: critical Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: temta...@gmail.com http://dpaste.dzfl.pl/f87326091fa6 --
Re: DCD 0.5.0 beta
On Saturday, 31 January 2015 at 02:50:27 UTC, Brian Schott wrote: https://github.com/Hackerpilot/DCD/tree/v0.5.0-beta3 Changes from 0.4.0: * Include current git commit hash in --version output * Update libdparse and msgpack dependencies * Fix several crashes * Remove Textadept module. It is now at https://github.com/Hackerpilot/textadept-d * Added basic regression testing scripts * Fix #117 * Fix #177 * Fix #179 * Fix #176 * Fix #178 * Fix #182 * Fix #184 Thx for the fix related to DDoc comments, this feature can be used correctly now.
[Issue 14139] New: GIT HEAD : PI now has wrong value
https://issues.dlang.org/show_bug.cgi?id=14139
Issue ID: 14139
Summary: GIT HEAD : PI now has wrong value
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
import std.math;
import std.stdio;
void main() {
writeln(PI);
}
With latest GIT HEAD prints
1.4488e+19
--
Re: strange work of GC
On 2015-02-07 at 12:02, Andrey Derzhavin wrote: If a destroy method is used together with GC inside of my app,it makes my app unstable. In this case I need to choose how to destroy my objects: 1) always manually by method destroy, but without GC; 2) or always automatically by GC, but without using the destroy method. In the first case I need to know how can I disable the automatic GC in my app? In the second case - how can I disable the destroy method calls inside of my app? Why do you want to use destroy? Put GC.collect() after the call to fn1 and GC cleanup will work just fine[1], I've checked. Are you talking about a different program now? [1] Assuming that you compile the program as 64-bit and not 32-bit.
[Issue 14131] va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131
--- Comment #3 from yebblies yebbl...@gmail.com ---
The partial fix makes the original test case work, but this one should still
fail.
void copyb(ref va_list ap2, va_list ap)
{
va_copy(ap2, ap);
}
void copya(int a, string format, ...)
{
va_list ap;
va_start(ap, format);
va_list ap2;
copyb(ap2, ap);
auto a1 = va_arg!int(ap);
auto a2 = va_arg!int(ap);
auto a3 = va_arg!int(ap);
assert(a1 == 0x);
assert(a2 == 0x);
assert(a3 == 0x);
auto b1 = va_arg!int(ap2);
auto b2 = va_arg!int(ap2);
auto b3 = va_arg!int(ap2);
assert(b1 == 0x);
assert(b2 == 0x);
assert(b3 == 0x);
va_end(ap);
va_end(ap2);
}
void testCopy()
{
copya(0, , 0x, 0x, 0x);
}
--
Re: @trust is an encapsulation method, not an escape
On 2/6/15 5:19 PM, Meta wrote: On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote: In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes. That seems like a good idea and in the spirit of what the goal is. However, won't it be a breaking change? Yes. The big question is, is it worth it? I would say yes, since @trusted is already incorrectly used in most cases. -Steve
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 06:20:16 UTC, Walter Bright wrote: On 2/6/2015 9:49 PM, Vladimir Panteleev wrote: On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright wrote: 1. exceptions are not for debugging the logic of your program 2. do not use exceptions to recover from logic bugs in your program OK, this is nothing new, but still doesn't answer my question. You wrote is clearly a program bug. Therefore use assert(). It's as simple as that. OK, thank you. A few years ago you were recommending something else for this situation. We were in disagreement then, and I agree with your current opinion.
[Issue 14131] va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/143f780fa6d5fd692d25b8f8318c73f5722616b9 Add test case for Issue 14131 - va_copy is broken on posix X86_64 https://github.com/D-Programming-Language/dmd/commit/97f5400129a489b31f4378cf9a1776ba0debc4b3 Merge pull request #4385 from yebblies/va_copy Add test case for Issue 14131 - va_copy is broken on posix X86_64 --
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote: On 2/6/2015 3:02 PM, Zach the Mystic wrote: This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! I suspect that such a feature would simply lull people into a false sense of security in that merely tagging an unsafe cast with @system and the compiler accepting it is good enough. My evidence for this is how @trusted was used in Phobos. I'm also not saying phobos was written perfectly to begin with. I think that this whole @system blocks suggestion came up in a slightly different context than did your original discontent with std.file and std.array. I'm not sure you're ever going to stop careless programmers from getting their bad code to compile. But I think that's a different issue from giving good, careful programmers the tools they need. Right now, @trusted functions are the only tool they have to help people figure out where the unsafe code is, but it's not enough. Nested @trusted functions, and @trusted lambas are clearly being added as a workaround for not being able to un@trust large portions of code intended to be @safe.
Re: Module for manual memory management
On Saturday, 7 February 2015 at 11:29:51 UTC, Jacob Carlborg wrote: On 2015-02-04 21:55, Walter Bright wrote: No need to reinvent this: https://github.com/D-Programming-Language/phobos/blob/master/std/file.d line 194 Just for the record, you can get a link to the exact line by clicking on the line number in the left margin and the copying the link from the address bar. The same I've said a page previously. Funny. :)
Re: @trust is an encapsulation method, not an escape
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
The solution is to regard @trusted as a means of encapsulating
unsafe operations, not escaping them. Encapsulating them means
that the interface from the @trusted code is such that it is
usable from safe code without having to manually review the
safe code for memory safety. For example (also from std.array):
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
}
I don't have to review callers of trustedMemory() because it
encapsulates an unsafe operation (memcpy) with a safe interface.
If I understand correctly, your rule o be a trusted function is:
Unable to create a memory corrutpion whatever the arguments.
But here:
- dest or src could be the null slice
- the assert would go away in release
So I though this example _could_ corrupt memory?
The reason @trusted applies only to functions, and not to
blocks of code, is that functions are the construct in D that
provides an interface. Arbitrary blocks of code do not have a
structured interface. Adding @trusted { code } support will
encourage incorrect uses like the opening example. The
existence of @trusted blocks will require review of every line
of code in the function that encloses it, and transitively
every function that calls it!
Adding @trusted as a function attribute, on the other hand,
only requires review of the function's interface to determine
if it is acceptable to use in safe code. Safety review of its
callers is unnecessary.
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 10:02:23 UTC, ponce wrote: If I understand correctly, your rule o be a trusted function is: Unable to create a memory corrutpion whatever the arguments. But here: - dest or src could be the null slice - the assert would go away in release So I though this example _could_ corrupt memory? I see know it was already addressed: http://forum.dlang.org/post/mb1vmt$etn$1...@digitalmars.com
[Issue 14131] va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/ee94dbddf7700a5e5864d485e66002e31e6fa670 Partial fix for Issue 14131 - va_copy is broken on posix X86_64 https://github.com/D-Programming-Language/druntime/commit/02270ea991f4218764d2c2cc867c56f082672d4c Merge pull request #1158 from yebblies/va_copy Partial fix for Issue 14131 - va_copy is broken on posix X86_64 --
[Issue 14140] Bad codegen when variable used as default argument
https://issues.dlang.org/show_bug.cgi?id=14140 --- Comment #1 from Temtaime temta...@gmail.com --- This bug exists with GIT HEAD too. --
Re: Learning to XML with D
On Friday, 6 February 2015 at 09:15:54 UTC, Derix wrote:
So, I set sails to transform a bunch of HTML files with D.
This, of course, will happen with the std.xml library.
There is this nice example :
http://dlang.org/phobos/std_xml.html#.DocumentParser
that I put to some use already, however some of the basics seem
to escape me, specially in lines like
xml.onEndTag[author] = (in Element e) { book.author
= e.text(); };
OK, we're doing some event-base parsing, reacting with a lambda
function on encountering so-and-do tag, à la SAX. (are we ?)
What I don't quite grab is the construct (in Element e) ,
especially the *in* part.
Is it *in* as in http://dlang.org/expression.html#InExpression
? In which case I fail to see what associative array we're
considering.
It's probably more a way to further qualify the argument e were
passing to the λ-function : could someone elaborate on that ?
Of course, it is entirely possible that I completely miss the
point and that I'm overlooking some fundamentals, if so have
mercy and help me find my way back to teh righteous path ;-)
Thxxx
Maybe, when you're on windows, you could use msxml6 through COM.
You have DOM, SAX, Xpath 1.0 and XSLT at your disposal.
[Issue 14139] GIT HEAD : PI now has wrong value
https://issues.dlang.org/show_bug.cgi?id=14139 --- Comment #2 from Temtaime temta...@gmail.com --- The bug exists only on Windows when dmd is built with /GL, /LTCG compiler optimization options. 2.066 compiles and runs successfully with these options. --
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 18:52:45 UTC, Andrei Alexandrescu wrote: I think the problem is overstated. -- Andrei I think there could hardly be a more persuasive argument that this belief is wrong than Walter himself just having made the mistake several times, and not even immediately realizing what is wrong: https://github.com/D-Programming-Language/phobos/pull/2966 [1] Sorry for singling out this one example here. While it is particularly demonstrative, I am certainly not intending to put Walter in a bad light. It's simply hard to get that stuff right, as templates can make it hard to accurately determine the complete public interface of a function. As pointed out in the PR, here are some more examples for this class of bugs from Phobos code, also written and reviewed by top D coders: https://issues.dlang.org/show_bug.cgi?id=14135 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14137 https://issues.dlang.org/show_bug.cgi?id=14138 Neither of those issues would have been prevented by your new guidelines; the code in question is already written in that way. Quite to the contrary, consequent application of minimal @trusted blocks or even the workaround you reject so strongly would have prevented all of the bugs except for 14138. David [1] The diff in question, for when the PR is fixed: https://github.com/klickverbot/phobos/commit/db647f62cb5279ae42ad98665cd60cdcdb9b3dd5
Re: Using reduce with user types
On 8/02/2015 1:47 a.m., Kadir Erdem Demir wrote:
I can use filter algorithm with my types easily.
struct A
{
string value;
int count;
}
void main( string[] args )
{
A[] aArr;
aArr ~= A(HTTP, 3);
aArr ~= A(HTTPS, 2);
aArr ~= A(UNKNOWN_TCP, 4);
aArr.filter!( a = a.count == 2);
But I couldn't compile when I want to use reduce algorithm. I simply
want to get the sum of count variables inside of A[].
auto sum = aArr.reduce!((a,b) = a.count + b.count);
The line above gives
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(770): Error:
cannot implicitly convert expression (__lambda3(result,
front(_param_1))) of type int to A
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(791): Error:
template instance app.main.reduce!((a, b) = a.count +
b.count).reduce!(A, A[]) error instantiating
source\app.d(363):instantiated from here: reduce!(A[])
How can I achieve summing count variables inside A[]?
Best Regards
Kadir Erdem Demir
Ps: The problem caused by my lack of D basics I admit, the reason I
can't look up references more before ask question I am in a bit tight
schedule. Sorry for my dummy questions.
auto sum = aArr.map!`a.count`.reduce!((a,b) = a + b);
Not much difference.
I tried sum instead of reduce, but it didn't work. Wouldn't matter much
as it is the same thing pretty much anyway.
Re: Using reduce with user types
On 2015-02-07 at 13:47, Kadir Erdem Demir wrote: auto sum = aArr.reduce!((a,b) = a.count + b.count); The line above gives C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(770): Error: cannot implicitly convert expression (__lambda3(result, front(_param_1))) of type int to A C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(791): Error: template instance app.main.reduce!((a, b) = a.count + b.count).reduce!(A, A[]) error instantiating source\app.d(363):instantiated from here: reduce!(A[]) // auto sum = aArr.reduce!((a,b) = a.count + b.count); // Wrong auto sum = reduce!((a, b) = a + b.count)(0, aArr); // Good See here: http://dlang.org/phobos/std_algorithm.html#.reduce
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 12:40:26 UTC, David Nadlinger wrote: Neither of those issues would have been prevented by your new guidelines; the code in question is already written in that way. Quite to the contrary, consequent application of minimal @trusted blocks or even the workaround you reject so strongly would have prevented all of the bugs except for 14138. This is an incredibly poor argument. The fact that there is no documentation for why the functions are @trusted and why they have to be @trusted is testament to a flawed process. If you insist on relying on half-assed flawed verification you only catch those instances where it should not have been @trusted in the first place, and which would have been caught at an early stage with a decent process, but you will keep missing out on the hard to detect cases. You will run into much more difficult problems if you don't do something about the safety review process. Fix the weak typing rather than making the language more convoluted, the latter compounds the problem in the long run.
Is NRVO part of the spec?
I'm writing a blog post about why we don't need rvalue references in D. It seems that we rely on NRVO being performed, not just as an optimization, but for correct semantics (e.g. for objects without destructors or postblits). This doesn't appear to be documented anywhere. Is it meant to be part of the spec? Relevant issues: See: https://issues.dlang.org/show_bug.cgi?id=10372 https://issues.dlang.org/show_bug.cgi?id=12180
Re: Is NRVO part of the spec?
On 2/7/15 6:35 AM, Daniel Murphy wrote: Peter Alexander wrote in message news:uiqnamficseklfowm...@forum.dlang.org... I'm writing a blog post about why we don't need rvalue references in D. It seems that we rely on NRVO being performed, not just as an optimization, but for correct semantics (e.g. for objects without destructors or postblits). This doesn't appear to be documented anywhere. Is it meant to be part of the spec? NRVO isn't required for correct semantics, as structs can be moved with bitcopy. It is required for structs that disable postblit. -- Andrei
Re: Zero-length static array spec
On 7 Feb 2015 12:50, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Saturday, 7 February 2015 at 12:10:45 UTC, Iain Buclaw wrote:
Some cod scenarios:
1. Comparisons of == fold into 'false' (unless comparing to self)
2. Comparisons of != fold into 'true' (unless comparing to self)
3. Conversion to dynamic arrays is { .length=0, .ptr=arr0 }
What does arr0 refer to?
A zero length static array.
And assuming that a0.ptr and a1.ptr would end up being the same in your
proposal, do you really want to have a situation where a0.ptr == a1.ptr
a0.length == a1.length but a0 != a1?
David
a0.ptr == a1.ptr // false, enforced by compiler. Comparison not actually
emitted.
a0.length == a1.length // true, both are 0
a0 != a1 // true, same effect as first.
Iain.
Re: Is NRVO part of the spec?
On Saturday, 7 February 2015 at 14:46:55 UTC, Daniel Murphy wrote:
NRVO isn't required for correct semantics, as structs can be
moved with bitcopy.
Yes, you're right. I suppose what I mean is that it should be
guaranteed that returning a local Lvalue by value should always
be moved to the caller destination, rather than copied then
destroyed.
S foo() {
S s;
return s;
}
S s = foo(); // no destructors or postblits should be called here
The spec needs to guarantee this, otherwise unary
std.algorithm.move isn't guaranteed to work for non-copyable
types.
Re: Is NRVO part of the spec?
On Saturday, 7 February 2015 at 15:02:43 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 6:35 AM, Daniel Murphy wrote:
Peter Alexander wrote in message
news:uiqnamficseklfowm...@forum.dlang.org...
I'm writing a blog post about why we don't need rvalue
references in
D. It seems that we rely on NRVO being performed, not just as
an
optimization, but for correct semantics (e.g. for objects
without
destructors or postblits). This doesn't appear to be
documented anywhere.
Is it meant to be part of the spec?
NRVO isn't required for correct semantics, as structs can be
moved with
bitcopy.
It is required for structs that disable postblit. -- Andrei
NRVO specifically means that a pointer to the destination object
is passed to the function, and the returned object is constructed
in place. The in place construction isn't required. What is
required is that the local is moved.
e.g.
S foo() {
S s;
return s;
}
S s = foo();
With NRVO becomes:
void foo(ref S dst) {
dst = S();
}
S s = void;
foo(s);
But this isn't necessary. Would also be valid to just do:
void foo(ref S dst) {
S s;
move(dst, s); // do the memcpys
}
S s;
foo(s);
This distinction matters because NRVO cannot be performed when
foo may return two different objects, but we can still move and
avoid postblit.
Re: Renaming DMD File Extensions from C to C++
On Saturday, 7 February 2015 at 06:23:43 UTC, ketmar wrote: On Fri, 06 Feb 2015 18:48:16 +, deadalnix wrote: Well you are talking for talking, we are waiting on your awesome PRs. easy deal. and i'm waiting for Andrei and Walter preapprovement. i'm not interested in writing code for nothing. ah, and forbidding patch attachements to bugzilla. i'm still waiting for my $25 bounty, code for which keeps rotting there. Ketmar as a kid: https://www.youtube.com/watch?v=iayLBI7nsE0
Re: static alias this
Another try
E)---
struct StaticRegister {
static private uint _value;
@property static uint value() { return _value; }
@property static void value(uint v) { _value = v; }
static uint opCall(){return _value;}
alias _value this;
}
void main(string[] s) {
StaticRegister = 1;
assert(StaticRegister()==1);
}
Yes you're right, it's a bit strange that the writer works...does
the expression 'static this' make sense ?!
Re: Is NRVO part of the spec?
Peter Alexander wrote in message news:uiqnamficseklfowm...@forum.dlang.org... I'm writing a blog post about why we don't need rvalue references in D. It seems that we rely on NRVO being performed, not just as an optimization, but for correct semantics (e.g. for objects without destructors or postblits). This doesn't appear to be documented anywhere. Is it meant to be part of the spec? NRVO isn't required for correct semantics, as structs can be moved with bitcopy.
Re: @trust is an encapsulation method, not an escape
On 2/7/15 4:40 AM, David Nadlinger wrote: On Friday, 6 February 2015 at 18:52:45 UTC, Andrei Alexandrescu wrote: I think the problem is overstated. -- Andrei I think there could hardly be a more persuasive argument that this belief is wrong than Walter himself just having made the mistake several times, and not even immediately realizing what is wrong: https://github.com/D-Programming-Language/phobos/pull/2966 [1] Sorry for singling out this one example here. While it is particularly demonstrative, I am certainly not intending to put Walter in a bad light. It's simply hard to get that stuff right, as templates can make it hard to accurately determine the complete public interface of a function. As pointed out in the PR, here are some more examples for this class of bugs from Phobos code, also written and reviewed by top D coders: https://issues.dlang.org/show_bug.cgi?id=14135 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14137 https://issues.dlang.org/show_bug.cgi?id=14138 Neither of those issues would have been prevented by your new guidelines; the code in question is already written in that way. Quite to the contrary, consequent application of minimal @trusted blocks or even the workaround you reject so strongly would have prevented all of the bugs except for 14138. David [1] The diff in question, for when the PR is fixed: https://github.com/klickverbot/phobos/commit/db647f62cb5279ae42ad98665cd60cdcdb9b3dd5 Nice, thanks for this work. One good guideline here is to almost always let generic code rely on deduction instead of ascribing safety attributes to it. Andrei
Re: @trust is an encapsulation method, not an escape
https://github.com/klickverbot/phobos/commit/db647f62cb5279ae42ad98665cd60cdcdb9b3dd5 Nice, thanks for this work. One good guideline here is to almost always let generic code rely on deduction instead of ascribing safety attributes to it. Andrei And making this work in functions that already marked @trusted and need to be, but should have some parts inferred is the hole point of this thread and the @trusted-misuse in phobos.
Re: Using reduce with user types
auto sum = aArr.map!`a.count`.reduce!((a,b) = a + b); Rikki Thanks a lot. It works. Function map!a.count(aArr) surprises me a little. Because when I read std.algorithm reference: `Implements the homonym function (also known as transform)`. Which reminds me C++ transform and it will never used for returning a element of the struct. I expect transform to modify the elements of the range but in D it seem to me it also used traversing the elements. How can I imagine what map does in my mind, because it doesn't matches with the transform concept in my mind? Regards Kadir Erdem
Re: Zero-length static array spec
On 2015-02-07 at 13:21, Iain Buclaw via Digitalmars-d wrote: foo(p.data)// fine, ubyte* This is OK - gets passed as ubyte* bar(p.data[i]) // fine, ubyte (or memory violation) This is OK - gets passed as ubyte - though will throw arrayBounds error unless -noboundschecks. xxx(p.data) // ERROR, makes no sense, shouldn't compile This is OK - gets passed as ubyte[] - the dynamic array will have a length of '0' and the ptr to p.data. Oh, I see. That is quite a nice solution. Better than compilation error.
Re: GCs are complicated beasts: .NET Core, 35000 lines
On 2015-02-06 17:17, Andrei Alexandrescu wrote: I see. Not surprising - some teams at Facebook also prefer phabricator over github for reviews (others don't). I'm using both and phabricator is somewhat - but not dramatically - better. Any specifics you can point out where phabricator is better? -- /Jacob Carlborg
internal compiler error with immutable
Hi,
I'm trying to use immutable class instances and that seems to be
really difficult.
For example, with the following program I get an internal
compiler error:
cut-
import std.outbuffer : OutBuffer;
import std.typecons : Rebindable;
enum Attrkey : ubyte {
Fgcolor,
Bgcolor,
}
enum MAX_COMPRESSED_ATTRS = 128U;
alias Codes = Rebindable!(Attrs)[MAX_COMPRESSED_ATTRS];
static shared Codes codes;
private class Attrsp {
immutable(Attrsp) next;
Attrkey key;
ubyte value;
private this(Attrkey key, ubyte value, immutable(Attrsp) next) {
this.next = next;
this.key = key;
this.value = value;
}
// FIXME allow comparing the entire chain for equality.
private immutable void print(OutBuffer destination /*
destination */) {
destination.write(Attrs();
destination.write(cast(ubyte) key); // FIXME .toString()
destination.write(, );
destination.write(value);
destination.write(, \n);
if(this.next is null)
destination.write(null);
else
next.print(destination);
destination.write());
}
override immutable string toString() {
auto destination = new OutBuffer();
print(destination);
return destination.toString();
}
// TODO add newless static opCall which also does compression?
/*doesn't work static immutable immutable(Attrsp) opCall(Attrkey
key, ubyte value, immutable(Attrsp) next) {
return new immutable Attrsp(key, value, next);
}*/
alias Code = ubyte;
/* Compresses the given attributes into 1 Byte, if possible.
Returns MAX_COMPRESSED if it's not possible. */
static Code compress(immutable(Attrs) node) { // FIXME make
thread safe
ubyte i;
for(i = 0U; i MAX_COMPRESSED_ATTRS; ++i) {
if(codes[i] is null) {
codes[i] = node;
return i;
} else if(codes[i] == node)
return i;
}
return i; // tell that it didn't work.
}
static immutable(Attrs) uncompress(Code value) {
assert(value = 0U value MAX_COMPRESSED_ATTRS);
return codes[value];
}
}
alias Attrs = immutable(Attrsp);
cut-
gdc A.d
cc1d: ../../src/gcc/d/dfrontend/statement.c:293:
ErrorStatement::ErrorStatement(): Assertion `global.gaggedErrors
|| global.errors' failed.
cc1d: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions.
gdc (Debian 4.9.1-19) 4.9.1
cut-
What I'm trying to do is save space by putting often-used Attrs
into an array and just compressing references to those into 1
Byte in the other data structures where it's used (these other
data structures are not thread-local). Why do I need Rebindable
to begin with? I'm not even trying to modify the contents of the
instance, I'm just trying to assign another one to the array slot
(actually not even another one - it was null before).
Re: Git, the D package manager
On 2015-02-05 05:43, Vladimir Panteleev wrote: Is it a default if you can't change it? Or can it be changed? It can be changed. It's the mainSourceFile field [1]. It is not a question of preference, it is a question of the behavior being incompatible with certain tools and workflows. Sure it is, since this can be configured. [1] http://code.dlang.org/package-format -- /Jacob Carlborg
Re: Git, the D package manager
On 2015-02-04 23:00, Mike Parker wrote:
Then you specify a specific version of the library as a dependency,
rather than a version range.
No, this is not enough. The tool need to automatically track and lock
the whole dependency graph. Example:
Project A:
dependencies: {
b: 1.0.0
}
Project B:
dependencies: {
c: =1.0.0
}
Even though you have locked your direct dependencies to a specific
version doesn't mean that the dependencies have done so. Meaning, you
can get arbitrary versions of indirect dependencies. You can start
adding the indirect dependencies as direct dependencies but that defeats
the point of a package manager.
I have explained this so many times in the Dub forum, why not locking
the whole graph is a really, really bad idea.
I've experienced this myself many times with Ruby before it got Bundler
which fixes this.
--
/Jacob Carlborg
Re: GCs are complicated beasts: .NET Core, 35000 lines
On 2/7/15 6:26 AM, Jacob Carlborg wrote: On 2015-02-06 17:17, Andrei Alexandrescu wrote: I see. Not surprising - some teams at Facebook also prefer phabricator over github for reviews (others don't). I'm using both and phabricator is somewhat - but not dramatically - better. Any specifics you can point out where phabricator is better? E.g. comments are batched together, making one review one cohesive unit. People can't edit one another's comments. -- Andrei
Re: @trust is an encapsulation method, not an escape
And I'll add this: Please do not turn the compiler into a inadequate verification tool. The compiler should do what it can do well, but what it cannot do it should not do at all and leave to an external verification tool. @trusted basically tells the compiler this is beyond your capability so we left it to someone else. Third parties should be able to provide incrementally improved verification tools, for various purposes, without mandating language or compiler changes. So what you want from the language is simple clean semantics and reasonable best practice annotations for verification that can be extended based on the needs in a particular environment.
Re: Git, the D package manager
On 2015-02-05 15:11, Sönke Ludwig wrote: There is a request to make this configurable and it's a rather trivial addition. I just don't have the time to implement all feature requests myself, which is basically why it is not implemented, yet. Is the reason for putting it in the home directory to be able to share builds between packages? -- /Jacob Carlborg
Re: Is NRVO part of the spec?
Andrei Alexandrescu wrote in message news:mb59ej$2j7s$1...@digitalmars.com... NRVO isn't required for correct semantics, as structs can be moved with bitcopy. It is required for structs that disable postblit. -- Andrei IIRC they only require that no copies are made. They can still be moved.
Re: Is NRVO part of the spec?
Peter Alexander wrote in message
news:gverkczeotvadwmdo...@forum.dlang.org...
Yes, you're right. I suppose what I mean is that it should be guaranteed
that returning a local Lvalue by value should always be moved to the
caller destination, rather than copied then destroyed.
S foo() {
S s;
return s;
}
S s = foo(); // no destructors or postblits should be called here
The spec needs to guarantee this, otherwise unary std.algorithm.move isn't
guaranteed to work for non-copyable types.
Yeah, the spec needs to guarantee no copies. Kenji Hara has done some work
on this.
Re: signal handling
On Friday, 6 February 2015 at 19:40:44 UTC, Danny wrote: Hi, if I want to clean up inside a signal handler and then exit the process (as it would have without me handling it), what do I do? Can I exit() inside a signal handler or should I use a more direct quit now function? (after all, it could have been in the middle of relinking the free list when the signal arrived) I'm using a basic C-style sigaction with core.sys.posix.signal and calling std.c.stdlib:exit. For context, I'm performing serial communication with an actual device so the signal may come when my code is blocked in an vendor API call or on an underlying syscall. I have very little state so I'm doing equally little beside freeing extern handles. Setting a global flag and testing it didn't really prove adequate and littered the checks everywhere so I'm thinking now of leveraging std.signals but I'm not sure that will be reliable.
Re: signal handling
Hi rlonstein,
I've now read up on the opengroup pages about signal handling
(which references POSIX), and apparently it goes like this:
A signal can be delivered to a specific thread or to a process.
If it's delivered to a process, a random thread of that process
will receive it. If it's delivered to a thread, that thread will
receive it. sigaction() thus seems to be required per-thread. The
handler of a random thread will usually be called.
I've now settled on:
- per thread, register signal handler using sigaction with a mask
that blocks all the cleanup signals while the handler is running.
Remember the old handler in TLS variable.
- in the signal handler, clean up (just use the write syscall to
make it sane), then use sigaction to reinstall the old signal
handler, and then call raise().
Seems to work fine so far. Not sure whether it's safe to raise()
inside a signal handler. Calling raise() without reinstalling the
old signal handler is a very bad idea, I tried. Interesting is
that, after reinstalling the old signal handler, I can raise()
inside the signal handler even though it's blocked. It probably
gets queued in the kernel for the thread. Then the handler
returns and it processes the queue, calling the old handler. So
win win?
See
http://svn.nomike.com/playground/trunk/L1/D/TUI/Terminalclient.d,
bottom. Note that I don't distinguish between whether I'm in the
correct thread or not since for my use case it's not necessary.
The FD is always the same and who cares who resets the terminal...
I have very little state so I'm doing
equally little beside freeing extern handles.
Yeah, same for me, really.
Setting a global flag and testing it didn't really prove
adequate and littered the checks everywhere
Yeah,I don't think that EINTR and flag-checking is even safe.
What if you check the flag (and see nothing happened) and then go
back to the loop and block (in read() or whatever), and right
after the flag checking, unbeknowst to you the signal handler
sets the flag, returns, and only then you block in read()? You'd
block forever.
Do you know signalfd() ?
I know how it is with external libaries, they always block at the
silliest of times. But I've had one (OKAPI) which gave me the FD
back, so I could select() on a bunch FDs in my mainloop. In that
case, signalfd() was nice since it showed up as a normal read
ready in select(), i.e. as a normal event source. Might be
worth a try in your case?
Like this, in pseudo-code:
while (!error) {
auto readyfd = select([signalfd, externalfd]);
if (readyfd == signalfd)
... signal (would have) happened, handle it
else if (readyfd == externalfd)
vendor_read_chunk();
else ...
}
so I'm thinking now of leveraging std.signals but I'm not sure
that will be reliable.
Hmm, I don't know that one yet.
[Issue 14115] Copy dlang.org's look and feel to the wiki
https://issues.dlang.org/show_bug.cgi?id=14115 --- Comment #1 from Zach the Mystic reachz...@gmail.com --- I wasn't able to find the code which affects the look and feel of the wiki, to play around with it. Hopefully it's easily changeable. For background, some selected (and modified) quotes from the link above: IMO, the most important thing *is* the Wiki, but a newcomer might not know that, so they must be told. If I try to decide the best link for them I'll just be duplicating the effort done on the Wiki page. Just send people to the Wiki. It has the best current information about what to do and where to go. I think the Wiki should be the main place to go to get information on D. Dlang.org should be concise and formal, containing only the more permanent information. D doesn't have a wealthy funder to pay for building a single unified website experience. I'm follow the evidence. Dlang.org should say, regarding the Wiki, If you can't beat 'em, join 'em. And by referring people there to begin with, more effort will be put into it... Please compare the Wiki to dlang.org. I don't think dlang.org can keep up. That said... we should copy the look-and-feel from dlang to the Wiki, so it feels like the same website, creating the illusion of unity. --
[Issue 14115] Copy dlang.org's look and feel to the wiki
https://issues.dlang.org/show_bug.cgi?id=14115 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Zach the Mystic from comment #1) I wasn't able to find the code which affects the look and feel of the wiki, to play around with it. Hopefully it's easily changeable. If you can create a MediaWiki skin, I can review and add it. I would like to ask, however, that it copies as little code from dlang.org as possible, and instead integrates with the makefile to produce the necessary skin files. This is to minimize future maintenance effort for inevitable future dlang.org changes. --
Re: internal compiler error with immutable
Hi, I've filed it with gdcproject.org before reading your reply. Will it be forwarded to issues.dlang.org or should I file it there as well? Also, it seems there's a new DMD release underway right now, does it still happen with that? (I tried but can't get it to build - doesn't seem to support ARMHF target)
Fun with floating point
Hi, D community!
I have this program:
import std.stdio;
import std.conv;
int main(string[] argv)
{
float eps = 1.0f;
float f = 0.0f;
while (f + eps != f)
f += 1.0f;
writeln(eps = ~ to!string(eps) ~ , max_f = ~
to!string(f));
return 0;
}
According to the languge specification what result would you
expect from its execution?
When running similar C++ program (VS 2013) the loop terminates
and I get t = 2^24 = 16777216.
Does D language specifies that loop will be terminated for this
program or ?
I compiled with DMD and it hungs.
Details about assembly generated by DMD can be found here:
http://stackoverflow.com/questions/28380651/floating-point-maxing-out-loop-doesnt-terminate-in-d-works-in-c
Thanks.
Re: Fun with floating point
And sory for the typos, cannot find edit functionality here..
Re: Is NRVO part of the spec?
On 2/7/15 8:02 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
NRVO isn't required for correct semantics, as structs can be moved with
bitcopy.
It is required for structs that disable postblit. -- Andrei
IIRC they only require that no copies are made. They can still be moved.
Exactly - as you just said in the other post, the spec must clarify when
things are guaranteed to be moved and not copied.
That includes:
1. URVO: returning an rvalue does not entail a copy.
2. Last return of a function local variable does not entail a copy.
That's actually more than NRVO because NRVO requires the same local be
returned from all paths. Example:
T fun(bool b) {
if (b) { T a; return a; }
T b;
return b;
}
This should work if T is noncopyable. It may be less efficient than it
could though.
3. The more complicated/ambitious cases involve the last use of a value.
Consider:
T fun() {
T a;
T b = a;
return b;
}
Even though the code ostensibly makes a copy, it's the last use of a so
that could be a move.
I think (3) could be used for optimization but it's too much of a
headache to put in the language definition. We do need to have (1) and
(2) covered.
Andrei
[Issue 14124] BigInt %= int can return -0
https://issues.dlang.org/show_bug.cgi?id=14124 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/1cabeac6da6ce691a31bf4654179f222a0956137 Fix Issue 14124 - BigInt %= int can return -0 https://github.com/D-Programming-Language/phobos/commit/9f6e1c33be2001bb44cfcb53f78441b75eb1c718 Merge pull request #2959 from e10s/patch-7 Fix Issue 14124 - BigInt %= int can return -0 --
[Issue 14124] BigInt %= int can return -0
https://issues.dlang.org/show_bug.cgi?id=14124 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14104] aa with pointer key type doesn't find existing value
https://issues.dlang.org/show_bug.cgi?id=14104 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/13d0da1e7ec9a02bf7757e6d1cf6470f59cf6ff5 Merge pull request #4389 from rainers/issue14104 fix issue 14104 - nuke getInternalTypeInfo --
[Issue 14141] New: `pure` member function returning qualified member result is implicitly convertible to unqualified
https://issues.dlang.org/show_bug.cgi?id=14141
Issue ID: 14141
Summary: `pure` member function returning qualified member
result is implicitly convertible to unqualified
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code should compile:
---
struct S
{
Object obj;
const(Object) getObj() const pure
{ return obj; }
}
void main()
{
const S s;
static assert(is(typeof(s.getObj()) == const Object)); // ok
static assert(!__traits(compiles, { Object o = s.getObj(); })); // fails
}
---
As a result such function compiles but shouldn't:
---
Object f(const Object o)
{
const S s = { obj: o };
return s.getObj();
}
---
This results in type system breakage.
--
Re: Using reduce with user types
On Saturday, 7 February 2015 at 13:38:00 UTC, Kadir Erdem Demir
wrote:
How can I imagine what map does in my mind, because it
doesn't matches with the transform concept in my mind?
You can think of map as taking a range of something (in this
case, an array of A), and calling a user-supplied function on
each element in that range. The user-supplied function is a
function that describes how to map each value in the range to a
result. In your case, the function defines how to map from an A
to its `count` member variable (it is a function of type A-int).
All aArr.map!`a.count` means is that for each A in aArr, return
its `count` member. map!`a.count` is some syntax sugar D has to
make function calls shorter; It expands to the following:
aArr.map!((A a) {
return a.count;
})
The main difference between `map` in D and `transform` in C++ is,
I believe, twofold. First off, `transform` is eager, meaning it
does as much work as possible as son as possible. On the other
hand, `map` does as little work as possible as late as possible.
For the following code:
iota(10).map!(n = writeln(n)).take(5).array
Only 0 1 2 3 4 will be printed, as map is lazy and will not do
work it doesn't have to.
Second of all, map returns a range that is the result of applying
the supplied function to each element of aArr. C++'s tranform
copies the result to another user-supplied range. If you wanted
the equivalent of transform in C++, you could do this:
auto result = new int[](10);
iota(10).map!(n = n + 1).copy(result)
And result will be filled with the results of map.
Re: internal compiler error with immutable
On Sat, Feb 07, 2015 at 02:35:13PM +, Danny via Digitalmars-d-learn wrote: [...] cut- gdc A.d cc1d: ../../src/gcc/d/dfrontend/statement.c:293: ErrorStatement::ErrorStatement(): Assertion `global.gaggedErrors || global.errors' failed. cc1d: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. gdc (Debian 4.9.1-19) 4.9.1 cut- [...] Please file a bug at http://issues.dlang.org/. Compiler internal errors are *always* bugs that need to be fixed. Thanks! T -- English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall
Re: Git, the D package manager
On Saturday, 7 February 2015 at 14:36:19 UTC, Jacob Carlborg wrote: On 2015-02-05 05:43, Vladimir Panteleev wrote: Is it a default if you can't change it? Or can it be changed? It can be changed. It's the mainSourceFile field [1]. I don't see how this setting is at all relevant to the problem at hand.
[Issue 14142] New: combine standard ddoc-umentation and wiki-style editing on single pages
https://issues.dlang.org/show_bug.cgi?id=14142 Issue ID: 14142 Summary: combine standard ddoc-umentation and wiki-style editing on single pages Product: D Version: unspecified Hardware: x86 OS: All Status: NEW Severity: enhancement Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: reachz...@gmail.com For me, the power of wiki-style editing is pretty convincing. It seems generally agreed that what documentation can be easily edited, should be. Existing in-code documentation requires the review process, which is at odds with the lightning quick way a wiki page is normally changed. This enhancement proposes an intermediate solution to the problem. Each std function, for example, will have a top (or bottom) window which formats and copies the existing embedded ddoc-umentation, while at the bottom (or top) providing a freestyle wiki window. Editing the embedded docs from the wiki page will still be a little clunky like it is now (with the improve this page button), because of github pulls and the review process, but editing the wiki window will harness the power of wiki. In other words, you shouldn't have to click Page wiki to get to the wiki, and no Wiki page should exclude what's already in the ddocs. The documentation and the wiki should be the same page, while working around the existing barriers to accomplishing this. The transition could be piecemeal, with a wiki window being merged onto the dlang.org page one function at a time, or, conversely, with links to functions with wiki pages somehow overriding the default dlang.org page. Basically, I want everyone to be on the same page (pun intended). --
Re: strange work of GC
Why do you want to use destroy? The destroy method always calls a dtor of the objects, where I can destroy some object's variables in that order that I need, I think. And this is very good for me, because I have a full control of the object's destroying stage. But if I use the GC, I have no garanties that the dtors will be called, therefore some of my methods will not be called too. In this case it would be better to disable automatically garbage collection in my D app, elsewise once app will be failed (manual destroying idiom). On another hand if I use only GC (automatically destroying idiom), I have to disable destroy method and all dtors of the objects, so that nobody can call destroy method. Otherwise app will be failed once again. Two idioms are existing in one app at the same time have more possiblities for D programmers to make hard errors in their code, and it is confusing me sometimes. For example, .Net (C#) have no dtors and destroy methods. It is a very good idiom, because no confusions occur.
Re: Special Type Challenge
On Saturday, 7 February 2015 at 05:27:39 UTC, Andrei Alexandrescu wrote: On 2/6/15 8:28 PM, Jonathan Marler wrote: Do you know if D might support that later or if there's a reason for not supporting it? It's deliberate following the C++ experience. -- Andrei Hasn't there been a debate about a hypothetical `opImplicitCast()`? The default would still be off, but you can opt-in by defining said method.
[Issue 14139] GIT HEAD : PI now has wrong value
https://issues.dlang.org/show_bug.cgi?id=14139 Orvid King blah38...@gmail.com changed: What|Removed |Added CC||blah38...@gmail.com --- Comment #3 from Orvid King blah38...@gmail.com --- Which version of MSVC? I use a 64-bit DMD compiled by MSVC 2010 with link-time code gen (/LTCG) and whole program optimization (/GL), and have no issues here. Is it possible that you've changed the floating point model in your build to something other than precise (/fp:precise)? --
Re: Is NRVO part of the spec?
On Saturday, 7 February 2015 at 16:10:48 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 8:02 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
NRVO isn't required for correct semantics, as structs can
be moved with
bitcopy.
It is required for structs that disable postblit. -- Andrei
IIRC they only require that no copies are made. They can
still be moved.
Exactly - as you just said in the other post, the spec must
clarify when things are guaranteed to be moved and not copied.
That includes:
1. URVO: returning an rvalue does not entail a copy.
2. Last return of a function local variable does not entail a
copy.
I think this needs to be phrased differently: Any returned value
can be moved iff none of the destructors, scope(exit)'s and
finallys that are run as part of the cleanup can possibly access
the value's original location. (I assume that the move happens
_before_ the destructors are called. This is reasonable because
otherwise said destructors could modify the returned value in
flight.) This formulation also encompasses rvalues.
That's actually more than NRVO because NRVO requires the same
local be returned from all paths. Example:
T fun(bool b) {
if (b) { T a; return a; }
T b;
return b;
}
This should work if T is noncopyable. It may be less efficient
than it could though.
3. The more complicated/ambitious cases involve the last use of
a value. Consider:
T fun() {
T a;
T b = a;
return b;
}
Even though the code ostensibly makes a copy, it's the last use
of a so that could be a move.
This is arguably different, because it doesn't involve a return.
I think (3) could be used for optimization but it's too much of
a headache to put in the language definition. We do need to
have (1) and (2) covered.
Andrei
Re: Issue with template function
On Saturday, 7 February 2015 at 12:04:12 UTC, Nicholas Wilson
wrote:
Are you wanting to to convert each element in arr to a byte
thus truncating and losing data (when T.sizeof != 1)?
as in
toBytes([1,2,3, 42, 500 /*this will be truncated to 244
*/]);// T == int here
or are you wanting to convert each element to a ubyte array and
then concatenate it to the result.
as is
ubyte[] toBytes(T)(T[] arr)
{
ubyte[T.sizeof] buf;
if (arr is null)
{
return null;
}
ubyte[] result = new ubyte[arr.length * T.sizeof];
foreach (i, val; arr)
{
buf[] = cast(ubyte[T.sizeof])(arr[i])[0 ..
T.sizeof]
result ~= buf;
}
return result;
}
?
The original code I was using was written in Java, and only had a
method for strings. This is closer to what I wanted. My unit
tests were just going back and forth with readString function, so
I was completely missing this for other types. Nice catch!
There were a couple issues with your code so I've included the
corrected version:
ubyte[] toUbytes(T)(T[] arr)
{
if (arr is null)
{
return null;
}
ubyte[T.sizeof] buffer;
ubyte[] result = new ubyte[arr.length * T.sizeof];
foreach (i, val; arr)
{
buffer[] = cast(ubyte[T.sizeof])((arr[i]))[0 ..
T.sizeof]; // Parenthesis and missing semicolon
result[i * T.sizeof .. (i * T.sizeof) + T.sizeof] =
buffer; // Specify appropriate slice for buffer to be inserted
into
}
return result;
}
[Issue 14143] New: signals: SIGWINCH, SIGSYS, SIGSTKFLT, SIGPWR missing
https://issues.dlang.org/show_bug.cgi?id=14143 Issue ID: 14143 Summary: signals: SIGWINCH, SIGSYS, SIGSTKFLT, SIGPWR missing Product: D Version: D2 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: danny.m...@gmail.com Some of the signal numbers are missing in druntime. I needed SIGWINCH and on the occassion checked and updated all the Linux signal definitions. --
[Issue 14124] BigInt %= int can return -0
https://issues.dlang.org/show_bug.cgi?id=14124 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/1cabeac6da6ce691a31bf4654179f222a0956137 Fix Issue 14124 - BigInt %= int can return -0 https://github.com/D-Programming-Language/phobos/commit/9f6e1c33be2001bb44cfcb53f78441b75eb1c718 Merge pull request #2959 from e10s/patch-7 --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #20 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/21aba9efeaf9eacd7da3d2585519b083355b9b78 Fixed issue 14126 -- Used wrong constant for offset when finalizing a large array. https://github.com/D-Programming-Language/druntime/commit/1c5aef8b9d58718b633d2a45ca09b5f9dd1ab6bc Merge pull request #1159 from schveiguy/issue14126 --
[Issue 7151] [CTFE] cannot compare classes with ==
https://issues.dlang.org/show_bug.cgi?id=7151 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/8a3ea8160d940dc22916cbd3e18e5eb19ece8b28 mostly fix Issue 7151 - [CTFE] cannot compare classes with == https://github.com/D-Programming-Language/druntime/commit/8c13443c436a453e01c6319f74e2e6d54f44a547 Merge pull request #916 from NilsBossung/7151 --
[Issue 14131] va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/ee94dbddf7700a5e5864d485e66002e31e6fa670 Partial fix for Issue 14131 - va_copy is broken on posix X86_64 https://github.com/D-Programming-Language/druntime/commit/02270ea991f4218764d2c2cc867c56f082672d4c Merge pull request #1158 from yebblies/va_copy --
[Issue 14059] Formatted write with wrong formatting string
https://issues.dlang.org/show_bug.cgi?id=14059 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/806361692978e538ed782287d796e58b2ed5b8df Issue 14059 - Formatted write with wrong formatting string https://github.com/D-Programming-Language/phobos/commit/3299c63e7500e6eeb9f5f3c9f8f3ec501fde6064 Merge pull request #2958 from sinkuu/fix_14059_format --
[Issue 12153] Ternary operator on static array lvalues creates copy
https://issues.dlang.org/show_bug.cgi?id=12153 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/bdb30977e7084d1c496c7b386203af8dd33eea0d Move fix Issue 12153 to frontend https://github.com/D-Programming-Language/dmd/commit/e62c349db2f20f8ea709314bcbca16540c6cfc35 Merge pull request #4062 from ibuclaw/fix12153 --
[Issue 14143] signals: SIGWINCH, SIGSYS, SIGSTKFLT, SIGPWR missing
https://issues.dlang.org/show_bug.cgi?id=14143 --- Comment #1 from Danny Milosavljevic danny.m...@gmail.com --- https://github.com/D-Programming-Language/druntime/pull/1161 --
[Issue 14130] [REG2.067a] ICE following error in template parameter default value
https://issues.dlang.org/show_bug.cgi?id=14130 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5dd31fa1a3118e7cd522e6a3400957b31ecbed71 fix Issue 14130 - ICE following error in template parameter default value https://github.com/D-Programming-Language/dmd/commit/f51b7bb77de736bce051b1c1556b17e53e51b99f Merge pull request #4386 from 9rnsr/fix14130 --
[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 --- Comment #9 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e5f21beb82acade73900aa50a0e092b3935e980b fix Issue 13952 - change in struct ctor lowering triggers codegen bug https://github.com/D-Programming-Language/dmd/commit/2ebb60303208768adfa29d29f11f7fc8c95fffa7 Merge pull request #4387 from 9rnsr/fix13952 --
[Issue 14123] cannot compare typeid(object.Object) at compile time
https://issues.dlang.org/show_bug.cgi?id=14123 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3c195275a852d4aff6e33454cc700e2687898a01 fix Issue 14123 - cannot compare typeid(object.Object) at compile time https://github.com/D-Programming-Language/dmd/commit/ae5fffaa6ea81f5a0665e6f848615dfe0ada Merge pull request #4383 from 9rnsr/fix14123 --
[Issue 14104] aa with pointer key type doesn't find existing value
https://issues.dlang.org/show_bug.cgi?id=14104 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/13d0da1e7ec9a02bf7757e6d1cf6470f59cf6ff5 Merge pull request #4389 from rainers/issue14104 --
[Issue 14131] va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/143f780fa6d5fd692d25b8f8318c73f5722616b9 Add test case for Issue 14131 - va_copy is broken on posix X86_64 https://github.com/D-Programming-Language/dmd/commit/97f5400129a489b31f4378cf9a1776ba0debc4b3 Merge pull request #4385 from yebblies/va_copy --
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:21:50 UTC, weaselcat wrote: On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote: No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions. This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! this sounds interesting, is anyone going to make a DIP for it? It was Teoh's idea. Maybe he should have the honors?
Re: Zero-length static array spec
On Saturday, 7 February 2015 at 12:10:45 UTC, Iain Buclaw wrote:
On 6 February 2015 at 23:42, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 6 February 2015 at 23:37:30 UTC, Iain Buclaw wrote:
Simple, you implement it by allocating no memory. :)
Let me put it a different way. Imagine you have this in your
program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that
they are
distinct, but you don't end up allocating 100 bytes of stack
memory?
David
There are no addresses for them, you can't do *anything* with
them at runtime.
Some cod scenarios:
1. Comparisons of == fold into 'false' (unless comparing to
self)
2. Comparisons of != fold into 'true' (unless comparing to
self)
Why's that? Shouldn't _all_ 0 size variables compare equal? I'd
say that follows from the definition:
array1 == array2
=
all corresponding elements of both arrays are equal
=
no corresponding elements of both arrays are different
For the last one, it's obvious that this applies to empty arrays:
they don't even contain elements that could compare unequal.
Or maybe you're only talking about the addresses here?
Re: Is NRVO part of the spec?
On Saturday, 7 February 2015 at 16:10:48 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 8:02 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
NRVO isn't required for correct semantics, as structs can
be moved with
bitcopy.
It is required for structs that disable postblit. -- Andrei
IIRC they only require that no copies are made. They can
still be moved.
Exactly - as you just said in the other post, the spec must
clarify when things are guaranteed to be moved and not copied.
That includes:
1. URVO: returning an rvalue does not entail a copy.
2. Last return of a function local variable does not entail a
copy.
That's actually more than NRVO because NRVO requires the same
local be returned from all paths. Example:
T fun(bool b) {
if (b) { T a; return a; }
T b;
return b;
}
This should work if T is noncopyable. It may be less efficient
than it could though.
3. The more complicated/ambitious cases involve the last use of
a value. Consider:
T fun() {
T a;
T b = a;
return b;
}
Even though the code ostensibly makes a copy, it's the last use
of a so that could be a move.
I think (3) could be used for optimization but it's too much of
a headache to put in the language definition. We do need to
have (1) and (2) covered.
Andrei
Perfect. Clear and reasonable.
