Re: Fiber based UI-Toolkit

[bauss via Digitalmars-d-learn]

On Monday, 10 July 2017 at 08:40:15 UTC, Jacob Carlborg wrote:

On 2017-07-09 23:12, bauss wrote:

I believe OSX (possibly macOS too.) only allows it from the 
main thread.


Yes, that's correct. But what's the difference between OSX and 
macOS ;)


Well besides that it's newer versions of the OS, then nothing 
much I guess. It could potentially change such specs though.

[Issue 17632] [REG 2.075-b1] opBinary and delegate code generation

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||ice
 CC||bugzi...@digitalmars.com

--

Re: Fiber based UI-Toolkit

[Gerald via Digitalmars-d-learn]

On Monday, 10 July 2017 at 14:03:59 UTC, Jacob Carlborg wrote:

On 2017-07-10 15:37, Gerald wrote:

Having said that, I'm in the camp where this doesn't make much 
sense. Using fibers on the main UI thread is likely going to 
result in a blocked UI whenever a fiber takes too long to do 
its work. History has shown that cooperative multi-tasking 
typically doesn't work well for UI applications.


It's that basically the whole idea of async/await? Seems like 
Microsoft is pushing quite heavily for that in GUI code.


Thanks for the link, I'm not active with .Net so I had to go look 
it up. Reminds me a lot of the way node.js works. If all your 
async activity is IO bound maybe it works fine and I'm wrong 
about this.



My past experience has been that it's challenging to determine 
the appropriate times to yield particularly with a lot of async 
activity happening. However with it baked into the framework and 
a simplified API maybe it becomes less of an issue.


I'll have to do more reading on it, again thanks for the pointer.

Re: Why no offsetof for static struct?

[Mike Parker via Digitalmars-d-learn]

On 7/11/2017 6:14 AM, FoxyBrown wrote:

On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote:


No, it isn't. Static members are stored in an entirely different place 
than non-static members. They are really just global variables in 
memory with their in-source name being nested somewhere else.



This is not true, just because there isn't any official statement, or 
even if denied, does not make it true. I have proof:


auto GetStaticAddress(T)()
{
 mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
 return p;
}


Returns the address of a struct's static members.

It's pretty obvious, the compiler seems to instantiate the static 
members simply as a sort of "singleton". They are laid out with the same 
relative offsets as the struct(which is obvious, as that is the most 
natural way). That is all that is needed to treat the memory the static 
variables use as the struct in which they are part of. No need to make 
it any more complex than that.




Every variable has an address. That includes static members of a struct. 
But their location has absolutely no relationship to any instance of a 
struct. They have a fixed location in memory. Consider:


module Foo;
int x;
struct Bar {
static int y;
int z;
}

There is effectively no difference between x and y here. The only 
difference is that Bar is part of y's namespace, so you can access them 
like so:


Foo.x;
Foo.Bar.y;

y's location has no relationship to any instance of Bar, and the 
declaration of the Bar type has no address. Of course you can take the 
address of y, as , but you can also take the address of x. Take y 
out of Bar and the only difference is that you no longer need Bar as 
part of the namespace.  On the other hand:


Bar b;
writeln(b.z);

As an instance of Bar, b *does* have a location in memory. And z *does* 
have an offset that is relative to that location.


So y.offsetof does not exist, because there is no instance of Bar to 
which it can have a relative address.

Re: Debugging D applications from VS code with webfreak.debug

[Domain via Digitalmars-d-learn]

On Friday, 24 February 2017 at 13:19:53 UTC, FR wrote:

On Friday, 24 February 2017 at 03:15:11 UTC, Jerry wrote:
You can use the C++ plugin, which provides a debugger. Just 
make sure you aren't using optlink, I don't think it generates 
compatible files. Also you might need to use "-gc" which 
generates debug names to be in C format.


https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools

You might also need to enable breakpoints anywhere in VS code 
user setting file.



Awesome! After finding the right combination of flags (-g and 
-m64 fed to dmd via dflags-dmd in my dub.json) this works quite 
nicely. Thanks a lot!

Is there anywhere I can contribute this as documentation?


I cannot debug my app with mago-mi. I click debug button, but 
nothing happen. I have installed cpptools, mago-mi, 
webfreak.debug, and I have tried vscode-dlang and code-d. My 
launch.json:


{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "mago-mi",
"request": "launch",
"target": "${workspaceRoot}/bin/exp.exe",
"cwd": "${workspaceRoot}",
"preLaunchTask": "build"
}
]
}

Re: Translating C macros to D

[Cym13 via Digitalmars-d]

On Monday, 10 July 2017 at 19:42:28 UTC, Jacob Carlborg wrote:
I'm trying to come up with a generic way to translate function 
like C macros to D to be used in DStep.


[...]


Is not getting rid of the macro an option? By that I mean 
translating the code inside the macro (which can admitedly be 
hard because it doesn't have to be semanticaly correct code due 
to concatenations but most macros aren't so evil) and add a pass 
of cpp to the build.


Of course nobody wants to use the C preprocessor on D code, but 
it would work and I'd prefer ugly code that works and can be 
refactored than no working translation at all personnaly.

stacktrace for InvalidMemoryOperationError

[crimaniak via Digitalmars-d-learn]

Hi!

I have vibe.d application and long-standing error in it.
For the current moment, I have logs for stdout, stderr, and 
additional log to write exceptions I catch. This error gives me 
only the short line in stderr log:


core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid 
memory operation


Also, I use registerMemoryErrorHandler(); (see 
http://vibed.org/docs#handling-segmentation-faults )


What else can I do to have the stack trace for this error?

I can't debug it because I don't have it on my developer's 
machine.

Re: dmd and Archlinux

[Marco Leise via Digitalmars-d]

Am Sun, 09 Jul 2017 18:35:09 +
schrieb Antonio Corbi :

> Hi!
> 
> Are there any news about the status of packaging dmd for 
> archlinux?
> 
> The last dmd compiler packaged is 2.074.0 and since the last 
> batch of updated packages in archlinux, dmd generated objects 
> fail to link with libphobos with erros like these:
> 
> /usr/bin/ld: /usr/lib/libphobos2.a(object_a_66e.o): relocation 
> R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile con -fPIC
> /usr/bin/ld: /usr/lib/libphobos2.a(object_b_58c.o): relocation 
> R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile con -fPIC
> /usr/bin/ld: /usr/lib/libphobos2.a(object_c_7f4.o): relocation 
> R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile con -fPIC
> /usr/bin/ld: /usr/lib/libphobos2.a(object_d_a07.o): relocation 
> R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile con ...
> 
> A. Corbi

The linker gold (since binutils 2.27) is problematic with DMD
and would emit such errors. (Is ld a symlink to ld.gold in
this case?) Also binutils 2.28 breaks how DMD's druntime
loads shared libraries. You have to either downgrade binutils
or use the hack of adding '-fPIC' when compiling executable
that link against shared libraries. binutils 2.26 should be
the most compatible version for the time being.

-- 
Marco

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Marco Leise via Digitalmars-d]

Am Sun, 9 Jul 2017 16:22:16 -0400
schrieb "Nick Sabalausky (Abscissa)"
:

> […] a sufficiently-smart compiler could conceivably even
> choose "runtime" vs "compile-time" (or even, "it varies")
> based on optimization priorities.

GCC already does this, i.e. find runtime arguments of constant
value and generate a second instance of the function with that
argument optimized out.

-- 
Marco

Re: .NET Library In D

[rjframe via Digitalmars-d]

On Mon, 10 Jul 2017 21:36:05 +, FoxyBrown wrote:

> The goal is that, one day, we can effectively replace the phobos with
> .NET semantics if we want. It, being a nicer library, and all the source
> code available through reflection, makes it a nice target.  While the
> source code cannot be distributed, the recompiler can. In C# maps to D
> farily well, it is not a difficult ask.

Mono is mostly MIT, so could be redistributed (they haven't developed the 
full framework, but the common stuff works).

https://github.com/mono/mono/tree/master/mcs/class

This would be very helpful for porting libraries from .NET; do you have a 
public repository?

Re: Call for arms: Arch Linux D package maintenance

[rjframe via Digitalmars-d-announce]

On Sun, 09 Jul 2017 21:33:15 +, bachmeier wrote:

> The answer (assuming things are still run the way they
> were back then) is that you're not able to do anything about it. You
> won't see anything done with the official package and you won't be able
> to put anything in AUR because there is an official package.

I couldn't find a documented deprecation process, but they do deprecate 
packages; perhaps if that could be pushed forward it would allow someone 
to maintain something in AUR.

Re: proposed @noreturn attribute

[Marco Leise via Digitalmars-d]

Am Sat, 8 Jul 2017 03:15:39 -0700
schrieb Walter Bright :

> […]
>
> Having an @noreturn attribute will take care of that:
> 
> @noreturn void ThisFunctionExits();
> 
> Yes, it's another builtin attribute and attributes are arguably a failure in 
> language design.

The 'none' return type sounds interesting, because a @noreturn
function is also a void function, it is practical to implement
this as a void sub-type or compiler recognized druntime
defined "type intrinsic". On the other hand, the attribute
solution has worked well for the existing compilers in practice
and such a rarely used tag doesn't add significantly to the
meticulous D programmers list: "pure @safe nothrow @nogc".

-- 
Marco

Re: Cannot dup an associative array but why?

[Jean-Louis Leroy via Digitalmars-d-learn]

On Monday, 10 July 2017 at 19:11:37 UTC, Ali Çehreli wrote:

On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote:
> Is there something special about ClassInfo that confuses?
Look at this
> example:
>
> struct Foo
> {
>
> }
>
> class Bar
> {
> }
>
> void main()
> {
>   Foo*[Bar] a;
>   auto aa = a.dup; // OK
>   Foo*[ClassInfo] b; // Error: static assert  "cannot call
> Foo*[TypeInfo_Class].dup because Foo* is not copyable"

I think you're hitting the same TypeInfo.init issue again. :/ 
This is the assert that fails inside object.dup:


static assert(is(typeof({ V v = aa[K.init]; })),
"cannot call " ~ T.stringof ~ ".dup because " ~ 
V.stringof ~ " is not copyable");


Jean-Louis, a little more patience please. :) Hopefully this 
will be resolved with 2.075, which you should be able to test 
yourself already. (?) 2.075 is in its fourth beta release.


Ali


Howdy Ali ;-)

Aaaah...those rough edges you were talking about at CppNow?

FYI, having a lot of fun. See 
https://github.com/jll63/meth.d/blob/experiments/source/meth/examples/adventure.d


At the time being, I'm hijacking ClassInfo.deallocator. I hope it 
will live through the next iteration of D.

[Issue 10233] [Tracker] Grammar issues

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10233
Issue 10233 depends on issue 953, which changed state.

Issue 953 Summary: Multiple C style declarations of same type cannot be in one 
statement
https://issues.dlang.org/show_bug.cgi?id=953

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--

[Issue 12196] Bad error message for multiple declarations

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |DUPLICATE

--- Comment #3 from Vladimir Panteleev  ---


*** This issue has been marked as a duplicate of issue 953 ***

--

[Issue 953] Multiple C style declarations of same type cannot be in one statement

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Vladimir Panteleev  ---
(In reply to Matti Niemenmaa from comment #0)
> int foo[2], bar[2];
> 
> The above fails with the error message "multiple declarations must have the
> same type, not int[2] and int[2]" which makes no sense. int[2] is the same
> type as int[2].

Fixed by https://github.com/dlang/dmd/pull/4021. Now it prints:

test.d(1): Deprecation: instead of C-style syntax, use D-style syntax 'int[2]
foo'
test.d(1): Deprecation: instead of C-style syntax, use D-style syntax 'int[2]
bar'

--

[Issue 953] Multiple C style declarations of same type cannot be in one statement

[via Digitalmars-d-bugs]

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

--- Comment #9 from Vladimir Panteleev  ---
*** Issue 12196 has been marked as a duplicate of this issue. ***

--

Re: version=D_16

[Luís Marques via Digitalmars-d]

On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] 
wrote:
The problem Walter pointed to is that due to integer promotion, 
arithmetic operands of types smaller than int are converted to 
int, hence even if you use bytes and shorts you would end up 
using ints, which are expensive on CPUs with no native 32-bit 
registers. In theory, you could write your code so that it's 
easy for the optimizer to prove that you're only using 8 or 16 
bits and variables would fit in single registers, so you would 
be able to get away without a performance penalty for using a 
language where ints are 32-bit.


Ah, that makes sense. Thanks for clarifying. For me it hasn't 
proved a problem, but I could see it being if you do a lot of 
arithmetic with 16-bit integers.

[Issue 4085] Steps toward a static foreach

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #13 from Vladimir Panteleev  ---
https://github.com/dlang/dmd/pull/6760

Closing in favor of DIP 1010:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md

--

[Issue 17628] formattedWrite is impure on double

[via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
> which I think may change FPU flags or something

A hack would to create a pureSnprintf which resets errno to the value before
its execution.

There are talks about doing this for free:

https://github.com/dlang/druntime/pull/1836

--

Re: version=D_16

[via Digitalmars-d]

On Monday, 10 July 2017 at 21:53:16 UTC, Luís Marques wrote:

On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote:
You can't use RTTI or Exceptions, for example. Those generate 
bloat even if they are not used - a compiler switch is typical 
to disable them. It's not true that C++ is "pay only for what 
you use".


If the C++ usage is "C with member functions", then yes, it'll 
work and be useful.


Sure, people don't use exceptions and RTTI and other expensive 
things on microcontrollers. But, as you say, they use it for 
less expensive or zero cost things like member functions, 
operator overloading, templates (not very common, but I've seen 
some interesting 0-cost wrappers that increased the safety of 
setting registers), etc. But I'm not here to advocate C++, I've 
only used it incidentally for microcontrollers (AVR, the 
Arduino libraries are C++, urg).


For example, ints in C are 16 bits. In D they are 32. This 
means that integer operations are expensive.


I don't understand this point of view. You are literally saying 
that writing "int x" is more expensive in D than in 16-bit C 
because they mean something different. Uhh, so just write 
"short x" in D? That's the equivalent code. Why would you write 
code that's character-by-character the same but means a 
different machine type?


If that's because short is more inconvenient in D than in C, I 
can understand that! But C also has a lot of annoying 
limitations, I feel that overall it's still a win.


If you give me more concrete examples I can try to address 
them. Just keep in mind that it's still fairly low level D 
code. I'm not throwing new Exceptions! But you can use modules, 
static ifs, templates... Modules alone sometimes feel like 
enough benefit...


The problem Walter pointed to is that due to integer promotion, 
arithmetic operands of types smaller than int are converted to 
int, hence even if you use bytes and shorts you would end up 
using ints, which are expensive on CPUs with no native 32-bit 
registers. In theory, you could write your code so that it's easy 
for the optimizer to prove that you're only using 8 or 16 bits 
and variables would fit in single registers, so you would be able 
to get away without a performance penalty for using a language 
where ints are 32-bit.

[Issue 15770] SocketSet.add OutOfMemoryError on Posix

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
I can't reproduce this:

/// test.d //
import std.socket;

void main()
{
auto ss = new SocketSet;
auto s = new TcpSocket;
ss.add(s);  // succeeds
ss.add(TcpSocket.init); // segmentation fault as expected
}
/

Please reopen if you can provide a reproducible test case.

--

[Issue 17633] Unary negation has the wrong type

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

  Component|dlang.org   |dmd
   Severity|enhancement |normal

--

[Issue 7063] No error or warning for conflicting D and C symbols

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to anonymous4 from comment #4)
> This can be reliably diagnosed only by the linker, since duplicate symbols
> can be buried in libraries or come from different object files.

The compiler probably shouldn't be passing garbage to the linker if it can help
it, though.

--

[Issue 17631] Can overload functions with simple enum argument, but not with complex enum argument

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Hardware|x86_64  |All
Summary|can overlaod functions with |Can overload functions with
   |simple enum argument, but   |simple enum argument, but
   |not with complex enum   |not with complex enum
   |argument|argument
 OS|Linux   |All

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

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

--- Comment #7 from Vladimir Panteleev  ---
(In reply to Cy Schubert from comment #5)
> What do you think if DMD D and LDC D provided a facility to test
> __FreeBSD_version or if not that the major.minor version number?

Cy, you mentioned that the patch came with careful backwards compatibility
provisions so as not to break older binaries. In my previous comment I asked
how that compatibility check works, and whether we can take advantage of it.
Have you looked into that at all yet?

--

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[Moritz Maxeiner via Digitalmars-d]

On Monday, 10 July 2017 at 20:10:58 UTC, 12345swordy wrote:

On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote:

On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:

On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:

I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy 
when it comes to manual memory management. The solutions 
that I find here involves very hackish solutions which is 
not idea for me.


Alex


No responses!?


See long standing `rt_finalize` issue [1], it's unfortunately 
a non-trivial problem.


[1] https://issues.dlang.org/show_bug.cgi?id=15246


What's the progress regarding fixing it?


AFAIK people disagreeing on how to proceed, because there's no 
one correct answer, it's a matter of policy.
And then there's the fact that hardly anyone uses @nogc 
currently, anyway, because this is not the only issue with it, 
see the (somewhat) controversial @nogc Exception PRs by Walter 
for one other problem [1][2] - idiomatic D code is essentially 
impossible atm with @nogc, unless you use hacks like preallocated 
exceptions. Another issue is how 
std.experimental.allocator.IAllocator and @nogc can fit together 
(because the interface can't be declared as attributed AFAIK).
I understand your frustration, but right now the best option imho 
(read as: least time expensive) remains not using @nogc (ouch, I 
know) and if you really fear hidden GC allocations, use the -vgc 
to have the compiler output all the placed where GC allocation 
may occur (grep through the result automatically, ensuring there 
are none reported); doesn't work for binary dependencies, 
unfortunately.


[1] https://github.com/dlang/druntime/pull/1804
[2] https://github.com/dlang/dmd/pull/6681

Re: Automatic invariant generation

[Jonathan M Davis via Digitalmars-d]

On Monday, July 10, 2017 11:26:43 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote:
> > For some assertions, having more than a file and line number is nice
> > (e.g. if you have messages for your pre-condition assertions, then you
> > can make it so that when it fails, the programmer doesn't even need to
> > look at the source code),
>
> He always needs to look at the source code. Asserts are for BUGS, and to
> fix bugs, you gotta look at the code. If asserts are being used as a
> substitute for input/environment errors, they're misused.
>
> In 40 years of asserts, I can't think of ever not visiting the file/line
> where it failed as the first thing I did to debug it.

Yes, assertions are used for catching bugs, but when they're used for DbC,
the bug is in the caller, and if it's clear from the message that the caller
violated a pre-condition as well as what that pre-condition was, then there
really is no need for the programmer to look at the source code of the
function being called. They just need to look at their code that's calling
it and figure out how they screwed up and passed a bad value. Essentially,
with pre-conditions, it's really the caller's code that's being tested, not
the code where the assertion itself is.

Assertions which test the code that they're actually in, on the other hand,
pretty much always require that you look at that code to figure out what's
going on.

- Jonathan M Davis

Re: version=D_16

[Luís Marques via Digitalmars-d]

On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote:
You can't use RTTI or Exceptions, for example. Those generate 
bloat even if they are not used - a compiler switch is typical 
to disable them. It's not true that C++ is "pay only for what 
you use".


If the C++ usage is "C with member functions", then yes, it'll 
work and be useful.


Sure, people don't use exceptions and RTTI and other expensive 
things on microcontrollers. But, as you say, they use it for less 
expensive or zero cost things like member functions, operator 
overloading, templates (not very common, but I've seen some 
interesting 0-cost wrappers that increased the safety of setting 
registers), etc. But I'm not here to advocate C++, I've only used 
it incidentally for microcontrollers (AVR, the Arduino libraries 
are C++, urg).


For example, ints in C are 16 bits. In D they are 32. This 
means that integer operations are expensive.


I don't understand this point of view. You are literally saying 
that writing "int x" is more expensive in D than in 16-bit C 
because they mean something different. Uhh, so just write "short 
x" in D? That's the equivalent code. Why would you write code 
that's character-by-character the same but means a different 
machine type?


If that's because short is more inconvenient in D than in C, I 
can understand that! But C also has a lot of annoying 
limitations, I feel that overall it's still a win.


If you give me more concrete examples I can try to address them. 
Just keep in mind that it's still fairly low level D code. I'm 
not throwing new Exceptions! But you can use modules, static ifs, 
templates... Modules alone sometimes feel like enough benefit...

Re: Why no offsetof for static struct?

[Ali Çehreli via Digitalmars-d-learn]

On 07/10/2017 02:14 PM, FoxyBrown wrote:
> On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote:
>> On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote:
>>> Cannot get the offset of static members of a struct
>>
>> That's because static members do not have an offset. They are not part
>> of the struct in memory, just in name.
>>
>>> We can clearly get a pointer to the static struct X
>>
>> There's barely any such thing as a static struct. That's just a struct
>> that stands without outside context which is almost all structs,
>> actually, so the term isn't special.
>>
>>> since  is effectively the address of X(regardless nomenclature
>>> and terminology issues in D trying to hide this).
>>
>> No, it isn't. Static members are stored in an entirely different place
>> than non-static members. They are really just global variables in
>> memory with their in-source name being nested somewhere else.
>
>
> This is not true, just because there isn't any official statement, or
> even if denied, does not make it true. I have proof:
>
> auto GetStaticAddress(T)()
> {
> mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
> return p;
> }
>
>
> Returns the address of a struct's static members.

Yes but that address is not offset from the beginning of any struct 
object. What would be its relationship to the following two objects?


import std.stdio;

auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

struct S {
static int s;
int m;
}

void main() {
writeln("S.s is at ", GetStaticAddress!S);
auto a = S();
auto b = S();
writeln("a   is at ", );
writeln("b   is at ", );
}

Prints

S.s is at 7F6D68484710
a   is at 7FFEADF41B68
b   is at 7FFEADF41B6C

So there is no offset of S.s to speak of (i.e. number of bytes from the 
beginning of) neither from a nor b.


> It's pretty obvious, the compiler seems to instantiate the static
> members simply as a sort of "singleton".

Makes sense.

> They are laid out with the same
> relative offsets as the struct(which is obvious, as that is the most
> natural way). That is all that is needed to treat the memory the static
> variables use as the struct in which they are part of. No need to make
> it any more complex than that.

S.s is sitting in memory all by itself without are relation to any other 
S members.


> Just because D obfuscates that static structs have addresses, doesn't
> mean they don't.

I assume you mean "static members". Then, yes, of course they have 
addresses. And you don't even need a function like GetStaticAddress():


writeln("S.s is at ", );

> No need to perpetuate a misnomer. Static structs and
> classes have addresses.

Again, I think you mean "static members of" or "instances of" structs 
and classes.


Ali

.NET Library In D

[FoxyBrown via Digitalmars-d]

I was able to get my C# to D convert to convert about 25% of the 
.net library v4.6


It converts the following libs:

// System.CodeDom
// System.CodeDom.Compiler
// System.Collections.Concurrent
// System.Collections.Generic
// System.Collections.ObjectModel
// System.Collections.Specialized
// System.ComponentModel
// System.ComponentModel.Design
// System.ComponentModel.Design.Serialization
// System.Configuration
// System.Configuration.Internal
// System.Diagnostics
// System.Diagnostics.CodeAnalysis
// System.IO
// System.IO.Compression
// System.IO.Ports
// System.Media
// System.Timers
// System.Text.RegularExpressions

Not all code works depending on the specific but 90%+ does.

The goal is that, one day, we can effectively replace the phobos 
with .NET semantics if we want. It, being a nicer library, and 
all the source code available through reflection, makes it a nice 
target.  While the source code cannot be distributed, the 
recompiler can. In C# maps to D farily well, it is not a 
difficult ask.

[Issue 17633] Unary negation has the wrong type

[via Digitalmars-d-bugs]

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

--- Comment #1 from Eyal  ---
If C's rules are not desirable here. That's fine.

assert_minus_1 should STILL not fail.

instead of -ubyte becoming int as in C, -ubyte can at least become byte.

--

Re: version=D_16

[Walter Bright via Digitalmars-d]

On 7/10/2017 1:52 PM, Luís Marques wrote:

On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote:

On 7/10/2017 12:46 PM, Luís Marques wrote:
I'm curious how that implementation addresses the issues I brought up:


I'm not really sure how to respond, you mostly just made statements about your 
worldview. For instance:


"C++ on a 64K machine is like using a tank to get to the grocery store". If you 
mean using all of C++ features, sure, that's inappropriate. If you mean that 
there are no C++ features that you could use in a microcontroller, there are 
non-trivial amounts of people the disagree with you.


You can't use RTTI or Exceptions, for example. Those generate bloat even if they 
are not used - a compiler switch is typical to disable them. It's not true that 
C++ is "pay only for what you use".


If the C++ usage is "C with member functions", then yes, it'll work and be 
useful.



"D for 16 bits wouldn't really be D, it would be a D variant with different
semantics and capabilities. (Like C++ for 16 bits.)" -> so far LDC with 
mtriple=msp430 has worked for me, for my needs. I don't really know what you 
mean by D for 16 bits...


For example, ints in C are 16 bits. In D they are 32. This means that integer 
operations are expensive.


But hey, if it works for your application, I can't argue with that!

[Issue 17628] formattedWrite is impure on double

[via Digitalmars-d-bugs]

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

--- Comment #1 from Vladimir Panteleev  ---
Missing:
import std.array : appender;

Seems to be impure because it calls snprintf (which I think may change FPU
flags or something).

--

.NET Library In D

[FoxyBrown via Digitalmars-d]

I was able to get my C# to D convert to convert about 25% of the 
.net library v4.6


It converts the following libs:

// System.CodeDom
// System.CodeDom.Compiler
// System.Collections.Concurrent
// System.Collections.Generic
// System.Collections.ObjectModel
// System.Collections.Specialized
// System.ComponentModel
// System.ComponentModel.Design
// System.ComponentModel.Design.Serialization
// System.Configuration
// System.Configuration.Internal
// System.Diagnostics
// System.Diagnostics.CodeAnalysis
// System.IO
// System.IO.Compression
// System.IO.Ports
// System.Media
// System.Timers
// System.Text.RegularExpressions

Not all code works depending on the specific but 90%+ does.

The goal is that, one day, we can effectively replace the phobos 
with .NET semantics if we want. It, being a nicer library, and 
all the source code available through reflection, makes it a nice 
target.  While the source code cannot be distributed, the 
recompiler can. In C# maps to D farily well, it is not a 
difficult ask.

[Issue 17627] DMD's toChars should not include the entire array of a slice result

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|assert output in ctfe is|DMD's toChars should not
   |irritating  |include the entire array of
   ||a slice result

--

[Issue 17633] New: Unary negation has the wrong type

[via Digitalmars-d-bugs]

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

  Issue ID: 17633
   Summary: Unary negation has the wrong type
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Unary negating a ubyte has type ubyte. This is a bug because it contradicts the
behavior of the same unary operator syntax in C:

enum ubyte x = 1;
void assert_minus_1(int y) { assert(y == -1); }
static assert(is(typeof(-x) == int), "Violating C's type rules");
unittest {
assert_minus_1(-x); // -x is 255, it's zero-extended instead of
sign-extended!
}

--

[Issue 17626] Same name variable assignment should raise a compile-time warning

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|dlang.org   |dmd

--

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

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

--- Comment #6 from Vladimir Panteleev  ---
(In reply to Jacob Carlborg from comment #5)
> I didn't really expect it to work. Perhaps a worthwhile feature?

Perhaps! Feel free to file an enhancement request.

--

[Issue 17625] Confusing error message for private functions in different modules

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Vladimir Panteleev  ---
I also get another line from the compiler, before the two shown:

zmain.d(3): Deprecation: zmain.boo is not visible from module zmain

This adds to the confusion because there is no "boo" in zmain (the compiler is
referring to the overload set created by the imports).

But it also points that it is related to 313/314, so when the deprecation
period of those expires, the error messages may change.

--

Re: LDC 1.3.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 9 July 2017 at 21:33:17 UTC, kinke wrote:

LDC 1.3.0, the LLVM-based D compiler, is available for download!
This release is based on the 2.073.2 frontend and standard 
library and supports LLVM 3.5-4.0.


Congratulations all! :-)

The ldc2 snap package has been updated to 1.3.0 as well.

Re: Why no offsetof for static struct?

[FoxyBrown via Digitalmars-d-learn]

On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote:

On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote:

Cannot get the offset of static members of a struct


That's because static members do not have an offset. They are 
not part of the struct in memory, just in name.



We can clearly get a pointer to the static struct X


There's barely any such thing as a static struct. That's just a 
struct that stands without outside context which is almost 
all structs, actually, so the term isn't special.


since  is effectively the address of X(regardless 
nomenclature and terminology issues in D trying to hide this).


No, it isn't. Static members are stored in an entirely 
different place than non-static members. They are really just 
global variables in memory with their in-source name being 
nested somewhere else.



This is not true, just because there isn't any official 
statement, or even if denied, does not make it true. I have proof:


auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}


Returns the address of a struct's static members.

It's pretty obvious, the compiler seems to instantiate the static 
members simply as a sort of "singleton". They are laid out with 
the same relative offsets as the struct(which is obvious, as that 
is the most natural way). That is all that is needed to treat the 
memory the static variables use as the struct in which they are 
part of. No need to make it any more complex than that.


Just because D obfuscates that static structs have addresses, 
doesn't mean they don't. No need to perpetuate a misnomer. Static 
structs and classes have addresses.


No, it might not be officially supported and the compiler may end 
up doing something funky, but it works, and works as it should, 
and should become part of D because it is useful:


auto GetOpts(T)(string[] args)
{   
import std.getopt, std.meta, std.traits;
auto t = GetStaticAddress!(T)();

string combine()
{
string s = "";
foreach(m; AliasSeq!(__traits(allMembers, T)))
{
mixin("enum a = __traits(getAttributes, T."~m~")[0];");
mixin("s ~= \"`"~a~"`, &"~T.stringof~"."~m~", \";");
}
return s;
}

enum s = combine();
mixin("return getopt(args, "~s~");");
}

struct X
{
align(1):
__gshared public static:
@("A") bool A;
@("B") string B;  
@("C") string[] C;
};


which allows us to do

GetOps!X(args)

vs

getop(args, "A", , "B", , "C", );


replaces the overly verbose getopt. Tell me that isn't useful and 
tell me that static structs don't have addresses!

[Issue 17614] [REG2.075.0-b2] __VERSION__ has the wrong value

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/5a92cda46371382ff03276970dd970d1a9718851
fix Issue 17614 - __VERSION__ has the wrong value

https://github.com/dlang/installer/commit/500302cdddb8c7b7ab656b565b7144ab7ac39dbf
Merge pull request #237 from MartinNowak/fix17614

--

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

[ketmar via Digitalmars-d-learn]

NoBigDeal256 wrote:

Do you happen 
to have a link to the bug report for this specific issue that I could 
look at? I looked at the known bugs list and couldn't find anything 
related to this.


nope. it is a kind of "known bug nobody bothered to report". ;-)

Re: version=D_16

[Luís Marques via Digitalmars-d]

On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote:

On 7/10/2017 12:46 PM, Luís Marques wrote:
I'm curious how that implementation addresses the issues I 
brought up:


I'm not really sure how to respond, you mostly just made 
statements about your worldview. For instance:


"C++ on a 64K machine is like using a tank to get to the grocery 
store". If you mean using all of C++ features, sure, that's 
inappropriate. If you mean that there are no C++ features that 
you could use in a microcontroller, there are non-trivial amounts 
of people the disagree with you.


"D for 16 bits wouldn't really be D, it would be a D variant with 
different
semantics and capabilities. (Like C++ for 16 bits.)" -> so far 
LDC with mtriple=msp430 has worked for me, for my needs. I don't 
really know what you mean by D for 16 bits...

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

[NoBigDeal256 via Digitalmars-d-learn]

On Monday, 10 July 2017 at 20:31:12 UTC, ketmar wrote:

NoBigDeal256 wrote:

I'm currently learning D and started working on one of my 
first projects which is an API wrapper. I'm currently having 
an issue with my program getting a InvalidMemoryOperationError 
upon exiting the process on Windows 7. On my Debian VM I get a 
segmentation fault.


known bug in curl finalization on program exit. should be fixed 
in the next release. for now you have to live with it, or build 
your own phobos.


Ah. It's interesting that it works perfectly fine when used 
directly in main, and only becomes an issue when it's a struct 
member. Do you happen to have a link to the bug report for this 
specific issue that I could look at? I looked at the known bugs 
list and couldn't find anything related to this.

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Walter Bright via Digitalmars-d]

On 7/10/2017 12:53 PM, Luís Marques wrote:

On Monday, 10 July 2017 at 19:41:48 UTC, Walter Bright wrote:

What is the goal/reason/rationale for making a 16 bit D target?


- I program for MSP430
- I'm tired of C's limitation
- LDC works with MSP430


Those are quite understandable goals. I'm curious how the issues I brought up 
are addressed, however.

Re: Slides share: DMesos - Not only a re-implementation of Mesos

[Andy Smith via Digitalmars-d]

On Monday, 10 July 2017 at 17:29:01 UTC, 鲜卑拓跋枫 wrote:

Dear all,
   I am a D-language amateur from China, and just want to share 
you with a slides from me that post on MesosCon Asia 
2017(Beijing):
   
https://mesosconasia2017.sched.com/event/AZc6/dmesos-not-only-a-re-implementation-of-mesos-ce-feng-li-emc#
   I do really wanna to implement the design or "dream" as 
described in this slides,

your help and suggestion are very welcome!
   Thanks！

BRs,
Koo


Wow - very cool stuff. Wish I could have heard the talk - was it 
recorded at all? D could really benefit from some sort of 
'project X' that will propel it to the next level. (Much like 
rails did for ruby, numpy/pandas did for python, akka/spark for 
scala). A D re-implementation of the mesos/akka/raft stack was 
one of the things that could be it.


Best of luck with the project. I'll be watching it with a lot of 
interest!


Cheers,

A.

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Brad Roberts via Digitalmars-d]

On 7/10/17 10:49 AM, Luís Marques via Digitalmars-d wrote:

On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote:
The official stance is that we don't.  There is just far too much 
baggage that gets piled in by default that makes it very hostile, 
however those of us who are capable of doing so won't try to stop you, 
and you have the likes of minilibd and other minimal D libraries as 
friendly replacement, perhaps you could even use them on top of musl. ;-)


By "we don't" it seems you are referring to supporting D + druntime + 
Phobos. But, to clarify, plain -betterC D seems to work well. One issue 
is that size_t currently has the wrong size, and changing it involves at 
least some druntime support (changing object.d, and changing all of the 
size_t line = __LINE__ fallout).


BTW, I wasn't sure how I should go about changing druntime and Phobos 
regarding the size_t line -> line_t line transition. I opted to change 
LDC's fork of druntime first, because it seemed to me like the 
contribution had a better chance of being accepted, and afterwards make 
a separate dlang/druntime pull request. But the more natural way would 
probably be to change the canonical druntime first and then merge the 
changes on the LDC side, no?


- Luís


I think this is a great example of a project where the best path is to 
fork the compiler, runtime, and phobos (if you intend to go that high up 
the stack) and just go do it.  Don't worry, for the short term, about 
any of the naming issues, mergability, etc.  Make it work, use it, learn 
what the big issues are, etc.  Then, cycle back and look at how to 
merge.  I suspect there's going to be a lot of issues and finding out 
what's important to disucss in what order is useful.  Getting bogged 
down early is going to be frustrating.

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

[ketmar via Digitalmars-d-learn]

NoBigDeal256 wrote:

I'm currently learning D and started working on one of my first projects 
which is an API wrapper. I'm currently having an issue with my program 
getting a InvalidMemoryOperationError upon exiting the process on Windows 
7. On my Debian VM I get a segmentation fault.


known bug in curl finalization on program exit. should be fixed in the next 
release. for now you have to live with it, or build your own phobos.

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

[NoBigDeal256 via Digitalmars-d-learn]

Still haven't figured out what's wrong. Any help would be 
appreciated.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 04:14 PM, Nick Sabalausky (Abscissa) wrote:


Oh, I didn't mean to imply that I wouldn't love to have it in D 
(assuming it was all well-fleshed out and didn't have big problems). I 
just wanted to be crystal clear that I'm merely discussing a langauge 
design idea here rather than coming in saying "Hey, you people should 
all like this idea and go implement it put it into D!!!" It's easy for 
things to get taken that way here, and can result in knee-jerk reactions 
and otherwise derailing of what's really only intended as a theoretical 
academic discussion. If something *were* to come of it, and it worked 
great, and everybody was happy, then fantastic. That's just not what I'm 
bringing it up for, that's all.


I especially wanted to avoid any the "How dare you even consider 
speaking of something without fully implementing it first!" that tends 
to be common here. (Speaking of, *that* sort of thing is far more 
unprofessional than the mere "bad words" some people are so terrified of).

Re: version=D_16

[Walter Bright via Digitalmars-d]

On 7/10/2017 12:46 PM, Luís Marques wrote:

since LDC essentially works for MSP430, even though it isn't officially 
supported.


I'm curious how that implementation addresses the issues I brought up:

http://www.digitalmars.com/d/archives/digitalmars/D/size_t.sizeof_2_LINE_.sizeof_4_304013.html#N304054

Curiously, there's the MSP430X with 20 bit registers!

https://en.wikipedia.org/wiki/TI_MSP430#MSP430X_20-bit_extension

Why no offsetof for static struct?

[FoxyBrown via Digitalmars-d-learn]

Cannot get the offset of static members of a struct

struct X
{
__gshared public:
int x;
}


X.x.offsetof < invalid.

We can clearly get a pointer to the static struct X since  is 
effectively the address of X(regardless nomenclature and 
terminology issues in D trying to hide this).


e.g.,

auto p = cast(X*)

will, for all practical purposes be a pointer to X.


auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

Of course, assuming that the first member is at the same location 
as the start of the struct and the elements are laid out in the 
same positions(not sure if this is guaranteed, but probably is).


Would be much nicer if we could just take the address of a static 
struct




This is pretty useful for simplification:

auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

auto GetOpts(T)(string[] args)
{   
import std.getopt, std.meta, std.traits;
auto t = GetStaticAddress!(T)();

string combine()
{
string s = "";
foreach(m; AliasSeq!(__traits(allMembers, T)))
{
mixin("enum a = __traits(getAttributes, T."~m~")[0];");
mixin("s ~= \"`"~a~"`, &"~T.stringof~"."~m~", \";");
}
return s;
}

enum s = combine();
mixin("return getopt(args, "~s~");");
}

struct X
{
align(1):
__gshared public static:
@("A") bool A;
@("B") string B;  
@("C") string[] C;
};


which allows us to do

GetOps!X(args)

vs

getop(args, "A", , "B", , "C", );


Could be improved to only deal with special argument attributes 
on X's fields and allow for non-static strucs(for the general 
case of mapping). Sort of a map between attribute space on a type 
and some function.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 02:55 PM, Jacob Carlborg wrote:

On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:

The other important thing I want to emplasize yet again (just in case,
because I know from experience in the past it's exactly this kind of
point that rarely gets noticed), I'm not proposing D do this. It'd be
far too big a change and it's far too incomplete to even think of trying
to push. (Even tiny straightforward improvements to D face dowwnright
epic levels of resistance any more.) So again, it's just some
brainstorming. Maybe D several decades from now, maybe some other
language inspired by D, maybe nothing ever, whatever.


Here I disagree. I think that D should have something like this.



Oh, I didn't mean to imply that I wouldn't love to have it in D 
(assuming it was all well-fleshed out and didn't have big problems). I 
just wanted to be crystal clear that I'm merely discussing a langauge 
design idea here rather than coming in saying "Hey, you people should 
all like this idea and go implement it put it into D!!!" It's easy for 
things to get taken that way here, and can result in knee-jerk reactions 
and otherwise derailing of what's really only intended as a theoretical 
academic discussion. If something *were* to come of it, and it worked 
great, and everybody was happy, then fantastic. That's just not what I'm 
bringing it up for, that's all.

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[12345swordy via Digitalmars-d]

On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote:

On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:

On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:

I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy 
when it comes to manual memory management. The solutions that 
I find here involves very hackish solutions which is not idea 
for me.


Alex


No responses!?


See long standing `rt_finalize` issue [1], it's unfortunately a 
non-trivial problem.


[1] https://issues.dlang.org/show_bug.cgi?id=15246


What's the progress regarding fixing it?

Re: Why no offsetof for static struct?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote:

Cannot get the offset of static members of a struct


That's because static members do not have an offset. They are not 
part of the struct in memory, just in name.



We can clearly get a pointer to the static struct X


There's barely any such thing as a static struct. That's just a 
struct that stands without outside context which is almost 
all structs, actually, so the term isn't special.


since  is effectively the address of X(regardless 
nomenclature and terminology issues in D trying to hide this).


No, it isn't. Static members are stored in an entirely different 
place than non-static members. They are really just global 
variables in memory with their in-source name being nested 
somewhere else.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/10/2017 12:02 PM, Jacob Carlborg wrote:

Are those few cases worth optimizing for?


Yes. Not having it makes enforce(), for example, generate poor code.

Re: proposed @noreturn attribute

[Steven Schveighoffer via Digitalmars-d]

On 7/10/17 3:05 PM, Meta wrote:

On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer wrote:

On 7/10/17 2:38 PM, Walter Bright wrote:

On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically determining 
that a function is noreturn?


It is useful anywhere dataflow analysis is useful.

FunctionThatDoesnotReturn();
a = b; // error: unreachable code


That doesn't require static introspection. The compiler can see that, 
the user doesn't have to worry about it.


Note, one thing that hasn't been mentioned is how we are now going to 
be able to make regular functions noreturn. This means templates that 
accept aliases will now have to deal with the possibility that those 
aliases are noreturn.


So if the compiler, for instance, marks the above as an error, what 
happens here?


foo(alias f)()
{
   f();
   auto a = b;
}

if f is a noreturn function, is this instantiation an error?


Currently not. This is either a bug or the compiler's flow analysis is 
not robust enough to detect this case.


I think the implication from Walter is that f would be treated just like 
a direct call to assert(0) (i.e. it doesn't return).


So where code like this produces an "unreachable statement" error:

void foo()
{
   assert(0);
   auto a = b;
}

with dmd -w, code like the above will potentially produce an unreachable 
code error if f is a noreturn (the compiler can now do dataflow analysis 
and determine it's unreachable).


This means that you get errors for some instantiations. Which ironically 
means you'd need to do something like this:


void foo(alias f)()
{
   f();
   static if(!isNoreturn!f)
   {
   auto a = 5;
   ...// etc.
   }
}

Today, it's not a big issue. We can't alias `assert` function directly, 
so it's obvious where it's an assert or not (because you have to spell 
it out!).


We have similar problems today with generic code causing unreachability 
errors. See for instance https://issues.dlang.org/show_bug.cgi?id=14835


-Steve

Foreign threads in D code.

[Igor Shirkalin via Digitalmars-d-learn]

Hello!

I have written some D code that I need to link to :C++ huge 
project. Let it be just one function that uses GC. The question 
is: if C++ code creates several threads and runs this :D function 
simultaneously, will GC work correctly?


p.s. Of course the druntime is initialized before it.

Igor Shirkalin

Why no offsetof for static struct?

[FoxyBrown via Digitalmars-d-learn]

Cannot get the offset of static members of a struct

struct X
{
__gshared public:
int x;
}


X.x.offsetof < invalid.

We can clearly get a pointer to the static struct X since  is 
effectively the address of X(regardless nomenclature and 
terminology issues in D trying to hide this).


e.g.,

auto p = cast(X*)

will, for all practical purposes be a pointer to X.


auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

Of course, assuming that the first member is at the same location 
as the start of the struct and the elements are laid out in the 
same positions(not sure if this is guaranteed, but probably is).


Would be much nicer if we could just take the address of a static 
struct

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/10/2017 12:05 PM, Meta wrote:
Currently not. This is either a bug or the compiler's flow analysis is not 
robust enough to detect this case.


Flow analysis relies on the function's signature, not its implementation, and 
currently the signature contains no information about noreturn.


Addressing this is the whole point of this thread.

Re: proposed @noreturn attribute

[ketmar via Digitalmars-d]

Jacob Carlborg wrote:

I'm going to ask the stupid question: I understand that this is for the 
compiler to generate better code. But, since the attribute (or whatever 
it is) indicates that a function won't return, it can only be used in 
very few cases. Are those few cases worth optimizing for?


the case that makes @noreturn worth having is even not optimizing, but 
don't adding visual noise at the call site.


case Smth: error("boo");
case Other: ...

oops. i know that `error()` will never return, but compiler doesn't, and 
insisting on adding `break;` there.


sure, i can either put break, or always put `assert(0);` after noreturn 
functions, but hey, aren't we invented computers exactly to lay off such 
borning things onto them!? ;-)

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Luís Marques via Digitalmars-d]

On Monday, 10 July 2017 at 19:41:48 UTC, Walter Bright wrote:

What is the goal/reason/rationale for making a 16 bit D target?


- I program for MSP430
- I'm tired of C's limitation
- LDC works with MSP430

Re: Translating C macros to D

[ketmar via Digitalmars-d]

Jacob Carlborg wrote:

Does anyone have any other ideas that would work for everything that can 
be passed to a C macro?


string mixin with concatenation. this is basically what C macro is anyway.

version=D_16

[Luís Marques via Digitalmars-d]

Hello,

Johan Engelen suggested I bring further attention to this issue 
here in the D forums.


We need a version identifier for 16-bit code (e.g. to 
conditionally define size_t correctly). This is not theoretical, 
it's an actual need, since LDC essentially works for MSP430, even 
though it isn't officially supported. I'm assuming that adding a 
predefined version identifier isn't problematic, so the only 
issue is how it should be named. Here's what I wrote on GitHub:


"I defined a version identifier for 16-bit code called D_P16, by 
analogy with D_LP64. Now, D_LP64 was an awful name because it 
means 64-bit in general and not C's LP64 in particular. I chose 
D_P16 to mean pointers are 16-bit, but now I'm thinking if we 
should just call it D_16. In theory we could have a Harvard 
architecture where the native integer size is different from the 
native pointer size. That's one argument in favor of D_P16. 
Another argument would be consistency with D_LP64." -> but maybe 
that's overcomplicating and D_16 suffices?


Bikeshed all the things! \o

- Luís

[Issue 17632] [REG 2.075-b1] opBinary and delegate code generation

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|2.075 beta regression:  |[REG 2.075-b1] opBinary and
   |opBinary and delegate code  |delegate code generation
   |generation  |

--- Comment #1 from Vladimir Panteleev  ---
Introduced by https://github.com/dlang/dmd/pull/6852

--

Translating C macros to D

[Jacob Carlborg via Digitalmars-d]

I'm trying to come up with a generic way to translate function like C 
macros to D to be used in DStep.


One problem with macros is that it's not possible, by just looking at 
the macro, to understand how it's used, what can be passed to it. For 
example, it's possible to pass values, variables and types to a C macro. 
But I cannot come up with a signature for a template or function in D 
that would work for all cases.


Currently DStep translates the macros to templated functions where each 
parameter has its own template type and are declared as "auto ref". Example:


#define _IOR(type,nr,size) 
_IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))


Is translated to:

extern (D) auto _IOR(T0, T1, T2)(auto ref T0 type, auto ref T1 nr, auto 
ref T2 size)

{
return _IOC(_IOC_READ, type, nr, (_IOC_TYPECHECK(size)));
}

Use as follows:

enum FE_READ_BER = _IOR('o', 70, uint);

The problem with this translation is that it's not possible to pass only 
a type to this function.


Second try: use alias parameters and only template parameters:

extern (D) auto _IOR(alias type, alias nr, alias size)();

Use as a template:

enum FE_READ_BER = _IOR!('o', 70, uint);

This won't compile either because it's not possible to pass a type to an 
alias parameter. This is probably a bug that should be fixed.


Third try:

Use the template variadic parameter trick:

extern (D) auto _IOR(Args... /* type, nr, size */)() if (Args.length == 3);

Now the above usage example actually works:

enum FE_READ_BER = _IOR!('o', 70, uint);

Unfortunately it's not possible to take the address of a variable and 
pass to template variadic parameter:


void foo(Args...)() {}

void main()
{
int b;
foo!(b); // passing the variable directly works fine
foo!(); // Error: variable b cannot be read at compile time
}

The strange thing is, if I add another function and pass to the variadic 
parameter it does work:


void foo(Args...)(Args args)
{
bar!(args);
}

void bar(Args...)() {}

void main()
{
int a;
foo();
}

Does anyone have any other ideas that would work for everything that can 
be passed to a C macro?


--
/Jacob Carlborg

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Walter Bright via Digitalmars-d]

On 7/10/2017 5:41 AM, Luís Marques wrote:

for 16 bit targets


Having developed C/C++ on 16 bit targets for a couple decades, I have some 
curmudgeonly perspective.


1. having __LINE__ as size_t is madness. If I was responsible for that, shame 
on me.

2. a 16 bit type for 16 bit targets is plenty good enough. Consider that 32 bits 
on 16 bit targets is code bloat EXPENSIVE, and code bloat is a huge problem on 
16 bit targets. You're just not going to have 64000 line files, because the 
generated code won't fit in 16 bits. Even if you constructed a case, having the 
counter wrap around is little more than a very minor aggravation.


3. C++ worked on 16 bit code before exceptions and RTTI. Exceptions and RTTI are 
completely unworkable on 64K machines, and even on 640K machines. The STL is 
completely unworkable on 640K machines, because it is just too big.


4. 640K programming in C++ is not practical without near/far support. D has no 
such support, and neither does Standard C++.


5. C++ on a 64K machine is like using a tank to get to the grocery store.

6. __LINE__ is typed `unsigned` everywhere I've seen, including with 16 bit 
compilers.


== Some Conclusions ==

1. __LINE__ should be `uint`. Negative lines make no sense.

2. Exceptions are useless on 16 bits, so class Exception has no purpose.

3. D doesn't have near/far and won't be suitable for 640K programming.

4. D for 64K programming is possible in 'betterC' mode.

5. D's 32 bit int sizes are not very workable for 16 bit code. shorts will be 
promoted to 32 bits. Trying to change this in the compiler logic for 16 bit 
targets is an unknown amount of work.


6. D for 16 bits wouldn't really be D, it would be a D variant with different 
semantics and capabilities. (Like C++ for 16 bits.)


== Bottom Line ==

Trying to make D into a useful compiler for 16 bit programming is a bit of a 
quixotic quest. But it probably could be bludgeoned into doing something 
credible with it if needed to satisfy a bullet point requirement. __LINE__'s 
type is hardly the only problem.


What is the goal/reason/rationale for making a 16 bit D target?

Re: Slides share: DMesos - Not only a re-implementation of Mesos

[Joakim via Digitalmars-d]

On Monday, 10 July 2017 at 18:45:34 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 07/10/2017 02:16 PM, Joakim wrote:
I'm actually skeptical of cloud- I think mobile p2p will eat 
most of the cloud-


I've been REALLY hoping p2p will 
eat...cloud^H^H^H^H^Hcentralized internet services[1], but if I 
were a betting man I'd bet heavily against it. For one thing, 
for p2p to kill "cloud" we'd realistically need IPv6 to become 
much more ubiquitous, and that just isn't happening.


I don't think it's necessary, but it would be nice to have.

And I think the #2 reason IPv6 isn't happening (behind plain 
old inertia) is that it would *allow* p2p to overtake cloud.


I think you underestimate how well ipv6 has already done on 
mobile:


https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html

That post is now more than a year old, extrapolate accordingly.

Which brings me to the next reason I don't think p2p will kill 
"cloud": All the big players with all the money and the power 
all LOVE "cloud" because it allows them to hoard more power, 
control and money, whereas p2p would completely destroy that 
frontier for them.


Sure, many of the big tech players have built or are building 
giant cloud businesses, so they're not going to be interested in 
p2p, especially since there's no proven p2p business model.  Look 
at how BitTorrent Inc. floundered for more than a decade, before 
finally sinking recently.


This just means someone new will have to come in and knock the 
big boys off, maybe you. ;)


Also, replacing "cloud" with p2p would mean more reliance on 
user's devices actually having decent storage and upload 
bandwidth, but non-power-users (ie the vast majority of people, 
if you don't live in hipster valley) are ambivalent towards 
that, and it would raise the price of their devices, AND they 
don't want to deal with running low on storage, or backing 
things up, so they love "cloud" too.


A midrange smartphone or tablet these days comes with 2-3 GBs of 
RAM, 32-64 GBs of flash storage, an ARM chip about as powerful as 
a desktop chip from 3-5 years ago, and a 4G LTE chip that 
provides dozens of Mbits/s both ways.  Please tell me what 
they're missing, you can buy all that for $200-300.


Both the engineer and the humanitarian in me both REALLY want 
to see p2p eat "cloud", but I just don't see it realistically 
happening.


All you have to think about is whether the hardware is capable 
enough: we both know that it is.  Then, the software will flow 
downhill to where it can be executed most cheaply and reliably, 
_once_ there's a p2p business model.  It may take time for the 
dumb engineers to figure this out, but someone finally will, and 
when he strikes gold, the p2p gold rush will follow.


[1] The word "clould" bugs me to no end. It's the tech sector's 
equivalent to "smurf" - stupid word is used to mean *anything* 
internet-releated, even "internet" itself.


Heh, I was surprised recently to hear someone actually use the 
term as a real "cloud," ie they were referring to both mobile 
devices and servers in the data server, a true distributed cloud. 
 But yeah, most of the time it's just a new buzzword for ye olde 
client-server computing.

Re: proposed @noreturn attribute

[Patrick Schluter via Digitalmars-d]

On Monday, 10 July 2017 at 18:09:54 UTC, H. S. Teoh wrote:
On Sun, Jul 09, 2017 at 02:49:35PM -0400, Nick Sabalausky 
(Abscissa) via Digitalmars-d wrote:

On 07/09/2017 06:51 AM, Daniel N wrote:
> On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
> > On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright 
> > wrote:
> > 
> > > Has anyone a better idea?
> > 
> > What about
> > 
> > scope(exit) assert(0);
> > 
> > ?
> 
> void func()

> out { assert(0); }
> body
> {
> }

Too indirect and verbose. An attribute or special "return 
type" would just cut straight to the case.


If DIP 1009 is accepted, this would not be verbose at all:

void func()
out(false) // it even tells you it won't return
{
...
}

Plus, this has the advantage that you can specify a valid 
return type for when you need to override a base class method, 
e.g.:


class JitCompiler {
Code compile(string code);
}
class InvalidCompiler : JitCompiler {
override Code compile(string code) out(false) {...}
}

A Bottom type that implicitly converts to anything would also 
fit the bill, granted, but does require changing the language.


The main thing I have against adding a Bottom type is that it 
adds yet another built-in type to the language, which means (1) 
a combinatorial explosion of existing language constructs 
combined with the new type, with currently-unknown consequences 
(and possibly corner cases we haven't thought of that will come 
back to bite us), (2) yet another special type newcomers have 
to learn with special semantics (I can already anticipate 
complaints to D.learn about what's the difference between null 
and bottom); (3) having to implement lots of compiler changes 
to handle how this new type interacts with operators and other 
types in all possible cases; (4) all of this just for something 
that (a) is only rarely used, and (b) could have been easily 
implemented by adding @noreturn or using existing contract 
syntax without adding a whole new basic type to the language.


Honestly, I'd vote for @noreturn as the simplest, most 
straightforward solution, and the only reason I'm arguing for 
out{assert(0);} (or out(false) if DIP 1009 is accepted) is 
because people are all up in arms about adding Gosh Yet Another 
Special UDA In Addition To The Numerous Special UDAs We Already 
Have Like @safe and @nogc.



+1

Re: Cannot dup an associative array but why?

[Ali Çehreli via Digitalmars-d-learn]

On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote:
> Is there something special about ClassInfo that confuses? Look at this
> example:
>
> struct Foo
> {
>
> }
>
> class Bar
> {
> }
>
> void main()
> {
>   Foo*[Bar] a;
>   auto aa = a.dup; // OK
>   Foo*[ClassInfo] b; // Error: static assert  "cannot call
> Foo*[TypeInfo_Class].dup because Foo* is not copyable"

I think you're hitting the same TypeInfo.init issue again. :/ This is 
the assert that fails inside object.dup:


static assert(is(typeof({ V v = aa[K.init]; })),
"cannot call " ~ T.stringof ~ ".dup because " ~ V.stringof ~ " 
is not copyable");


Jean-Louis, a little more patience please. :) Hopefully this will be 
resolved with 2.075, which you should be able to test yourself already. 
(?) 2.075 is in its fourth beta release.


Ali

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer 
wrote:

On 7/10/17 2:38 PM, Walter Bright wrote:

On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically 
determining that a function is noreturn?


It is useful anywhere dataflow analysis is useful.

FunctionThatDoesnotReturn();
a = b; // error: unreachable code


That doesn't require static introspection. The compiler can see 
that, the user doesn't have to worry about it.


Note, one thing that hasn't been mentioned is how we are now 
going to be able to make regular functions noreturn. This means 
templates that accept aliases will now have to deal with the 
possibility that those aliases are noreturn.


So if the compiler, for instance, marks the above as an error, 
what happens here?


foo(alias f)()
{
   f();
   auto a = b;
}

if f is a noreturn function, is this instantiation an error?


Currently not. This is either a bug or the compiler's flow 
analysis is not robust enough to detect this case.


int b;

auto foo(alias f)()
{
f();
auto a = b; //no unreachable code error
}

void main()
{
foo!(() => assert(0))();
}

Re: proposed @noreturn attribute

[Jacob Carlborg via Digitalmars-d]

On 2017-07-08 12:15, Walter Bright wrote:

C compilers (and by extension C++ compilers) usually have an extension
which allows a function to be marked as one that never returns. The
point of this is it enables improved data flow analysis and better code
being generated.

Noreturn functions crop up in things like assert's and enforce's. DMD
internally hardcodes a few functions it knows about that are noreturn,
and the DMD optimizer and codegen take advantage of it.

But when people write their own assert's and enforce's, this falls
apart. While the programs will still work, they won't be as efficient as
they could be.


I'm going to ask the stupid question: I understand that this is for the 
compiler to generate better code. But, since the attribute (or whatever 
it is) indicates that a function won't return, it can only be used in 
very few cases. Are those few cases worth optimizing for?


--
/Jacob Carlborg

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Jacob Carlborg via Digitalmars-d]

On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:


Well, the nice thing about this approach (basing a concept-ish system
*on top* of existing D-style design-by-introspection, as opposed to a
C++-like concepts with no D-like features to complement it), is that it
*doesn't* require every little variation to be named.

For example, in the same psuedo-code I posted, there's a function (the
last join() overload) that takes an input range, but requires the input
range to support hasLength. But notice that there is NO symbol created
or used anywhere for InputRangeWithLength. IIUC, it sounds like C++
concepts would require such a symbol to be created. But with this, that
would not be needed.

One thing to keep in mind is that we're ALREADY creating names for many
(not all, but definitely some) of these things. In effect, *every* time
we have an 'isX' function (isSomeString, isForwardRange, etc), we're
already creating a name for it. We already implicitly understand that
just because it's unrealisting to name *everything* (which,
indicentally, reminds me of old Java class hierarchies), doesn't mean we
can't or shouldn't name some things.


I agree, it's not me that need convincing :)


The other important thing I want to emplasize yet again (just in case,
because I know from experience in the past it's exactly this kind of
point that rarely gets noticed), I'm not proposing D do this. It'd be
far too big a change and it's far too incomplete to even think of trying
to push. (Even tiny straightforward improvements to D face dowwnright
epic levels of resistance any more.) So again, it's just some
brainstorming. Maybe D several decades from now, maybe some other
language inspired by D, maybe nothing ever, whatever.


Here I disagree. I think that D should have something like this.

--
/Jacob Carlborg

Re: proposed @noreturn attribute

[Steven Schveighoffer via Digitalmars-d]

On 7/10/17 2:38 PM, Walter Bright wrote:

On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically determining that 
a function is noreturn?


It is useful anywhere dataflow analysis is useful.

FunctionThatDoesnotReturn();
a = b; // error: unreachable code


That doesn't require static introspection. The compiler can see that, 
the user doesn't have to worry about it.


Note, one thing that hasn't been mentioned is how we are now going to be 
able to make regular functions noreturn. This means templates that 
accept aliases will now have to deal with the possibility that those 
aliases are noreturn.


So if the compiler, for instance, marks the above as an error, what 
happens here?


foo(alias f)()
{
   f();
   auto a = b;
}

if f is a noreturn function, is this instantiation an error? That's 
going to get messy. It's not a problem today, because you can't alias 
`assert`, and the compiler doesn't care about other functions that don't 
return (even if they are completely available).


I learned the hard way with inout not to proactively make obvious errors 
errors. For instance, you can't return inout if you don't have any inout 
parameters. It makes complete logical sense when you think about it, 
just use const. This leads to the (inout int = 0) crap we see everywhere 
in phobos.


-Steve

Re: Slides share: DMesos - Not only a re-implementation of Mesos

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 02:16 PM, Joakim wrote:
I'm actually skeptical of cloud- I think mobile p2p will eat most 
of the cloud-


I've been REALLY hoping p2p will eat...cloud^H^H^H^H^Hcentralized 
internet services[1], but if I were a betting man I'd bet heavily 
against it. For one thing, for p2p to kill "cloud" we'd realistically 
need IPv6 to become much more ubiquitous, and that just isn't happening.


And I think the #2 reason IPv6 isn't happening (behind plain old 
inertia) is that it would *allow* p2p to overtake cloud. Which brings me 
to the next reason I don't think p2p will kill "cloud": All the big 
players with all the money and the power all LOVE "cloud" because it 
allows them to hoard more power, control and money, whereas p2p would 
completely destroy that frontier for them.


Also, replacing "cloud" with p2p would mean more reliance on user's 
devices actually having decent storage and upload bandwidth, but 
non-power-users (ie the vast majority of people, if you don't live in 
hipster valley) are ambivalent towards that, and it would raise the 
price of their devices, AND they don't want to deal with running low on 
storage, or backing things up, so they love "cloud" too.


Both the engineer and the humanitarian in me both REALLY want to see p2p 
eat "cloud", but I just don't see it realistically happening.


[1] The word "clould" bugs me to no end. It's the tech sector's 
equivalent to "smurf" - stupid word is used to mean *anything* 
internet-releated, even "internet" itself.

Cannot dup an associative array but why?

[Jean-Louis Leroy via Digitalmars-d-learn]

Is there something special about ClassInfo that confuses? Look at 
this example:


struct Foo
{

}

class Bar
{
}

void main()
{
  Foo*[Bar] a;
  auto aa = a.dup; // OK
  Foo*[ClassInfo] b; // Error: static assert  "cannot call 
Foo*[TypeInfo_Class].dup because Foo* is not copyable"
  auto bb = b.dup; // instantiated from here: 
dup!(Foo*[TypeInfo_Class], TypeInfo_Class, Foo*)}

}

'Foo*' is not copyable? Except that it is if the key is something 
else than ClassInfo? ClassInfo and Bar are both reference types 
though...

Re: iterate over variadic

[ag0aep6g via Digitalmars-d-learn]

On 07/10/2017 08:31 PM, H. S. Teoh via Digitalmars-d-learn wrote:

if (i % 2) {
// even


odd


... // do something with arg
} else {
// odd


even


... // do something with arg
}

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically determining that a function 
is noreturn?


It is useful anywhere dataflow analysis is useful.

   FunctionThatDoesnotReturn();
   a = b; // error: unreachable code

[Issue 17632] New: 2.075 beta regression: opBinary and delegate code generation

[via Digitalmars-d-bugs]

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

  Issue ID: 17632
   Summary: 2.075 beta regression: opBinary and delegate code
generation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: briancsch...@gmail.com

The following code executes successfully with 2.074.1 but segmentation faults
with 2.075.0-b4:



import std.stdio;

struct Test
{
void delegate() testBody;
Exception unexpected;

void opBinary(string op)(void delegate() fun)
{
testBody = fun;

// Call it
try
testBody();
catch (Exception ex)
unexpected = ex;
}
}

struct URL
{
string fragment;

}

struct JsonCube
{
URL dataURL;
}

struct JsonCubeDef
{
JsonCube _def;
this(string)
{
}
}

immutable TEST_JSON = `{}`;

void main()
{
auto def = cast(immutable) JsonCubeDef(TEST_JSON);

Test() in
{ writeln(def); };
}

--

Re: Automatic invariant generation

[Walter Bright via Digitalmars-d]

On 7/9/2017 4:37 AM, Steven Schveighoffer wrote:

On 7/9/17 7:00 AM, Walter Bright wrote:

On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:


Yet, here is an example of where we have effectively added a null pointer 
exception. > At the very least, this should be eliminated on Linux

and just use the signal handling null pointer error mechanism!


You're a few years late, as pretty much nobody agreed with me that the 
operating system handling of it was plenty.


I think you misunderstand, we have etc.linux.memoryerror that can actually throw 
an error on a null pointer using the signal handler.


Windows creates a exception, too, on null seg faults.


I have a suggestion: eliminate this feature, and add a -npe switch to the 
compiler that errors on any null pointer usage. Asserts will be sprinkled in 
everywhere, but may be useful to someone debugging a nasty null pointer segfault 
somewhere.


It's just redundant to add these.

Re: Automatic invariant generation

[Walter Bright via Digitalmars-d]

On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote:

For some assertions, having more than a file and line number is nice (e.g.
if you have messages for your pre-condition assertions, then you can make it
so that when it fails, the programmer doesn't even need to look at the
source code),


He always needs to look at the source code. Asserts are for BUGS, and to fix 
bugs, you gotta look at the code. If asserts are being used as a substitute for 
input/environment errors, they're misused.


In 40 years of asserts, I can't think of ever not visiting the file/line where 
it failed as the first thing I did to debug it.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 09:16 AM, Martin Nowak wrote:

On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky (Abscissa) wrote:

SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}


Looks like concepts.

We've settled on leveraging the already useful template constraints (at 
best in CNF [¹]) for better error messages. It's on the Agenda for later 
this year [²].


[¹]: https://github.com/dlang/phobos/pull/5461
[²]: https://wiki.dlang.org/Vision/2017H2_draft



Sounds nice.

But I'm getting the distinct impression people are missing that I never 
actually proposed that D itself should do this. It's just academic 
brainstorming.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 11:58 AM, bpr wrote:


You've seen this, right?

https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

A small step in one such direction, influenced by C++ concepts. That 
proto-DIP also raises a question I always had about why D doesn't allow 
chained template instantiation, but that's another DIP for another time.




Yea, I've seen that. It'd be a nice improvent for D and I'm definitely 
in favor of it.


It doesn't especially excite me though just because it's a small 
incremental change and creates further syntactical differences between 
handling runtime-oriented symbols and compile-time-oriented symbols. Ie, 
I'd prefer "InputRange r" over "T r if InputRange" because it's vastly 
simpler and more consistent with non-templated variable declarations. 
But in a practical sense, that's be a much more major and difficult to 
retrofit that onto D, so the DIP sounds like an appropriate (if 
unexciting) direction for D to take.


But what I find much more interesting than that DIP (again, from a 
purely academic standpoint) is taking all of these abilities and finding 
a way simplify them, while retaining all of their power, and create more 
overall consistency[1]. (That was *exactly* one of my big original draws 
to D in the first place - it took C++, then cleaned it all up and 
enhanced it. I have interest in brainstorming the same for D. I think 
there's been enough practical experience using D at this point for more 
streamlined designs to now be possible.)


[1] Heck, on the consistency front, it even bugs the hell out of me when 
people do "foo()" to call/define a function, but then deliberately stick 
with "if ()"-style instead for keywords. Both are "identifier followed 
by parens", but whether or not a space is added between is *different* 
depending on whether the identifier is a symbol or a keyword. 
Unnecessary inconsistency. Maybe it's all the puzzle games I've played 
over my lifetime, but...want...to...simplify... ;)

Re: Slides share: DMesos - Not only a re-implementation of Mesos

[Joakim via Digitalmars-d]

On Monday, 10 July 2017 at 17:29:01 UTC, 鲜卑拓跋枫 wrote:

Dear all,
   I am a D-language amateur from China, and just want to share 
you with a slides from me that post on MesosCon Asia 
2017(Beijing):
   
https://mesosconasia2017.sched.com/event/AZc6/dmesos-not-only-a-re-implementation-of-mesos-ce-feng-li-emc#
   I do really wanna to implement the design or "dream" as 
described in this slides,

your help and suggestion are very welcome!
   Thanks！


Wow, you've done your research!  Lot of good D stuff in those 
slides, nice to see the ldc team's work on ARM and GPUs has been 
noticed (glad to see a mention of my Android builds too).


I had never heard of Mesos until now, shows how I don't track 
cloud at all.  I'm actually skeptical of cloud- I think mobile 
p2p will eat most of the cloud- but a lot of these distributed D 
cloud libraries you want can be repurposed for mobile too.

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Sun, Jul 09, 2017 at 02:49:35PM -0400, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 07/09/2017 06:51 AM, Daniel N wrote:
> > On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
> > > On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
> > > 
> > > > Has anyone a better idea?
> > > 
> > > What about
> > > 
> > > scope(exit) assert(0);
> > > 
> > > ?
> > 
> > void func()
> > out { assert(0); }
> > body
> > {
> > }
> 
> Too indirect and verbose. An attribute or special "return type" would
> just cut straight to the case.

If DIP 1009 is accepted, this would not be verbose at all:

void func()
out(false) // it even tells you it won't return
{
...
}

Plus, this has the advantage that you can specify a valid return type
for when you need to override a base class method, e.g.:

class JitCompiler {
Code compile(string code);
}
class InvalidCompiler : JitCompiler {
override Code compile(string code) out(false) {...}
}

A Bottom type that implicitly converts to anything would also fit the
bill, granted, but does require changing the language.

The main thing I have against adding a Bottom type is that it adds yet
another built-in type to the language, which means (1) a combinatorial
explosion of existing language constructs combined with the new type,
with currently-unknown consequences (and possibly corner cases we
haven't thought of that will come back to bite us), (2) yet another
special type newcomers have to learn with special semantics (I can
already anticipate complaints to D.learn about what's the difference
between null and bottom); (3) having to implement lots of compiler
changes to handle how this new type interacts with operators and other
types in all possible cases; (4) all of this just for something that (a)
is only rarely used, and (b) could have been easily implemented by
adding @noreturn or using existing contract syntax without adding a
whole new basic type to the language.

Honestly, I'd vote for @noreturn as the simplest, most straightforward
solution, and the only reason I'm arguing for out{assert(0);} (or
out(false) if DIP 1009 is accepted) is because people are all up in arms
about adding Gosh Yet Another Special UDA In Addition To The Numerous
Special UDAs We Already Have Like @safe and @nogc.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it 
often, use it unsparingly, to subdue your listeners into submission!

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Luís Marques via Digitalmars-d]

On Monday, 10 July 2017 at 18:03:27 UTC, Steven Schveighoffer 
wrote:
I think it's reasonable to instrument druntime/phobos with 
line_t, and then libraries may or may not work with 16-bit (I 
wouldn't be surprised if most don't), but at least they will 
likely work for files less than 65k lines (quite a few) :)


Right, since for 32- and 64-bit code line_t is an alias for 
size_t, nothing breaks.


I will review and approve such a request if you make it. You'd 
likely need buy-in from Andrei.


That's nice. So maybe I should submit for the canonical druntime 
first and ask for a merge on the LDC side?


BTW, if you want to help bikeshed the name for the 16-bit version 
identifier name, there's still time... 



D_P16? D_16? Something else?

Re: DIP 1010--Static foreach--Formal Review

[jmh530 via Digitalmars-d]

On Monday, 10 July 2017 at 08:53:42 UTC, Mike Parker wrote:
As promised, since there has been zero feedback on DIP 1010, 
"Static foreach", in either the Draft or Preliminary review 
rounds, I'm going to skip the normal two-week feedback cycle on 
the Formal review. If there are no major criticisms or 
objections raised in this thread, then sometime on Thursday of 
this week I'll send Walter & Andrei an email kicking off the 
decision process.


So, if you have any thoughts on the DIP, now is the time to 
express them.


Thanks!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md


I have two somewhat related questions.

In the "Generating fields" section, does it have to be a static 
struct? I see another example with an abstract class with a 
static for each, but I don't see simpler struct/class examples.


I ask this because it seems like static foreach can be used to 
provide the same functionality as inout, e.g.


class Foo
{
static foreach(T; AliasSeq!(int,const(int),immutable(int)))
{
void bar(T t)
{
}
}
}

Re: Is runtime info in shared memory?

[Ali Çehreli via Digitalmars-d-learn]

On 07/09/2017 02:38 AM, Jean-Louis Leroy wrote:

When I look at ldc2's object.d I have the impression it's thread local.
I may be wrong though, just beginning to learn about 'shared'.


Unless it's marked as shared or __gshared it's thread-local by default.

Ali

[Issue 17159] Behavior of unions at compile time is not documented

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/e6085cb8faa58a8dcf243aacd3bc93f3ac89d8b2
Fix Issue 17159 - Behavior of unions at compile time is not documented

https://github.com/dlang/dlang.org/commit/eefbd0fd9aedce5c063e135a295e84f183d0e62a
Merge pull request #1702 from wilzbach/fix-17159

Fix Issue 17159 - Behavior of unions at compile time is not documented
merged-on-behalf-of: Vladimir Panteleev 

--

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Steven Schveighoffer via Digitalmars-d]

On 7/10/17 1:49 PM, Luís Marques wrote:

On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote:
The official stance is that we don't.  There is just far too much 
baggage that gets piled in by default that makes it very hostile, 
however those of us who are capable of doing so won't try to stop you, 
and you have the likes of minilibd and other minimal D libraries as 
friendly replacement, perhaps you could even use them on top of musl. ;-)


By "we don't" it seems you are referring to supporting D + druntime + 
Phobos. But, to clarify, plain -betterC D seems to work well. One issue 
is that size_t currently has the wrong size, and changing it involves at 
least some druntime support (changing object.d, and changing all of the 
size_t line = __LINE__ fallout).


I think it's reasonable to instrument druntime/phobos with line_t, and 
then libraries may or may not work with 16-bit (I wouldn't be surprised 
if most don't), but at least they will likely work for files less than 
65k lines (quite a few) :)


e.g. this should work fine if super takes a line_t:

class MyException : Exception
{
  this(string msg, size_t line = __LINE__, string file = __FILE__)
  {
super(msg, line, file);
  }
}

I will review and approve such a request if you make it. You'd likely 
need buy-in from Andrei.


-Steve

Re: Get a string of a function name from a function pointer?

[Ali Çehreli via Digitalmars-d-learn]

On 07/10/2017 05:26 AM, SauceKode wrote:
> I need to pass a group of (C) function pointers to another language from
> D... is there a way to derrive a name from a function pointer? Or do I
> have to manually list out the names?

libunwind should be able to provide that functionality. Otherwise, no, 
the function pointer itself does not contain any additional information.


Ali

Re: problem overloading functions with complex enum type

[Ali Çehreli via Digitalmars-d-learn]

On 07/08/2017 08:23 AM, Eric wrote:

> enum AS : string[2] { a = ["1","2"], b = ["3","4"] };
> enum BS : string[2] { a = ["5","6"], b = ["7","8"] };
>

> void funcs(AS a) { writeln("AS"); }
> void funcs(BS b) { writeln("BS"); }

> funcs(AS.a); // compiler error: matches both funcs(AS) and funcs(BS)

This looks like a bug to me.

Ali

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Mon, Jul 10, 2017 at 03:47:35PM +0200, Jacob Carlborg via Digitalmars-d 
wrote:
> On 2017-07-09 23:14, H. S. Teoh via Digitalmars-d wrote:
> 
> > I like out{ assert(0); } for pretty much the same reasons as Steven
> > lists. The biggest pro is that **the language already supports it*.
> > Contract syntax already is meant to signal intent, and assert(0)
> > signals "never gets here". You can't find a better solution than
> > this.
> 
> I highly doubt that the compiler does not need to be changed at all to
> get the wanted behavior.

I did not say the compiler does not need to be changed. I said the
*language* does not need to be changed.


> It that case it's just as easy to add a compiler recognized UDA. It
> doesn't add any more baggage than "out{ assert(0); }".
> 
> With that said, I don't care that much at all and I'm questioning how
> useful this feature is to have at all.
[...]

As is usual around here, things of marginal consequence receive the most
attention and energy spent in debating every last nitpick. Sigh.


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/10/2017 07:32 AM, Jacob Carlborg wrote:


Something like this has been proposed several times before, but Andrei 
doesn't seem to like it. He think it's a failure that all the conditions 
need to have a name, or something like that. I prefer your approach.




Well, the nice thing about this approach (basing a concept-ish system 
*on top* of existing D-style design-by-introspection, as opposed to a 
C++-like concepts with no D-like features to complement it), is that it 
*doesn't* require every little variation to be named.


For example, in the same psuedo-code I posted, there's a function (the 
last join() overload) that takes an input range, but requires the input 
range to support hasLength. But notice that there is NO symbol created 
or used anywhere for InputRangeWithLength. IIUC, it sounds like C++ 
concepts would require such a symbol to be created. But with this, that 
would not be needed.


One thing to keep in mind is that we're ALREADY creating names for many 
(not all, but definitely some) of these things. In effect, *every* time 
we have an 'isX' function (isSomeString, isForwardRange, etc), we're 
already creating a name for it. We already implicitly understand that 
just because it's unrealisting to name *everything* (which, 
indicentally, reminds me of old Java class hierarchies), doesn't mean we 
can't or shouldn't name some things.


The other important thing I want to emplasize yet again (just in case, 
because I know from experience in the past it's exactly this kind of 
point that rarely gets noticed), I'm not proposing D do this. It'd be 
far too big a change and it's far too incomplete to even think of trying 
to push. (Even tiny straightforward improvements to D face dowwnright 
epic levels of resistance any more.) So again, it's just some 
brainstorming. Maybe D several decades from now, maybe some other 
language inspired by D, maybe nothing ever, whatever.

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Luís Marques via Digitalmars-d]

On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote:
The official stance is that we don't.  There is just far too 
much baggage that gets piled in by default that makes it very 
hostile, however those of us who are capable of doing so won't 
try to stop you, and you have the likes of minilibd and other 
minimal D libraries as friendly replacement, perhaps you could 
even use them on top of musl. ;-)


By "we don't" it seems you are referring to supporting D + 
druntime + Phobos. But, to clarify, plain -betterC D seems to 
work well. One issue is that size_t currently has the wrong size, 
and changing it involves at least some druntime support (changing 
object.d, and changing all of the size_t line = __LINE__ fallout).


BTW, I wasn't sure how I should go about changing druntime and 
Phobos regarding the size_t line -> line_t line transition. I 
opted to change LDC's fork of druntime first, because it seemed 
to me like the contribution had a better chance of being 
accepted, and afterwards make a separate dlang/druntime pull 
request. But the more natural way would probably be to change the 
canonical druntime first and then merge the changes on the LDC 
side, no?


- Luís

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[bpr via Digitalmars-d]

On Monday, 10 July 2017 at 16:16:40 UTC, bpr wrote:

On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
Ah, I guess it is very similar after all, except it'd be based 
on top of and coexist with all of D's design by introspection 
stuff (rather than exist without it as with C++), thus 
avoiding a lot of the downsides and getting best of both 
worlds.



You've seen this, right?

https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

A small step in one such direction, influenced by C++ concepts. 
That proto-DIP also raises a question I always had about why D 
doesn't allow chained template instantiation, but that's 
another DIP for another time.


Sorry about the repeat posting, I could observe the software 
hiccuping on my browser...

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

[Iain Buclaw via Digitalmars-d]

On 10 July 2017 at 17:56, Luís Marques via Digitalmars-d
 wrote:
> On 10/07/2017 14:31, Jonathan M Davis via Digitalmars-d wrote:
>>
>> I didn't think that D supported 16-bit targets at all. Do ldc and/or gdc
>> support 16-bit targets of some kind?
>
>
> LDC accepts -mtriple=msp430 with some small tweaks. This issue arose as I as
> working on a proper implementation of those tweaks, to be accepted for
> inclusion in LDC.
>

The official stance is that we don't.  There is just far too much
baggage that gets piled in by default that makes it very hostile,
however those of us who are capable of doing so won't try to stop you,
and you have the likes of minilibd and other minimal D libraries as
friendly replacement, perhaps you could even use them on top of musl.
;-)

The same arguments that are normally brought up about C++ being used
on 16bit processors also apply to D I guess.

Iain.

Slides share: DMesos - Not only a re-implementation of Mesos

[鲜卑拓跋枫 via Digitalmars-d]

Dear all,
   I am a D-language amateur from China, and just want to share 
you with a slides from me that post on MesosCon Asia 
2017(Beijing):
   
https://mesosconasia2017.sched.com/event/AZc6/dmesos-not-only-a-re-implementation-of-mesos-ce-feng-li-emc#
   I do really wanna to implement the design or "dream" as 
described in this slides,

your help and suggestion are very welcome!
   Thanks！

BRs,
Koo