Re: LDC / BetterC / _d_run_main

[Mike Franklin via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 02:25:38 UTC, Richard wrote:

Hi,
I've been trying to see if I can get an mbed project to work 
with Dlang

basically compiling D code for use on a Cortex-M Proccessor


You might be interested in the following, if you're not already 
aware:

 * https://github.com/JinShil/stm32f42_discovery_demo
 * https://bitbucket.org/timosi/minlibd

The STM32 demo only supports GDC right now, but I'll be updating 
it to support LDC when 2.079.0 lands there.  2.079.0 removes some 
coupling of the compiler to the runtime, so I should be able to 
avoid the following bugs:


https://github.com/ldc-developers/ldc/issues/created_by/JinShil


so I tried this instead
```
extern (C) int _d_run_main(int argc, char **argv, void* 
mainFunc) {

MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}
```

but nope that didn't seem to work ether, compiles okay but the 
code in main() (D space) isn't called

I'd imagine this should be a simple thing, anyone got any ideas?


The following worked fine for me on my x64 Linux desktop with LDC 
version 1.8.0 (DMD v2.078.3, LLVM 5.0.1)


``` main.d
import core.stdc.stdio;

private alias extern(C) int function(char[][] args) MainFuncType;
extern (C) int _d_run_main(int argc, char **argv, void* mainFunc)
{
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}

void main()
{
printf("Hello, World!\n");
}
```

Compile with: ldc2 -defaultlib= -debuglib= -betterC main.d

Mike

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


nice.

andd that 'langauge specification' is really important too.. or 
people will drift towards languages that 'are' properly specified.


None of us like to be surprised by what the compiler does. The 
spec should tell it what to do.


and...just don't implement a 'no hugs' policy, or I'm outta here 
;-)

Re: dpldocs now has cross-package search (experimental)

[Andre Pany via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 00:09:18 UTC, Adam D. Ruppe wrote:

Looking for http libs? Behold:

http://search.dpldocs.info/?q=http


Oh my. Eats 2 GB of ram but with the newest patrons 
 I sprung for the beefier 
host. Only searches projects already on the site as of the 
beginning of each day (it loads what has already been 
generated, it doesn't seek to generate more at this time).


It loads one of my own deprecated modules as the top result. 
lol, it could still use some work. But it is started now.


That is so great. Thanks.

A little feature request. Could you group the found modules by 
dub package. Then the same license information can be shown once 
per dub package.


Kind regards
André

[Issue 18584] Undefined identifier when not specifying 'this'

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike Franklin  ---
Attempted Fix: https://github.com/dlang/dmd/pull/7991

--

Re: DConf hotel poor QoS

[Mike Parker via Digitalmars-d]

On Friday, 9 March 2018 at 18:08:58 UTC, Ali Çehreli wrote:



Off topic, booking all legs of your flight individually may be 
much much cheaper at least on Expedia. They first quoted I 
think $1800 for the multi-city San Francisco - Istanbul - 
Munich and back. The same trip was about $1100 when I booked 
everything individually, still on Expedia. (I am being 
approximate on the prices but the difference was very large 
like that.)


I booked both legs directly through Lufthansa and decided to fly 
into Frankfurt since it's cheaper than the direct flight to 
Munich. The flight there is costing us about $450 ea. for Basic 
Economy, non-stop. The BE seats on the way back are $600+, so we 
booked premium economy for a little over $800 ea. instead. For my 
wife and I together, $2700 round trip. Then I planned our trip 
around that: 5 nights in Frankfurt, 7 in Munich, and 3 in Berlin, 
with two Deutsche Bahn rides and an EasyJet flight in between.

Re: DConf hotel poor QoS

[Mike Parker via Digitalmars-d]

On Saturday, 10 March 2018 at 04:24:49 UTC, Adam Wilson wrote:
I booked online. I need a different room than the Conference 
Rate. But while I was there I did notice that the online rate 
for the conference room was the same as quoted on the 
conference site (89EUR).


I booked via nh-hotels.com, signed up for a membership, and paid 
in advance for 2 adults in a standard room (no breakfast) at 
~69EUR.

[Issue 18574] Unclear error message when trying to inherit from multiple classes

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/f669389682636b0d2902f4c4567b04e1cc72cb4d
Fix issue 18574: Unclear error message when trying to inherit from multiple
classes

https://github.com/dlang/dmd/commit/0f10515281a9fc0f57f121567af81beac59e56f1
Merge pull request #7987 from thewilsonator/patch-2

Fix issue 18574: Unclear error message when trying to inherit from mu…
merged-on-behalf-of: Mike Franklin 

--

[Issue 18574] Unclear error message when trying to inherit from multiple classes

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: DConf hotel poor QoS

[Adam Wilson via Digitalmars-d]

I booked online. I need a different room than the Conference Rate. But 
while I was there I did notice that the online rate for the conference 
room was the same as quoted on the conference site (89EUR).


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: LDC / BetterC / _d_run_main

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

Eh, you can simplify it a lot by just writing your own C main 
(legal with or without betterC btw)


---
import core.stdc.stdio;

extern(C)
int main(int argc, char** argv) {
printf("hello world, %s\n", argc > 1 ? argv[1] : "user");
return 0;
}
---

that should work with any compiler, with or without -betterC.

LDC / BetterC / _d_run_main

[Richard via Digitalmars-d-learn]

Hi,
I've been trying to see if I can get an mbed project to work with 
Dlang

basically compiling D code for use on a Cortex-M Proccessor
So far I've been using the latest release of LDC with the 
-BetterC Flag
From what I can gather, normally without -BetterC it works like 
this:


  * main() - C main generated by the compiler
  * _d_run_main - called by C main to setup the runtime
  * _Dmain - main function in D land, is called by _d_run_main

With -BetterC enabled, it instead works like this

  * main() - C main generated by the compiler
  * _d_run_main - needs to be written by the user since there's 
no runtime

  * _Dmain - main function in D land

so basically I need to write my own basic _d_run_main to call 
_Dmain.

Code in github does something like this typically
```
private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv, 
MainFunc mainFunc)

{
return mainFunc(null);
}
```

However the LDC compiler doesn't like this as it expects the 
mainFunc parameter to be a void pointer

so I tried this instead
```
extern (C) int _d_run_main(int argc, char **argv, void* mainFunc) 
{

MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}
```

but nope that didn't seem to work ether, compiles okay but the 
code in main() (D space) isn't called

I'd imagine this should be a simple thing, anyone got any ideas?

Re: Vision document for H1 2018

[rikki cattermole via Digitalmars-d-announce]

On 10/03/2018 10:43 AM, Andrei Alexandrescu wrote:
Hello, the vision document of the Founation for the first six months of 
2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level priority - 
locking down the language definition. This is in recognition of the fact 
that we need a precise definition of the language going forward.



Thanks,

Andrei


I was going to edit the document and argue for it (but procedure has 
been a bit different this time), shared libraries.


From what I saw in 2017 and pre 2016 too they are the number one 
implementation issue of D that drives people away. Almost everything 
else can be worked around.


Now that we have @nogc exceptions, and are going pay-as-you-go for 
runtime, this is the biggest thing holding us back IMO.


We need clear use cases with example code that works cross-platform.

With D-host, With C-host, merged with host, unmerged to host. Stuff like 
that.

dpldocs now has cross-package search (experimental)

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

Looking for http libs? Behold:

http://search.dpldocs.info/?q=http


Oh my. Eats 2 GB of ram but with the newest patrons 
 I sprung for the beefier 
host. Only searches projects already on the site as of the 
beginning of each day (it loads what has already been generated, 
it doesn't seek to generate more at this time).


It loads one of my own deprecated modules as the top result. lol, 
it could still use some work. But it is started now.

Re: Vision document for H1 2018

[Joakim via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level 
priority - locking down the language definition. This is in 
recognition of the fact that we need a precise definition of 
the language going forward.



Thanks,

Andrei


Very nice, love how concrete this document has become, including 
listing the members of the core team, especially compared to the 
vague early vision statements.


One note about @nogc: I've seen complaints about the -vgc reports 
on reddit, that they're not very useful for mixed @nogc usage, 
where the GC is used for part of the codebase, not sure if 
something can be done about that.

Re: Generic Property Implementation

[Mike Franklin via Digitalmars-d-learn]

On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:

This is the best I've come up with in the current language:

struct S {
int n;
mixin property!("field", "get => this.n", "set => this.n = 
set");

}


Not bad.  Not good, but not bad either.


Sadly, there are issues:

1) Wrong return type:
unittest {
S s;
auto a = s.field;
// Fails - typeof(a) is Property!((get) => this.n, (set) => 
this.n = set)

assert(is(typeof(a) == int));
}


This looks like a related issue:  
https://issues.dlang.org/show_bug.cgi?id=16657.  That's is a 
deal-breaker for me, but I think it could be fixed.



2) Noisy syntax:
If I had my druthers, mixin templates would be mixin'd 
automatically, and eponymous mixin templates would be a thing.


Yes, this would be nice, but I don't think it's a deal-breaker.


3) Stringy functions:
The string literal functions are an eyesore, but would require 
some compiler work to fix. This fails:


struct S {
int n;
mixin property!("field", get => this.n, set => this.n = 
set);

}

The reason is there's no 'this' at the point of instantiation, 
since we're in the context of the type, not a function where 
'this' makes sense. It seems to me this should be fixable, but 
I have no idea how much work would be required.


Yeah, that's quite unfortunate; writing code in strings stinks.  
I actually prefer the DIP for this issue alone.



4) 'this' in function bodies
It should be possible to write "get => this.n" as "get => n". 
There's no ambiguity as to which 'n' I'm referring to. Filed a 
bug:

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


Thanks for filing the issue.  I just might be able to fix it; 
I'll try.



Implementation:
https://gist.github.com/Biotronic/5849af011cbe9c7ea05515011d5995bf


You've done some great work here.  I spent about an hour on this 
yesterday, and my implementation started to require more and more 
mixing strings to get it to work.


If all of the issues you've identified were addressed, you'd end 
up with something like this (formatted in a C# way).


struct S {
int n;
property!
(
get =>
{
n
},
set =>
{
n = set
}
) field;
}

That's actually pretty darn good.  It makes me wonder if I should 
work on fixing those issues or continue with the DIP.


If you don't have any objections I'd like to incorporate this 
implementation and your analysis into the DIP.


Thank you again for doing this; you've saved me a awful lot of 
time, and have done more than I probably could have.


Mike

Re: Returning constant / literal struct value (pod)

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Mar 09, 2018 at 09:30:53PM +, Cecil Ward via Digitalmars-d-learn 
wrote:
> Can we return a literal struct value straight from a return statement?
> 
> ie something like
> mystruct_t myfunc()
> { // ... blah
> return { field1: val1, field2: val2; };
> }
> assuming that the return type is defined suitably, and the struct is
> just a C struct, plain-old-data (ie not a C++-like class).

The usual D idiom is to write:

mystruct_t myfunc() {
return mystruct_t(val1, val2);
}

Unfortunately, AFAIK at this time there's no way to write field names as
well, so you'll have to rely on the struct's field order or the ctor's
parameter order.  (But I could be wrong.)


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made 
it is still dripping.

Re: Compile-time variadic equality

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 9 March 2018 at 19:24:03 UTC, Nordlöw wrote:
I'm looking for a function (that probably should be placed in 
std.meta) named something like `areEqual` that checks whether 
all it's arguments are equal or not.


Is there such as function already in Phobos?

My usage is

static if (allEqual!(staticMap!(ElementEncodingType, Rs)))
{
// compare Rs byCodeUnit
}


NoDuplicates!V.length == 1

--
  Simen

Re: What's the proper way to add a local file dependence to dub?

[crimaniak via Digitalmars-d-learn]

On Sunday, 4 March 2018 at 16:46:56 UTC, Marc wrote:

then copy it to sources folder?

...
Also, symlinks are power tool for organizing your files without 
copying.

Vision document for H1 2018

[Andrei Alexandrescu via Digitalmars-d-announce]

Hello, the vision document of the Founation for the first six months of 
2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level priority - 
locking down the language definition. This is in recognition of the fact 
that we need a precise definition of the language going forward.



Thanks,

Andrei

Re: DConf hotel poor QoS

[Walter Bright via Digitalmars-d]

I just now booked it through Expedia. Didn't have any problems.

Returning constant / literal struct value (pod)

[Cecil Ward via Digitalmars-d-learn]

Can we return a literal struct value straight from a return 
statement ?


ie something like
mystruct_t myfunc()
{ // ... blah
return { field1: val1, field2: val2; };
}
assuming that the return type is defined suitably, and the struct 
is just a C struct, plain-old-data (ie not a C++-like class).


I've had to set up a throwaway const item, initialised, and then 
had to return that.

[Issue 18573] `cast(void)` leads to floating point return value not being popped from FPU stack

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

Summary|std.algorithm each does not |`cast(void)` leads to
   |function correctly for  |floating point return value
   |assignment under x86|not being popped from FPU
   ||stack

--

[Issue 12486] Function returning struct isn't called if `enum` of its result is accessed

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #3 from ag0ae...@gmail.com ---
Very similar case:


struct S {}

S f(ref int i)
{
++i;
return S();
}

void main()
{
int i = 2;
assert(f(i) == S());
assert(i == 3); // fails, i = 2
}


With the enum, the struct doesn't have to be empty, but here it does.

--

[Issue 18560] find on infinite ranges is broken

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords|wrong-code  |
  Component|dmd |phobos
   Hardware|x86_64  |All
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12486
 OS|Linux   |All

--- Comment #4 from ag0ae...@gmail.com ---
The codegen bug has its own dedicated issue: issue 12486.

I'm changing this to a Phobos bug. Maybe `true.repeat.all` can be made to
behave as expected by working around the compiler bug.

I'm not sure how feasible that is, though. Likely, other Phobos functions are
affected as well. Ideally, the compiler bug would get fixed soon and then this
can be closed as a duplicate. (Wishful thinking for sure.)

--

[Issue 12486] Function returning struct isn't called if `enum` of its result is accessed

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18560

--

[Issue 12486] Function returning struct isn't called if `enum` of its result is accessed

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||default_357-l...@yahoo.de

--- Comment #2 from ag0ae...@gmail.com ---
*** Issue 18562 has been marked as a duplicate of this issue. ***

--

[Issue 18562] expression is not evaluated when accessing manifest constant

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from ag0ae...@gmail.com ---


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

--

Re: Article: Why Const Sucks

[Nathan S. via Digitalmars-d-announce]

On Monday, 5 March 2018 Jonathan M Davis wrote at 
http://jmdavisprog.com/articles/why-const-sucks.html:
What Java has instead is `final`, which IMHO is borderline 
useless


In Java `final`  is extremely useful for efficient threadsafe 
code.

Re: DConf hotel poor QoS

[Walter Bright via Digitalmars-d]

On 3/9/2018 9:12 AM, Luís Marques wrote:

On Friday, 9 March 2018 at 17:07:50 UTC, Jonathan M Davis wrote:

I had similar problems


How do these people stay in business??


I wonder that every time I deal with a business that makes it hard to send them 
my money.

[Issue 18585] New: Linker error if compiled with -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18585
   Summary: Linker error if compiled with -dip1000
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: criman...@gmail.com

r.d:

void main()
{
import std.regex;

auto foo = ctRegex!`\d`;
}

Fresh install of DMD 2.079.0
r.d compiles with no keys and failed to link with -dip1000:

crimaniak@crimaniak-X550LB:~/dlang$ dmd r.d
crimaniak@crimaniak-X550LB:~/dlang$ dmd -dip1000 r.d
r.o: In function
`_D3std5regex8internal6parser__T6ParserTAyaTSQBqQBpQBmQBg7CodeGenZQBi11parseEscapeMFNeZv':
r.d:(.text._D3std5regex8internal6parser__T6ParserTAyaTSQBqQBpQBmQBg7CodeGenZQBi11parseEscapeMFNeZv[_D3std5regex8internal6parser__T6ParserTAyaTSQBqQBpQBmQBg7CodeGenZQBi11parseEscapeMFNeZv]+0x7dc):
undefined reference to `_D3std3uni__T5StackTkZQj3topMFNaNbNcNdNiNjNfZk'
r.o: In function `_D3std4conv__T8textImplTAyaTQeTxaZQuFNaNfQrxaZQw':
r.d:(.text._D3std4conv__T8textImplTAyaTQeTxaZQuFNaNfQrxaZQw[_D3std4conv__T8textImplTAyaTQeTxaZQuFNaNfQrxaZQw]+0x39):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.o: In function `_D3std4conv__T8textImplTAyaTQeTxaTQkZQxFNaNfQuxaQyZQBb':
r.d:(.text._D3std4conv__T8textImplTAyaTQeTxaTQkZQxFNaNfQuxaQyZQBb[_D3std4conv__T8textImplTAyaTQeTxaTQkZQxFNaNfQuxaQyZQBb]+0x41):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.d:(.text._D3std4conv__T8textImplTAyaTQeTxaTQkZQxFNaNfQuxaQyZQBb[_D3std4conv__T8textImplTAyaTQeTxaTQkZQxFNaNfQuxaQyZQBb]+0x77):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.o: In function `_D3std4conv__T8textImplTAyaTQeTAxaZQvFNaNbNfQuQpZQz':
r.d:(.text._D3std4conv__T8textImplTAyaTQeTAxaZQvFNaNbNfQuQpZQz[_D3std4conv__T8textImplTAyaTQeTAxaZQvFNaNbNfQuQpZQz]+0x3e):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.o: In function `_D3std4conv__T8textImplTAyaTQeZQrFNaNbNiNfNkQuZQx':
r.d:(.text._D3std4conv__T8textImplTAyaTQeZQrFNaNbNiNfNkQuZQx[_D3std4conv__T8textImplTAyaTQeZQrFNaNbNiNfNkQuZQx]+0x1c):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.o:r.d:(.text._D3std4conv__T8textImplTAyaTQeTwTQjZQwFNaNfQtwQwZQz[_D3std4conv__T8textImplTAyaTQeTwTQjZQwFNaNfQtwQwZQz]+0x41):
more undefined references to
`_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe' follow
r.o: In function
`_D3std3uni__T8CowArrayTSQwQu8GcPolicyZQz__T6__ctorTAkZQlMFNaNbNcNfQpZSQCqQCp__TQCoTQCiZQCw':
r.d:(.text._D3std3uni__T8CowArrayTSQwQu8GcPolicyZQz__T6__ctorTAkZQlMFNaNbNcNfQpZSQCqQCp__TQCoTQCiZQCw[_D3std3uni__T8CowArrayTSQwQu8GcPolicyZQz__T6__ctorTAkZQlMFNaNbNcNfQpZSQCqQCp__TQCoTQCiZQCw]+0x62):
undefined reference to
`_D3std9algorithm8mutation__T4copyTAkTQdZQmFNaNbNiNfQrNkQvZQy'
r.o: In function `_D3std4conv__T8textImplTAyaTQeTkTQjTkZQyFNaNbNfQxkQBakZQBf':
r.d:(.text._D3std4conv__T8textImplTAyaTQeTkTQjTkZQyFNaNbNfQxkQBakZQBf[_D3std4conv__T8textImplTAyaTQeTkTQjTkZQyFNaNbNfQxkQBakZQBf]+0x54):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.d:(.text._D3std4conv__T8textImplTAyaTQeTkTQjTkZQyFNaNbNfQxkQBakZQBf[_D3std4conv__T8textImplTAyaTQeTkTQjTkZQyFNaNbNfQxkQBakZQBf]+0xac):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.o: In function
`_D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp':
r.d:(.text._D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp[_D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp]+0x41):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.d:(.text._D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp[_D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp]+0x5d):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.d:(.text._D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp[_D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp]+0x79):
undefined reference to `_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe'
r.o:r.d:(.text._D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp[_D3std4conv__T6toImplTAyaTEQz5regex8internal2ir2IRZQBlFNaNfQBhZQBp]+0x95):
more undefined references to
`_D3std4conv__T2toTAyaZ__TQlTQkZQrFNaNbNiNfNkQBaZQBe' follow
collect2: error: ld returned 1 exit status
Error: linker exited with status 1

--

Re: Lazy caching map()?

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 09, 2018 at 12:47:14PM -0700, Jonathan M Davis via Digitalmars-d 
wrote:
> On Friday, March 09, 2018 11:41:46 H. S. Teoh via Digitalmars-d wrote:
> > [...]  More precisely, given an array `T[] src` of source data and a
> > function func(T) that's pretty expensive to compute, return an
> > object `result` such that:
> >
> > - result[i] == func(src[i]), for 0 ≤ i < src.length.
> >
> > - If result[j] is never actually used, func(src[j]) is never invoked
> >   (lazy).
> >
> > - If result[j] is referenced multiple times, a cached value is returned
> >   after the first time, i.e., the result of func(src[j]) is cached, and
> >   func(src[j]) is never invoked more than once.
[...]
> > Can this be done using current Phobos primitives?
> 
> Wasn't that what std.algorithm.iteration.cache was supposed to solve?
> I've never used it, so I don't know how well it fits what you need,
> but IIRC, using it with map was basically the use that it was invented
> for.
[...]

The problem with cache() is that it does not return a random-access
range, and for my use case random-access is mandatory, because I cannot
predict ahead of time which indices will be used.  Worse yet, cache()
eagerly evaluates .front and .back, which is a no-no in my case (it
should not compute elements that are not asked for).

These two limitations defeats the entire purpose, since no RA means I
have to iterate to find the elements I want, and eager evaluation means
func() will be computed as I iterate, even if I never call .front. So
basically the entire result array will be computed.

It's also not trivial to extend cache() to handle random access, because
that means it has to allocate in order to store cached elements, whereas
the current implementation statically allocates space in the returned
range to store cached .front and .back elements.


T

-- 
An imaginary friend squared is a real enemy.

Re: DConf hotel poor QoS

[Jonathan M Davis via Digitalmars-d]

On Friday, March 09, 2018 10:08:58 Ali Çehreli via Digitalmars-d wrote:
> On 03/09/2018 07:26 AM, Luís Marques wrote:
>  > conference hotel
>
> Somewhat related, I booked my room at the same hotel through Expedia for
> a cheaper price than DConf price. I'm sure it could go lower if I
> seached on other booking sites. (Expedia did increase the price about $3
> while I was clicking through with the BS "the fare has just went up;
> this happens sometimes". :) )

If that's the case, I'd suggest not even bothering with e-mailing the hotel,
since it clearly doesn't work very well.

- Jonathan M Davis

Re: Lazy caching map()?

[Jonathan M Davis via Digitalmars-d]

On Friday, March 09, 2018 11:41:46 H. S. Teoh via Digitalmars-d wrote:
> Today I found myself needing a lazy, caching version of map() on an
> array.  More precisely, given an array `T[] src` of source data and a
> function func(T) that's pretty expensive to compute, return an object
> `result` such that:
>
> - result[i] == func(src[i]), for 0 ≤ i < src.length.
>
> - If result[j] is never actually used, func(src[j]) is never invoked
>   (lazy).
>
> - If result[j] is referenced multiple times, a cached value is returned
>   after the first time, i.e., the result of func(src[j]) is cached, and
>   func(src[j]) is never invoked more than once.
>
> I couldn't figure out how to build this using Phobos primitives, so I
> wrote my own implementation of it.  Pretty simple, really, it's just a
> wrapper struct that lazily initializes an array of Nullable!T and lazily
> populates it with func(j) when opIndex(j) is invoked, and just returns
> the cached value if opIndex(j) has been invoked before.
>
> Can this be done using current Phobos primitives?

Wasn't that what std.algorithm.iteration.cache was supposed to solve? I've
never used it, so I don't know how well it fits what you need, but IIRC,
using it with map was basically the use that it was invented for.

- Jonathan M Davis

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Timothee Cour via Digitalmars-d]

updated build instructions, see
https://github.com/timotheecour/dtools/commit/8597923dd4ed7691f717b5e1bdbbf2ee66961ef5

On Fri, Mar 9, 2018 at 9:33 AM, Luís Marques via Digitalmars-d
 wrote:
> On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:
>>
>> https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d
>
>
> dtools seems to rely on the old import visibility behavior and doesn't
> compile with a recent D compiler. For instance:
>
> // functional.d:
> import std.algorithm:sort,uniq,walkLength;
>
> Error: module std.algorithm import 'walkLength' not found

Re: does the shared keyword work with mutable structs?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, March 09, 2018 19:33:26 WhatMeWorry via Digitalmars-d-learn 
wrote:
> On Friday, 9 March 2018 at 10:42:47 UTC, Kagamin wrote:
> > To make a struct noncopyable, add @disable this(this); to it,
> > then compiler will give an error on an attempt to copy it.
>
> I tried the @disable this(this); but now it doesn't even compile?
>
> Error: template std.concurrency.spawn cannot deduce function from
> argument types !()(void function(shared(EventBuffer) eB,
> shared(Lock) lock), shared(EventBuffer), shared(Lock)),
> candidates are:
> C:\ldc2\bin\..\import\std\concurrency.d(464):
> std.concurrency.spawn(F, T...)(F fn, T args) if (isSpawnable!(F,
> T))
>
>
> Is std.concurrency a work in progress or I'm I just obtuse here?
>
> I've been reading Ali's book on the concurrency chapters as
> inspiration, but the examples there use simple data types like
> ints or bools.

Well, as Kagamin said, the compiler gives you an error if you
@disable this(this); and then the code attempts to copy the type. The point
was to catch when the type was copied, not make spawn work with your type.
spawn requires that the types that its given be copyable. Either your type
needs to be able to work if it's copied, or it needs to be a reference type
(either by using a class, a pointer to a struct, or by making the struct's
guts live on the heap with a member variable that's a pointer pointing to
them).

- Jonathan M Davis

Lazy caching map()?

[H. S. Teoh via Digitalmars-d]

Today I found myself needing a lazy, caching version of map() on an
array.  More precisely, given an array `T[] src` of source data and a
function func(T) that's pretty expensive to compute, return an object
`result` such that:

- result[i] == func(src[i]), for 0 ≤ i < src.length.

- If result[j] is never actually used, func(src[j]) is never invoked
  (lazy).

- If result[j] is referenced multiple times, a cached value is returned
  after the first time, i.e., the result of func(src[j]) is cached, and
  func(src[j]) is never invoked more than once.

I couldn't figure out how to build this using Phobos primitives, so I
wrote my own implementation of it.  Pretty simple, really, it's just a
wrapper struct that lazily initializes an array of Nullable!T and lazily
populates it with func(j) when opIndex(j) is invoked, and just returns
the cached value if opIndex(j) has been invoked before.

Can this be done using current Phobos primitives?


T

-- 
Don't throw out the baby with the bathwater. Use your hands...

Re: does the shared keyword work with mutable structs?

[WhatMeWorry via Digitalmars-d-learn]

On Friday, 9 March 2018 at 10:42:47 UTC, Kagamin wrote:
To make a struct noncopyable, add @disable this(this); to it, 
then compiler will give an error on an attempt to copy it.


I tried the @disable this(this); but now it doesn't even compile?

Error: template std.concurrency.spawn cannot deduce function from 
argument types !()(void function(shared(EventBuffer) eB, 
shared(Lock) lock), shared(EventBuffer), shared(Lock)), 
candidates are:
C:\ldc2\bin\..\import\std\concurrency.d(464): 
std.concurrency.spawn(F, T...)(F fn, T args) if (isSpawnable!(F, 
T))



Is std.concurrency a work in progress or I'm I just obtuse here?

I've been reading Ali's book on the concurrency chapters as 
inspiration, but the examples there use simple data types like 
ints or bools.

Re: Inline Module / Namespace

[Jonathan M Davis via Digitalmars-d]

On Friday, March 09, 2018 18:44:07 Jonathan via Digitalmars-d wrote:
> D kinda lacks a way of creating a module/namespace inside another
> file.
>
> D does have modules but they have to be in separate files.
> (Though separate files may be better coding practice, why is it
> D's job to tell me how to code.)

It may not be the language's job to tell you how to code, but inevitably,
decisions haave to be made in the language design which essentially express
an opinion about how things should work, and the result is going to either
be the way you want it, or it isn't. In this case, it simplifies things
considerably to have modules correspond to files and packages correspond to
directories, and plenty of folks would argue that it's bad practice to do
otherwise (though obviously, there's some disagreement on that). Regardless,
it's the way that D went, and based on what Walter has said on it in the
past, I'd be very surprised to ever see that change. As with any language,
there are things that you're either going to have to put up with or decide
that they annoy you enough that you'd rather use another language.

> I think a simple way to do this with existing syntax is to add
> functionality for `module` to be used as a block.
>
>
>  module modulename {
>  void fun(){}
>  }
>  modulename.fun();
>
>
> An inline module.

You can always do something like declare a final abstract class with static
functions to create a new namespace of sorts in that any symbols inside it
then must be referred to using the class name, but it's not actually a
module and won't be directly importable as such, and without aliases, the
"namespace" must always be used when referring to the functions. It's not
something that's generally considered to be particularly good practice
though. Phobos does it in a couple of places where it seemed to make sense
at the time, but it's not something that's caught on, and I doubt that
anything more will ever be added to Phobos which does it. Regardless, I
expect that that's the closest that you'll ever get to declaring a module
within a module in D.

- Jonathan M Davis

Re: Compile-time variadic equality

[Nordlöw via Digitalmars-d-learn]

On Friday, 9 March 2018 at 19:24:03 UTC, Nordlöw wrote:
I'm looking for a function (that probably should be placed in 
std.meta) named something like `areEqual` that checks whether 
all it's arguments are equal or not.


Is there such as function already in Phobos?

My usage is

static if (allEqual!(staticMap!(ElementEncodingType, Rs)))
{
// compare Rs byCodeUnit
}


My current own implementation is

/** Returns: true iff all values $(D V) are the same.
See also: 
http://forum.dlang.org/post/iflpslqgrixdjwrlq...@forum.dlang.org
See also: 
http://forum.dlang.org/post/mheumktihihfsxxxa...@forum.dlang.org

*/
template allSame(V ...)
if (isExpressions!V)
{
static if (V.length <= 1)
{
enum allSame = true;
}
else static if (V.length & 1)
{
enum allSame = (V[$ - 1] == V[0] &&
V[0 .. $/2] == V[$/2 .. $-1] &&
allSame!(V[0 .. $/2]));
}
else
{
enum allSame = (V[0 .. $/2] == V[$/2 .. $] &&
allSame!(V[0 .. $/2]));
}
}

Should this go into std.meta?

Compile-time variadic equality

[Nordlöw via Digitalmars-d-learn]

I'm looking for a function (that probably should be placed in 
std.meta) named something like `areEqual` that checks whether all 
it's arguments are equal or not.


Is there such as function already in Phobos?

My usage is

static if (allEqual!(staticMap!(ElementEncodingType, Rs)))
{
// compare Rs byCodeUnit
}

Re: Inline Module / Namespace

[Adam D. Ruppe via Digitalmars-d]

On Friday, 9 March 2018 at 18:51:50 UTC, Manu wrote:
If you tried to `import modulename;` from some other module... 
how would the compiler know where to find it?


The compiler has to parse the module to find them correctly 
already. When you do foo.bar into foo/bar.d, it is just the first 
guess the tools take by convention. If you pass the module on the 
command line the compiler actually parses them to find the name 
anyway and the file system location/name is irrelevant.

[Issue 10488] Allow template this parameter to work with static functions

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||blah38...@gmail.com

--- Comment #6 from Nick Treleaven  ---
*** Issue 14191 has been marked as a duplicate of this issue. ***

--

[Issue 14191] Failure to locate overload with template this parameter

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Nick Treleaven  ---
The spec says:
"TemplateThisParameters are used in member function templates to pick up the
type of the this reference."

Using them in static methods is an enhancement, so this is a duplicate.

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

--

Re: Build an AliasSeq from memberFunction return types

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 9 March 2018 at 17:47:46 UTC, Timoses wrote:
To retrieve the member names the following (and filtering for 
only the functions) does the job:


   alias members = aliasSeqOf!([__traits(allMembers, S)]);


This can be simplified to
alias members = Alias!(__traits(allMembers, S));


However, I now would want to build an AliasSeq of the types. My 
idea would be (absolute pseudocode!!!):


   alias memberTypes;
   static foreach (member; members)
   {
  memberTypes ~= ReturnType!S.member;
   }


Generally, we use recursive templates in these cases:

template GetMemberTypes(funcs...) {
static if (funcs.length == 0) {
alias GetMemberTypes = AliasSeq!();
} else {
alias GetMemberTypes = AliasSeq!(
  ReturnType!(funcs[0]),
  GetMemberTypes!(funcs[1..$])
  );
}
}


However, std.meta has staticMap, which will do this recursion for 
us:


alias memberTypes = staticMap!(ReturnType, members);

Of course, this assumes 'members' contains only the functions you 
care about. All in all, what you want can be boiled down to this 
code:



import std.meta : staticMap, Alias, Filter;
import std.traits : isFunction, ReturnType;
import std.bitmanip : bitfields;

struct A
{
int a;
mixin(bitfields!(
uint, "x",2,
int,  "y",3,
uint, "z",2,
bool, "flag", 1));
}

template GetMember(T) {
alias GetMember(string name) = Alias!(__traits(getMember, T, 
name));

}
alias memberTypes = staticMap!(ReturnType, Filter!(isFunction, 
staticMap!(GetMember!A, __traits(allMembers, A;



So, how does it work?

GetMember is a template that takes an aggregate type as a 
parameter and returns a new template that takes a string. This 
inner template then returns the member of the aggregate type that 
has that name:


// Define a template that will find a member in A.
alias GetMemberOfA = GetMember!A;

// Get the 'flag' member of A.
alias someMemberOfA = GetMemberOfA!"flag";



Next: This line is a bit of a mouthful, so let's break it down:
alias memberTypes = staticMap!(ReturnType, Filter!(isFunction, 
staticMap!(GetMember!A, __traits(allMembers, A;


becomes:

// Grab the name of every single member of A.
alias allMemberNames = Alias!(__traits(allMembers, A));

// Define a template that will find a member in A.
alias GetMemberOfA = GetMember!A;

// Now get the members of A that correspond to the names 
__traits(allMembers) returned.

alias allMembers = staticMap!(GetMemberOfA, allMemberNames);

// Get rid of everything that's not a function.
alias onlyFunctions = Filter!(isFunction, allMembers);

// And finally grab the return type of each function.
alias memberTypes = staticMap!(ReturnType, onlyFunctions);

--
  Simen

Re: Inline Module / Namespace

[Timothee Cour via Digitalmars-d]

I'm sure he meant:

```
--- foo.d
module foo;
module foo.bar{
  void fun(){}
}

--- foo2.d
import foo.bar;
```


On Fri, Mar 9, 2018 at 10:51 AM, Manu via Digitalmars-d
 wrote:
> On 9 March 2018 at 10:44, Jonathan via Digitalmars-d
>  wrote:
>> D kinda lacks a way of creating a module/namespace inside another file.
>>
>> D does have modules but they have to be in separate files.  (Though separate
>> files may be better coding practice, why is it D's job to tell me how to
>> code.)
>>
>> I think a simple way to do this with existing syntax is to add functionality
>> for `module` to be used as a block.
>>
>>
>> module modulename {
>> void fun(){}
>> }
>> modulename.fun();
>>
>>
>> An inline module.
>
> If you tried to `import modulename;` from some other module... how
> would the compiler know where to find it?

[Issue 17773] this template parameter not working from derived class

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Nick Treleaven  ---
Changing foo to use `this.classSize;` works.

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

--

[Issue 14484] IFTI doesn't work with TemplateThisParameter and inheritance

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #2 from Nick Treleaven  ---
*** Issue 17773 has been marked as a duplicate of this issue. ***

--

Re: Inline Module / Namespace

[Manu via Digitalmars-d]

On 9 March 2018 at 10:44, Jonathan via Digitalmars-d
 wrote:
> D kinda lacks a way of creating a module/namespace inside another file.
>
> D does have modules but they have to be in separate files.  (Though separate
> files may be better coding practice, why is it D's job to tell me how to
> code.)
>
> I think a simple way to do this with existing syntax is to add functionality
> for `module` to be used as a block.
>
>
> module modulename {
> void fun(){}
> }
> modulename.fun();
>
>
> An inline module.

If you tried to `import modulename;` from some other module... how
would the compiler know where to find it?

Re: Vtable for virtual functions in D

[Manu via Digitalmars-d]

On 8 March 2018 at 14:56, Henrik via Digitalmars-d
 wrote:
>
> It all works good, but why do I have to put the @nogc on the constructor and 
> destructor separately?

@nogc in the global scope does not propagate inside the class (this
could lead to serious problems).
You can use `@nogc:` at the top of your class to make all class
contents @nogc too.

[Issue 17773] this template parameter not working from derived class

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #1 from Nick Treleaven  ---
Reduced with commented edit:

class Base
{
size_t classSize(this This)()
{
pragma(msg, This);
return This.sizeof;
}
}

class Derived : Base
{
void foo()
{
classSize();  // added ()
}
}

Error: template `templatethisparam.Base.classSize` cannot deduce function from
argument types `!()()`, candidates are:
   `templatethisparam.Base.classSize(this This)()`

--

Inline Module / Namespace

[Jonathan via Digitalmars-d]

D kinda lacks a way of creating a module/namespace inside another 
file.


D does have modules but they have to be in separate files.  
(Though separate files may be better coding practice, why is it 
D's job to tell me how to code.)


I think a simple way to do this with existing syntax is to add 
functionality for `module` to be used as a block.



module modulename {
void fun(){}
}
modulename.fun();


An inline module.

[Issue 18575] making delegate from member function can lead to unsafe code

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/75966dac262efb407bfedc6e1ed993802d95c7c8
fix Issue 18575 - making delegate from member function can lead to unsafe code

https://github.com/dlang/dmd/commit/51087a02078585204377d8dad1b029f50bfa407e
Merge pull request #7989 from WalterBright/fix18575

fix Issue 18575 - making delegate from member function can lead to un…

--

Re: DConf hotel poor QoS

[Ali Çehreli via Digitalmars-d]

On 03/09/2018 07:26 AM, Luís Marques wrote:
> conference hotel

Somewhat related, I booked my room at the same hotel through Expedia for 
a cheaper price than DConf price. I'm sure it could go lower if I 
seached on other booking sites. (Expedia did increase the price about $3 
while I was clicking through with the BS "the fare has just went up; 
this happens sometimes". :) )


Off topic, booking all legs of your flight individually may be much much 
cheaper at least on Expedia. They first quoted I think $1800 for the 
multi-city San Francisco - Istanbul - Munich and back. The same trip was 
about $1100 when I booked everything individually, still on Expedia. (I 
am being approximate on the prices but the difference was very large 
like that.)


Ali

[Issue 9551] template this parameter not recognized in constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |FIXED

--- Comment #10 from Nick Treleaven  ---
(In reply to Gor Gyolchanyan from comment #0)
>   Base b = new Derived;
>   b(); // 100% transparent dynamic dispatch

The code compiles with dmd v2.077.1 (if you add a dummy argument above, to
match the signature, e.g. b(4)).

--

Build an AliasSeq from memberFunction return types

[Timoses via Digitalmars-d-learn]

Hi,

I feel like starting to dig deeper into D. And I got lost : D.

I would like to reflect on defined bitfields:

   struct S
   {
  mixin!(bitfields!(
 , , ,
 ...
  ));
   }

which produces something like this in the back scenes:

   struct S
   {
  uint storage;

  @property  () {
 ... return field from storage;
  }
   }

There is an approach here:
https://forum.dlang.org/post/o5u21b$15f3$1...@digitalmars.com
However, it feels a bit overcomplicating the issue perhaps.

To retrieve the member names the following (and filtering for 
only the functions) does the job:


   alias members = aliasSeqOf!([__traits(allMembers, S)]);

However, I now would want to build an AliasSeq of the types. My 
idea would be (absolute pseudocode!!!):


   alias memberTypes;
   static foreach (member; members)
   {
  memberTypes ~= ReturnType!S.member;
   }

   pragma(msg, memberTypes); // prints sth like: (int, bool, 
uint, ...)


I have taken a look at https://dlang.org/phobos/std_meta.html but 
am unsure whether I can actually build an AliasSeq iteratively.


The mentioned example might help:
   alias TL = AliasSeq!(int, double);
   alias Types = AliasSeq!(TL, char);
   static assert(is(Types == AliasSeq!(int, double, char)));

However, I can't simply do

   static foreach (i, member; members)
   {
  alias memberTypes_i = AliasSeq!
 (memberTypes_i, ReturnType!S.) // <--- no idea 
even how to get
// the ReturnType 
here...
// S.member does 
not work

   }
   alias memberTypes = AliasSeq!(memberTypes_i_max);

But what the heck! I can't find a solution!
This might be related to:
https://forum.dlang.org/post/pxtqeahzxrsrljnrw...@forum.dlang.org

Do you have any ideas? Or does your head start spinning like mine 
does, too?

Re: How to fake a const method ?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, March 09, 2018 14:12:10 Basile B. via Digitalmars-d-learn wrote:
> On Friday, 9 March 2018 at 13:47:34 UTC, Basile B. wrote:
> > I would need this to work:
> >
> > ```
> > struct Foo
> > {
> >
> > TypeInfo typeCache;
> >
> > TypeInfo getTypeCache()
> > {
> >
> > alias NotThePoint = ubyte;
> > if (typeCache is null)
> >
> > typeCache = typeid(NotThePoint);
> >
> > return typeCache;
> >
> > }
> >
> > TypeInfo type() const
> > {
> >
> > alias NothrowType = TypeInfo delegate() const;
> > return (cast(NothrowType) )();
> >
> > }
> >
> > }
> >
> > void main(){}
> > ```
> >
> > But get:
> >> Error: mutable method `Foo.getTypeCache` is not callable using
> >> a `const` `this`
> >
> > - `type()` really has to be const because it's used in an
> > opEquals that's used by an AA (key is const so opEquals has to
> > as well)
> > - `typeCache` is not used to compare 2 Foos so it really
> > doesn't matter if it get assigned.
>
> Solved...The error message helped much actually... problem is
> `this` is `const`
>
> https://run.dlang.io/is/UOR2i2

Yes. That's what happens when you mark the function as const. Making the
this pointer/reference const is exactly what marking a member function const
does. However, if your solution involves casting away const, you had better
be 100% sure that the result is never mutated, because if it is mutated,
you're violating the type system and could get weird and subtle bugs. It
would be better if you could just remove const from the equation entirely,
but if you're dealing with AA keys, that's a bit difficult, since they're
immutable (forcing you to deal with either immutable or const).

- Jonathan M Davis

Re: Release: nanovega.d rendering lib like html5 canvas

[WebFreak001 via Digitalmars-d-announce]

On Thursday, 8 March 2018 at 22:08:30 UTC, aberba wrote:

On Thursday, 8 March 2018 at 19:24:43 UTC, WebFreak001 wrote:

On Thursday, 8 March 2018 at 03:55:35 UTC, Adam D. Ruppe wrote:

https://github.com/adamdruppe/arsd

nanovega.d

[...]


AMAZING! I think this will revolutionize how we do GUI and 
rendering in D, especially nogc. You can make really cool 
effects and renders very quickly.


Got some cool project ideas how you could use this already. 
You could make a WPF clone in D for example if you put in a 
lot of time, but it would probably be far superior than all 
other currently existing GUI toolkits if you get the data 
binding and event layer right.


And theming. Especially with a subset of CSS.


Yeah you can make really cool effects: https://wfr.moe/fFYvHH.png

---

string txt = "Text me up.";
float[4] bounds;
nvg.fontFace = "Roboto";
nvg.fontSize = 32;
nvg.textBounds(64, 64, txt, bounds[]);
nvg.beginPath();
nvg.roundedRect(bounds[0] - 32, bounds[1] - 8 + 8, 
bounds[2]-bounds[0] + 64, bounds[3]-bounds[1] + 16, 4);
nvg.fillPaint = nvg.linearGradient(bounds[0], bounds[1], 
bounds[2], bounds[3], NVGColor("#c50"), NVGColor("#860"));

nvg.fill();
nvg.beginPath();
nvg.roundedRect(bounds[0] - 32, bounds[1] - 8, 
bounds[2]-bounds[0] + 64, bounds[3]-bounds[1] + 16, 4);
nvg.fillPaint = nvg.linearGradient(bounds[0], bounds[1], 
bounds[2], bounds[3], NVGColor("#f70"), NVGColor("#a90"));

nvg.fill();
nvg.fillPaint = pattern;
nvg.fill();
nvg.beginPath();
nvg.roundedRect(bounds[0] - 32, bounds[1] - 8, 
bounds[2]-bounds[0] + 64, bounds[3]-bounds[1] + 16 + 8, 4);

nvg.strokeColor = NVGColor.white;
nvg.strokeWidth = 2;
nvg.stroke();
nvg.fillColor = NVGColor.black;
nvg.text(64, 64, txt);

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Luís Marques via Digitalmars-d]

On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:

https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d


dtools seems to rely on the old import visibility behavior and 
doesn't compile with a recent D compiler. For instance:


// functional.d:
import std.algorithm:sort,uniq,walkLength;

Error: module std.algorithm import 'walkLength' not found

Re: DConf hotel poor QoS

[Jonathan M Davis via Digitalmars-d]

On Friday, March 09, 2018 17:12:31 Luís Marques via Digitalmars-d wrote:
> On Friday, 9 March 2018 at 17:07:50 UTC, Jonathan M Davis wrote:
> > I had similar problems
>
> How do these people stay in business??

Probably by normally having folks use their website rather than e-mail them,
and if it's rare enough for folks to e-mail in like this, they don't have to
actually handle it well to stay in business. Personally, I think that it's
quite weird to be e-mailing in to make reservations. My guess is that we
were told to e-mail in, because their website probably doesn't have a way to
indicate that you want a special rate like this. Still, I was quite
surprised at how slow they were in responding to e-mails, and I was just
about to give up on getting a reservation that way when I finally got the
e-mail saying that they'd made one (with the wrong dates though).

I was also surprised that I had as much trouble getting to someone on the
phone who could help me as I did. Given that they're an international hotel
chain, I would have expected more of their folks on the phone to speak
English. That problem would be more understandable if they were just in
Germany, but they're not.

- Jonathan M Davis

[Issue 18580] std.conv.to!(ubyte[])(void[]) should work

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Jonathan M Davis  ---
Going from void[] to anything is the safety problem, because that's when the
data would potentially be reintrepreted incorrectly. Going to void[] from
anything doesn't directly introduce @safety problems. It just strips out the
ability to prevent them once converting to something else, because the type
information has been lost. I believe that the normal thing to do with void[] is
do something like write to a file or socket, in which case, it's arguably just
an @safe way to convert arbitrary data to bytes rather than require an explicit
cast (since the C API uses void* IIRC).

Either way, if you have void[] and are looking to do something with it other
than hand it off to a C API that takes void* and writes bytes to some system
resource, you need to know where it comes from and verify that the cast that
you're doing is @safe.

--

Re: DConf hotel poor QoS

[Luís Marques via Digitalmars-d]

On Friday, 9 March 2018 at 17:07:50 UTC, Jonathan M Davis wrote:

I had similar problems


How do these people stay in business??

Re: DConf hotel poor QoS

[Jonathan M Davis via Digitalmars-d]

On Friday, March 09, 2018 15:26:24 Luís Marques via Digitalmars-d wrote:
> I'm not impressed with the conference hotel so far. Here's a
> summary of my interactions with them:
>
> Feb-6: I send an email to reservierun...@nh-hotels.com with the
> keyword D-Conf in the subject line, as indicated in the
> conference page. I ask for a reservation between 30-04-2018 and
> 6-05-2018 (6 nights), since it was cheaper to stay an extra
> night, as the plane ticket that day was less expensive.
>
> Feb-9: I get an email asking to which hotel I would like to
> reserve. I hadn't notice it was a chain of hotels, but I'm
> surprised the special keyword didn't let them determine that
> automatically. I reply that I want a reservation for the NH
> München Messe, with the DConf conference special rate.
>
> Feb-13: I send them an email saying I continue to await their
> reply.
>
> Feb-14: They reply with a proposal. They have a different rate
> for 30.04.2018, because that's not included in the conference
> special. Fine. Here I had some other expenses on my credit card,
> so I decide to wait some days for that to sort out.
>
> Feb-20: They reply again with a seemingly similar email (not
> really! more on that later).
>
> Feb-21: I reply to confirm that I want to book. I send them my CC
> number and name, and ask if they need the CVV too.
>
> Feb-23: They say they need the expiry date. (why didn't they just
> say what CC details they needed in the original email?...). I
> reply with the needed data.
>
> Mar-1: I ask if my reservation has been made
>
> Mar-2: They confirm my reservation. Unfortunately, it seems that
> on the Feb-20 email they had changed the reservation dates to
> "From 01.05.2018 to 05.05.2018 and from 05.05.2018 to
> 06.05.2018". I hadn't noticed that. So one night is missing. I
> reply to them explaining the situation and asking for a change.
>
> Mar-9: I send them an email saying I continue to await a
> correction to my reservation.

I had similar problems (though they never asked for my CC number via e-mail,
and I don't know what I would have done if they had, since I won't give that
via e-mail). After I _finally_ got an e-mail with a reservation number, and
they'd screwed up the dates, rather than play more e-mail tag, I called one
of the numbers listed in that e-mail and (after getting passed around a fair
bit) managed to talk to someone who could speak and English and fix my
reservation - and who I could ask how I was supposed to pay, since they'd
never asked for any form of money in any of the e-mails i got sent (so I
gave my CC number over the phone). I don't know what their normal rates are,
so I don't know how much money going through this process saved me, but I
suspect that it would have been far easier to just book the room through
their website and pay the extra money than deal with playing e-mail tag and
then getting passed around on the phone until I managed to get to the right
person to fix my reservation. I did finally get it all sorted out though.

- Jonathan M Davis

Re: The New New DIP Process

[Joakim via Digitalmars-d-announce]

On Friday, 9 March 2018 at 12:59:07 UTC, Mike Parker wrote:
When I took on the role of DIP Manager last year, I didn't 
realize how much I had to learn. Most of the DIPs made it 
through just fine, but there were a few errors along the way. 
And there were some inefficiencies built into the system that 
weren't so obvious in the beginning. Recently, my new procedure 
document to revise the process was approved.


[...]


mistake: "for the all the details"

Re: complex arithmetic in D: multiple questions

[bachmeier via Digitalmars-d-learn]

On Friday, 9 March 2018 at 14:41:47 UTC, J-S Caux wrote:

Going further, I'm really wondering what the plan is as far as 
Complex is concerned. Right now it just feels neglected 
(half-done/aborted transition from creal etc to Complex, lots 
of missing basic functions etc), and is one major blocking 
point as far as adoption (among scientists) is concerned. Julia 
is really taking off with many of my colleagues, mostly because 
due respect was given to maths. I'd certainly choose Julia if 
it wasn't for the fact that I can't get my exploratory/testing 
codes to run faster than about 1/10th of my C++ stuff. It seems 
D could have such an appeal in the realm of science, but these 
little things are really blocking adoption (including for 
myself).


I don't do the things you're doing (I do econometrics) but I 
don't think that at this point D is ready to be used as a 
complete solution for everything you need. It can be done, but 
someone has to do the work, and that hasn't happened. D is 
designed to be fully interoperable with C and mostly 
interoperable with C++. You'll get the same performance as C, but 
that doesn't help if the libraries you need haven't been written 
yet.


From a practical perspective (i.e., you want to just work without 
writing a bunch of low-level stuff yourself) it's best to prepare 
to call from D into C/C++ or from C/C++ into D. This hybrid 
approach has worked well for me, and to be honest, I'd rather 
rely on well-tested, well-maintained C libraries than worry about 
pure D libraries that haven't been tested extensively and may or 
may not be maintained in the future. It really doesn't matter to 
your own code if the function you're calling was written in C or 
written in D.


As for Julia, that was created as a Matlab replacement, and they 
have full-time devs to work on it. If I were starting over, I 
would consider Julia for my own work. I'd probably still choose D 
but Julia does offer advantages.

[Issue 18580] std.conv.to!(ubyte[])(void[]) should work

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from ag0ae...@gmail.com ---
(In reply to Jack Stouffer from comment #5)
> Well the argument there is that the conversion from p to v should be unsafe,
> but not the conversion of v to b.

Either or, I guess. Either you forbid going from pointers to void[], or you
forbid going anywhere from void[]. As far as I see, both options provide
safety, or does the second one have any holes?

DMD currently goes with the second option. Changing it would not be a small
task, I think.

--

Re: Release D 2.079.0

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-03-08 19:21, Martin Nowak wrote:


Also this offer still stands
https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org


Who will decide if semver can/will be used?

--
/Jacob Carlborg

Re: Vibe.d web interface tutorial

[aberba via Digitalmars-d-announce]

On Friday, 9 March 2018 at 16:32:28 UTC, aberba wrote:

New blog post for the learning audience

aberba.com/2018/using-vibe-d-web-interface


http://aberba.com/2018/using-vibe-d-web-interface

Vibe.d web interface tutorial

[aberba via Digitalmars-d-announce]

New blog post for the learning audience

aberba.com/2018/using-vibe-d-web-interface

[Issue 18580] std.conv.to!(ubyte[])(void[]) should work

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Jack Stouffer  ---
(In reply to ag0aep6g from comment #4)
> (In reply to Jack Stouffer from comment #3)
> > Is it unsafe though? In this specific case of void[] to ubyte[] (or vise
> > versa) isn't it ok?
> 
> void[] to ubyte[] is unsafe, because anything converts to void[]:
> 
> 
> void f(int*[] p)
> {
> void[] v = p; /* This is considered @safe. Don't even need a cast. */
> ubyte[] b = cast(ubyte[]) v; /* Just as unsafe as `cast(ubyte[]) p`. */
> b[0] = 123; /* Messing with pointers like this is not safe. */
> }
> 

Well the argument there is that the conversion from p to v should be unsafe,
but not the conversion of v to b.

--

Re: Release: nanovega.d rendering lib like html5 canvas

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

Now also on dub:

http://code.dlang.org/packages/arsd-official%3Ananovega

DConf hotel poor QoS

[Luís Marques via Digitalmars-d]

I'm not impressed with the conference hotel so far. Here's a 
summary of my interactions with them:


Feb-6: I send an email to reservierun...@nh-hotels.com with the 
keyword D-Conf in the subject line, as indicated in the 
conference page. I ask for a reservation between 30-04-2018 and 
6-05-2018 (6 nights), since it was cheaper to stay an extra 
night, as the plane ticket that day was less expensive.


Feb-9: I get an email asking to which hotel I would like to 
reserve. I hadn't notice it was a chain of hotels, but I'm 
surprised the special keyword didn't let them determine that 
automatically. I reply that I want a reservation for the NH 
München Messe, with the DConf conference special rate.


Feb-13: I send them an email saying I continue to await their 
reply.


Feb-14: They reply with a proposal. They have a different rate 
for 30.04.2018, because that's not included in the conference 
special. Fine. Here I had some other expenses on my credit card, 
so I decide to wait some days for that to sort out.


Feb-20: They reply again with a seemingly similar email (not 
really! more on that later).


Feb-21: I reply to confirm that I want to book. I send them my CC 
number and name, and ask if they need the CVV too.


Feb-23: They say they need the expiry date. (why didn't they just 
say what CC details they needed in the original email?...). I 
reply with the needed data.


Mar-1: I ask if my reservation has been made

Mar-2: They confirm my reservation. Unfortunately, it seems that 
on the Feb-20 email they had changed the reservation dates to 
"From 01.05.2018 to 05.05.2018 and from 05.05.2018 to 
06.05.2018". I hadn't noticed that. So one night is missing. I 
reply to them explaining the situation and asking for a change.


Mar-9: I send them an email saying I continue to await a 
correction to my reservation.

Re: complex arithmetic in D: multiple questions

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 9 March 2018 at 14:41:47 UTC, J-S Caux wrote:
Is this a case for a bug report? Seems pretty bizarre to do 
that, like an oversight/neglect.


Yes if there's not one there for it already.

OK thanks. I looked at libmir, and saw many good things there. 
I was wondering: is it still actively developed/maintained? How 
will it fit with the "core" D in the future? [I don't want to 
build dependencies to libraries which aren't there to stay in 
the long run, I want code which can survive for decades]. It 
would seem to me that some of the things included in there 
should be part of D core/std anyway.


Yes, it is sponsored by https://github.com/kaleidicassociates it 
will be around for a long time.
It is developed separately because the dev/release cycles don't 
easily align with the core/ stdlib developers.


https://github.com/libmir/mir-algorithm/blob/master/source/mir/ndslice/slice.d#L594
is the de facto matrix structure for D.

Going further, I'm really wondering what the plan is as far as 
Complex is concerned. Right now it just feels neglected 
(half-done/aborted transition from creal etc to Complex, lots 
of missing basic functions etc), and is one major blocking 
point as far as adoption (among scientists) is concerned. Julia 
is really taking off with many of my colleagues, mostly because 
due respect was given to maths. I'd certainly choose Julia if 
it wasn't for the fact that I can't get my exploratory/testing 
codes to run faster than about 1/10th of my C++ stuff. It seems 
D could have such an appeal in the realm of science, but these 
little things are really blocking adoption (including for 
myself).


Indeed, I'll see what I can do about it.


[related questions:


Did you press send too soon?


No, the related questions were linked in my previous post (just 
copied & pasted it further above, but didn't delete these last 
couple of words properly).


Thanks a lot Nicholas!

Re: Generic Property Implementation

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote:

* binary assignment operators (e.g. +=)
* unary assignment operators (e.g. ++)
* @safe, @nogc, and -betterC compatible
* at least as good code generation as that proposed in the DIP 
when optimizations are enabled.
* And should be scalable to data that isn't addressable (e.g. 
bitfields).  See

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


This is the best I've come up with in the current language:

struct S {
int n;
mixin property!("field", "get => this.n", "set => this.n = 
set");

}

unittest {
import std.conv : to;
S s;
s.field = 3;
assert(s.field == 3);
s.field += 2;
assert(s.field == 5);
s.field++;
assert(s.field == 6);
assert(s.field.to!string == "6");
}

Sadly, there are issues:

1) Wrong return type:
unittest {
S s;
auto a = s.field;
// Fails - typeof(a) is Property!((get) => this.n, (set) => 
this.n = set)

assert(is(typeof(a) == int));
}
Not a whole lot to do about this. I've pondered writing a DIP on 
auto-decaying/rvalue types, which would decay to a different type 
the moment they're passed to a function or assigned to a 
variable. The feature would probably not be worth the trouble, 
though.



2) Noisy syntax:
If I had my druthers, mixin templates would be mixin'd 
automatically, and eponymous mixin templates would be a thing. 
That would give us this syntax:


struct S {
int n;
property!("get => this.n", "set => this.n = set") field;
}


3) Stringy functions:
The string literal functions are an eyesore, but would require 
some compiler work to fix. This fails:


struct S {
int n;
mixin property!("field", get => this.n, set => this.n = set);
}

The reason is there's no 'this' at the point of instantiation, 
since we're in the context of the type, not a function where 
'this' makes sense. It seems to me this should be fixable, but I 
have no idea how much work would be required.



4) 'this' in function bodies
It should be possible to write "get => this.n" as "get => n". 
There's no ambiguity as to which 'n' I'm referring to. Filed a 
bug:

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

Implementation:
https://gist.github.com/Biotronic/5849af011cbe9c7ea05515011d5995bf

--
  Simen

Re: complex arithmetic in D: multiple questions

[J-S Caux via Digitalmars-d-learn]

On Friday, 9 March 2018 at 13:56:33 UTC, Nicholas Wilson wrote:
- I would expect the D `Complex!double` case to work faster 
than the `real` one. Why is it the other way around? [I can 
accept (and use) D with Complex!real running 1/3 the speed of 
C++ (but with increased accuracy), but I'd also love to be 
able to run D with `Complex!double` at C++ speeds, since the 
tradeoff might be worth it for some calculations]


because the double version is doing the exact same work as the 
real
except that it is also converting between real and double for 
atan2 (from arg). 
https://github.com/dlang/phobos/blob/master/std/math.d#L1352


I'm really not sure why phobos does that, it should't.


Is this a case for a bug report? Seems pretty bizarre to do that, 
like an oversight/neglect.


- what is the best way to correct the unfortunate (to be 
polite) omission of many standard mathematical functions from 
std.complex? [if I may be frank, this is a real pain for us 
scientists] There exists 
https://gist.github.com/Biotronic/17af645c2c9b7913de1f04980cd22b37 but can this be integrated (after improvements) in the language, or should I (re)build my own?


It will be much faster to build your own that just forward to 
the C functions (or LLVM intrinsics) see 
https://github.com/libmir/mir-algorithm/blob/master/source/mir/math/common.d#L126 for a starting point (we'd greatly appreciate pull requests for anything missing).
Even if the decision to make std.math behave at the appropriate 
precision is accepted, it will still take an entire release 
cycle (unless you use dmd master), and I'm not so sure it will.




OK thanks. I looked at libmir, and saw many good things there. I 
was wondering: is it still actively developed/maintained? How 
will it fit with the "core" D in the future? [I don't want to 
build dependencies to libraries which aren't there to stay in the 
long run, I want code which can survive for decades]. It would 
seem to me that some of the things included in there should be 
part of D core/std anyway.


Going further, I'm really wondering what the plan is as far as 
Complex is concerned. Right now it just feels neglected 
(half-done/aborted transition from creal etc to Complex, lots of 
missing basic functions etc), and is one major blocking point as 
far as adoption (among scientists) is concerned. Julia is really 
taking off with many of my colleagues, mostly because due respect 
was given to maths. I'd certainly choose Julia if it wasn't for 
the fact that I can't get my exploratory/testing codes to run 
faster than about 1/10th of my C++ stuff. It seems D could have 
such an appeal in the realm of science, but these little things 
are really blocking adoption (including for myself).



[related questions:


Did you press send too soon?


No, the related questions were linked in my previous post (just 
copied & pasted it further above, but didn't delete these last 
couple of words properly).


Thanks a lot Nicholas!

Re: Why not flag away the mistakes of the past?

[Chris via Digitalmars-d]

On Friday, 9 March 2018 at 06:14:05 UTC, Jonathan M Davis wrote:



We'll make breaking changes if we judge the gain to be worth 
the pain, but we don't want to be constantly breaking people's 
code, and some changes are large enough that there's arguably 
no justification for them, because they would simply be too 
disruptive. Because of how common string processing is and how 
integrated auto-decoding is into D's string processing, it is 
very difficult to come up with a way to change it which isn't 
simply too disruptive to be justified, even though we want to 
change it. So, this is a particularly difficult case, and how 
we're going to end up handling it remains to be seen. Thus far, 
we've mainly worked on providing better ways to get around it, 
because we can do that without breaking code, whereas actually 
removing it is extremely difficult.


- Jonathan M Davis


It's aleady been said (by myself and others) that we should 
actually try to remove it (with a compiler switch) and then see 
what happens, how much code actually breaks, and based on that 
experience we can come up with a strategy. I've already said that 
I'm willing to try it on my code (that is almost 100% string 
processing). Why not _try_ it, later we can still philosophize

Re: Embedded Linux really needs Dlang for the IOT market

[Radu via Digitalmars-d]

On Friday, 9 March 2018 at 11:35:58 UTC, aberba wrote:

On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote:

On Friday, 9 March 2018 at 03:09:16 UTC, dangbinghoo wrote:

[...]


I'm working in BAS(Building Automation System) sector, and I 
use Dlang daily for some advance products targeting ARM/Mips 
boards.


D on Glibc/Linux/ARM works great today! It is well supported 
and getting LDC to cross-compile is as easy as those 100 and 
so words say! I'm using Ubuntu shell on Windows (WSL) and this 
makes things even more exciting. Actually the hardest part is 
getting the C cross tool-chain for your system, not LDC, I 
find this pretty amusing.


A tutorial or guide on "cross tool-chain for your system" will 
be very helpful. Say in ARM. Not that obvious to someone like 
me.




Recently I had to port the software to uClibc/Linux/ARM, hence 
my latest efforts on the port have followed with some patches 
for Druntime, Phobos and LDC. I think, minus 2 PRs, it is 
pretty close to complete. On my target system I've got it 
working including vibe.d.


Nice. Vibe.d sound great!! Especially for IoT stuff. Get some 
Pi to talk to APIs and services.




I suggest that you give it a try, and if you find issues 
contribute!


For LDC on ubuntu is is pretty straight forward

1. Get cross tools for ARM, let's say ARM HF (hardware floating 
point)



sudo apt-get install gcc-arm-linux-gnueabihf


2. Install LDC

3. Build cross libraries for LDC

From https://wiki.dlang.org/Building_LDC_runtime_libraries:


mkdir ldc-arm-linux-hf
cd ldc-arm-linux-hf
CC=arm-linux-gnueabihf-gcc ldc-build-runtime 
--dFlags="-w;-mtriple=arm-linux-gnueabihf" 
--targetSystem="Linux;UNIX"


Your cross compiled druntime and phobos libs will be the result 
of this step, they are located in the 
`/path/to/ldc-arm-linux-hf/lib` folder.


4. Compile your code

ldc2 -mtriple=arm-linux-gnueabihf -gcc=arm-linux-gnueabihf-gcc 
-L=-L/path/to/ldc-arm-linux-hf/lib awesome.d


You now have an linux arm hf binary that can run on your target 
device.

[Issue 18584] New: Undefined identifier when not specifying 'this'

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18584
   Summary: Undefined identifier when not specifying 'this'
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

This program gives the error message 'undefined identifier n':

struct S {
int n;
auto fun() { return tmp!(a => n)(); }
}

struct tmp(alias fns) {
alias fun = fns!int;
}

If you just add 'this', it works:

struct S {
int n;
auto fun() { return tmp!(a => this.n)(); }
}

struct tmp(alias fns) {
alias fun = fns!int;
}

There should be no ambiguity here as to which 'n' I'm referring to, and 'this'
should be unnecessary.

--

Re: How to fake a const method ?

[Basile B. via Digitalmars-d-learn]

On Friday, 9 March 2018 at 13:47:34 UTC, Basile B. wrote:

I would need this to work:

```
struct Foo
{
TypeInfo typeCache;

TypeInfo getTypeCache()
{
alias NotThePoint = ubyte;
if (typeCache is null)
typeCache = typeid(NotThePoint);
return typeCache;
}

TypeInfo type() const
{
alias NothrowType = TypeInfo delegate() const;
return (cast(NothrowType) )();
}
}

void main(){}
```

But get:

Error: mutable method `Foo.getTypeCache` is not callable using 
a `const` `this`



- `type()` really has to be const because it's used in an 
opEquals that's used by an AA (key is const so opEquals has to 
as well)
- `typeCache` is not used to compare 2 Foos so it really 
doesn't matter if it get assigned.


Solved...The error message helped much actually... problem is 
`this` is `const`


https://run.dlang.io/is/UOR2i2

Re: How to fake a const method ?

[Basile B. via Digitalmars-d-learn]

On Friday, 9 March 2018 at 13:54:07 UTC, Basile B. wrote:

On Friday, 9 March 2018 at 13:47:34 UTC, Basile B. wrote:
- `type()` really has to be const because it's used in an 
opEquals that's used by an AA (key is const so opEquals has to 
as well)


And the most annoying is that the non reduced Foo has a custom 
toHash that hashes a payload so the cast to const would really 
be perfectly valid.


Other annoying fact:

https://run.dlang.io/is/pmPSGr

It used to be accepted from 2.061 to 2.071.2

Re: complex arithmetic in D: multiple questions

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 9 March 2018 at 12:34:40 UTC, J-S Caux wrote:

Please bear with me, this is a long question!
To explain, I'm a scientist considering switching from C++ to 
D, but before I do, I need to ensure that I can:
- achieve execution speeds comparable to C++ (for the same 
accuracy; I can accept a slight slowdown, call it 30%, to get a 
few more digits (which I typically don't need))
- easily perform all standard mathematical operations on 
complex numbers
- (many other things not relevant here: memory use, 
parallelization, etc).


In the two files linked below, I compare execution 
speed/accuracy between D and C++ when using log on complex 
variables:


https://www.dropbox.com/s/hfw7nkwg25mk37u/test_cx.d?dl=0
https://www.dropbox.com/s/hfw7nkwg25mk37u/test_cx.d?dl=0

The idea is simple: let a complex variable be uniformly 
distributed around the unit circle. Summing the logs should 
give zero.


In the D code, I've defined an "own" version of the log, 
log_cx, since std.complex (tragically!) does not provide this 
function (and many others, see recent threads 
https://forum.dlang.org/post/dewzhtnpqkaqkzxwp...@forum.dlang.org and https://forum.dlang.org/thread/lsnuevdefktulxlto...@forum.dlang.org, and issue https://issues.dlang.org/show_bug.cgi?id=18571).


[snip]

So simple C++ is thrice as fast as the best-achieved D I 
managed.


Now for my questions:
- I would expect the D `Complex!double` case to work faster 
than the `real` one. Why is it the other way around? [I can 
accept (and use) D with Complex!real running 1/3 the speed of 
C++ (but with increased accuracy), but I'd also love to be able 
to run D with `Complex!double` at C++ speeds, since the 
tradeoff might be worth it for some calculations]


because the double version is doing the exact same work as the 
real
except that it is also converting between real and double for 
atan2 (from arg). 
https://github.com/dlang/phobos/blob/master/std/math.d#L1352


I'm really not sure why phobos does that, it should't.

- what is the best way to correct the unfortunate (to be 
polite) omission of many standard mathematical functions from 
std.complex? [if I may be frank, this is a real pain for us 
scientists] There exists 
https://gist.github.com/Biotronic/17af645c2c9b7913de1f04980cd22b37 but can this be integrated (after improvements) in the language, or should I (re)build my own?


It will be much faster to build your own that just forward to the 
C functions (or LLVM intrinsics) see 
https://github.com/libmir/mir-algorithm/blob/master/source/mir/math/common.d#L126 for a starting point (we'd greatly appreciate pull requests for anything missing).
Even if the decision to make std.math behave at the appropriate 
precision is accepted, it will still take an entire release cycle 
(unless you use dmd master), and I'm not so sure it will.


- for my education, why was the decision made to go from the 
built-in types `creal` etc to the `Complex` type?


I think because they can be done in the library.
I personally don't think they should have been, they don't 
complicate things that much.



[related questions:


Did you press send too soon?

Re: How to fake a const method ?

[Basile B. via Digitalmars-d-learn]

On Friday, 9 March 2018 at 13:47:34 UTC, Basile B. wrote:
- `type()` really has to be const because it's used in an 
opEquals that's used by an AA (key is const so opEquals has to 
as well)


And the most annoying is that the non reduced Foo has a custom 
toHash that hashes a payload so the cast to const would really be 
perfectly valid.

[vibe.d/dub] Linker error

[Chris via Digitalmars-d-learn]

I got this error msg today (see below):

DUB version 1.8.0, built on Mar  3 2018
vibe.d version 0.8.3
dmd 2.078.3 (the same with 2.079.0 and 2.077.0)

.dub/build/server64_72_debug-debug-linux.posix-x86_64-dmd_2079-CAC4A12AC8FE4B4625A9511E4EFEB8F6/anscealai.o:
 In function 
`_D3std5range10primitives__T5doPutTSQBh6format__T11hasToStringTSQCj8typecons__T5TupleTAysTmZQnTaZ9__lambda1MFZ1STaZQDjFNaNbNiNfKQDpaZv':
/usr/include/dlang/dmd/std/range/primitives.d:269: undefined 
reference to 
`_D3std6format__T11hasToStringTSQBd8typecons__T5TupleTAysTmZQnTaZ9__lambda1MFZ1S3putMFNaNbNiNfaZv' [...and loads of other similar messages...]

collect2: error: ld returned 1 exit status
Error: linker exited with status 1
/usr/bin/dmd failed with exit code 1.

It is so massive that it must be something ridiculous.

How to fake a const method ?

[Basile B. via Digitalmars-d-learn]

I would need this to work:

```
struct Foo
{
TypeInfo typeCache;

TypeInfo getTypeCache()
{
alias NotThePoint = ubyte;
if (typeCache is null)
typeCache = typeid(NotThePoint);
return typeCache;
}

TypeInfo type() const
{
alias NothrowType = TypeInfo delegate() const;
return (cast(NothrowType) )();
}
}

void main(){}
```

But get:

Error: mutable method `Foo.getTypeCache` is not callable using 
a `const` `this`



- `type()` really has to be const because it's used in an 
opEquals that's used by an AA (key is const so opEquals has to as 
well)
- `typeCache` is not used to compare 2 Foos so it really doesn't 
matter if it get assigned.

The New New DIP Process

[Mike Parker via Digitalmars-d-announce]

When I took on the role of DIP Manager last year, I didn't 
realize how much I had to learn. Most of the DIPs made it through 
just fine, but there were a few errors along the way. And there 
were some inefficiencies built into the system that weren't so 
obvious in the beginning. Recently, my new procedure document to 
revise the process was approved.


Structurally, the process is still the same. Now, it has more 
clearly defined responsibilities and time constraints. Hopefully, 
this will kill the inefficiencies we identified in the system, 
and I'll keep an eye open to adapting it as necessary.


This blog post summarizes the changes, their motivation, and my 
new attitude toward the role of the DIP Manager.


Blog:
https://dlang.org/blog/2018/03/09/the-new-new-dip-process/

Reddit:
https://www.reddit.com/r/d_language/comments/836fwt/the_new_new_dip_process/

Re: Embedded Linux really needs Dlang for the IOT market

[Binghoo Dang via Digitalmars-d]

On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote:

[...]


I'm working in BAS(Building Automation System) sector, and I 
use Dlang daily for some advance products targeting ARM/Mips 
boards.


[...]


That's great, it looks that what I need to do is just try! And, I 
would write a paper after I get everything working. thanks!

Re: Embedded Linux really needs Dlang for the IOT market

[Binghoo Dang via Digitalmars-d]

On Friday, 9 March 2018 at 07:56:12 UTC, Jacob Carlborg wrote:

[...]

straightforward to adopt it to targeting ARM.

[1] https://hub.docker.com/r/multiarch/crossbuild
[2] 
https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile


--
/Jacob Carlborg


thanks for sharing!

[Issue 18583] Wrong symbol in error message

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Simen Kjaeraas  ---
Further simplified:

struct S {
int n;
enum t = tmp!n;
}

string tmp(alias T)() { return ""; }

It seems tmp has to be a function template - reducing it to `enum tmp(alias T)
= 1;` removes the error message.

--

complex arithmetic in D: multiple questions

[J-S Caux via Digitalmars-d-learn]

Please bear with me, this is a long question!
To explain, I'm a scientist considering switching from C++ to D, 
but before I do, I need to ensure that I can:
- achieve execution speeds comparable to C++ (for the same 
accuracy; I can accept a slight slowdown, call it 30%, to get a 
few more digits (which I typically don't need))
- easily perform all standard mathematical operations on complex 
numbers
- (many other things not relevant here: memory use, 
parallelization, etc).


In the two files linked below, I compare execution speed/accuracy 
between D and C++ when using log on complex variables:


https://www.dropbox.com/s/hfw7nkwg25mk37u/test_cx.d?dl=0
https://www.dropbox.com/s/hfw7nkwg25mk37u/test_cx.d?dl=0

The idea is simple: let a complex variable be uniformly 
distributed around the unit circle. Summing the logs should give 
zero.


In the D code, I've defined an "own" version of the log, log_cx, 
since std.complex (tragically!) does not provide this function 
(and many others, see recent threads 
https://forum.dlang.org/post/dewzhtnpqkaqkzxwp...@forum.dlang.org 
and 
https://forum.dlang.org/thread/lsnuevdefktulxlto...@forum.dlang.org, and issue https://issues.dlang.org/show_bug.cgi?id=18571).


First, speed/accuracy (times for 1M points in all cases):
D:
dmd, no flags:
Complex!real: re, im (should be 0): 
-9.24759400999786151942e-15	6.26324079407839123978e-14

time for 100 pts: 190 ms, 508 μs, and 9 hnsecs
Complex!double: re, im (should be 0): 
-1.96986871259241524967e-12	5.46260919029144254022e-09

time for 100 pts: 455 ms, 888 μs, and 7 hnsecs

dmd -release -inline -O:
Complex!real: re, im (should be 0): 
-9.24759400999786151942e-15	6.26324079407839123978e-14

time for 100 pts: 175 ms, 352 μs, and 3 hnsecs
Complex!double: re, im (should be 0): 
-4.23880765557105362133e-14	5.46260919029144254022e-09

time for 100 pts: 402 ms, 965 μs, and 7 hnsecs

ldc2, no flags:
Complex!real: re, im (should be 0): 
-9.24759400999786151942e-15	6.26324079407839123978e-14

time for 100 pts: 184 ms, 353 μs, and 9 hnsecs
Complex!double: re, im (should be 0): 
-1.96986871259241524967e-12	5.46260919029144254022e-09

time for 100 pts: 436 ms, 526 μs, and 8 hnsecs

ldc2 -release -O:
Complex!real: re, im (should be 0): 
-9.24759400999786151942e-15	6.26324079407839123978e-14

time for 100 pts: 108 ms and 966 μs
Complex!double: re, im (should be 0): 
-1.96986871259241524967e-12	5.46260919029144254022e-09

time for 100 pts: 330 ms, 421 μs, and 8 hnsecs

As expected accuracy with Complex!real is about 4 digits better, 
and the best combo is ldc2 with flags.


Now C++:
GCC 7.1.0, -O3:
complex: re, im (should be 0): 
(8.788326118779445e-13,1.433519814600731e-11)

time for 100 pts: 0.042751 seconds.

Apple LLVM version 9.0.0 (clang-900.0.39.2), -O3:
complex: re, im (should be 0): 
(-3.0160318686967e-12,1.433519814600731e-11)

time for 100 pts: 0.038715 seconds.

So simple C++ is thrice as fast as the best-achieved D I managed.

Now for my questions:
- I would expect the D `Complex!double` case to work faster than 
the `real` one. Why is it the other way around? [I can accept 
(and use) D with Complex!real running 1/3 the speed of C++ (but 
with increased accuracy), but I'd also love to be able to run D 
with `Complex!double` at C++ speeds, since the tradeoff might be 
worth it for some calculations]
- what is the best way to correct the unfortunate (to be polite) 
omission of many standard mathematical functions from 
std.complex? [if I may be frank, this is a real pain for us 
scientists] There exists 
https://gist.github.com/Biotronic/17af645c2c9b7913de1f04980cd22b37 but can this be integrated (after improvements) in the language, or should I (re)build my own?
- for my education, why was the decision made to go from the 
built-in types `creal` etc to the `Complex` type?


[related questions:

Re: Why not flag away the mistakes of the past?

[Gary Willoughby via Digitalmars-d]

On Wednesday, 7 March 2018 at 17:11:55 UTC, H. S. Teoh wrote:

Kill autodecoding, I say. Kill it with fire!!


T


Please!!!

[Issue 18583] New: Wrong symbol in error message

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18583
   Summary: Wrong symbol in error message
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

struct S {
int n;
enum t = tmp!(a => n);
}

string tmp(alias T)() { return ""; }

foo.d(6): Error: function foo.S.tmp!((a) => n).tmp need 'this' to access member
tmp
foo.d(3):called from here: tmp()

Notice that the error message claims tmp needs 'this' to access itself. Surely
the latter should say 'member n' instead.

--

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

[d-bugmail--- via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Mathias Lang  ---
This is wrong. Gratuitously breaking code is not okay, especially when this
code could be working correctly, even if some safety checks were not performed.

This should not be considered in the context of a single codebase, but in the
context of the whole ecosystem: if you break code that is working in a library
that many depends on, a user won't care if the language is better as [s]he is
not able to use it.

I raised an objection on the PR about it being an reject-valid, but Walter
rightly pointed out that the reasoning is the same:
https://github.com/dlang/dmd/pull/7981#issuecomment-370570068

--

Re: Released vibe.d 0.8.3

[Martin Tschierschke via Digitalmars-d-announce]

On Friday, 9 March 2018 at 10:07:28 UTC, Sönke Ludwig wrote:
[...]

Additionally, DMD 2.079.0 is finally supported,

[...]

"...write fast, read fast, and run fast.

Fast code, fast."

Thank you!

Re: Why not flag away the mistakes of the past?

[Guillaume Piolat via Digitalmars-d]

On Thursday, 8 March 2018 at 17:35:11 UTC, H. S. Teoh wrote:
Yeah, the only reason autodecoding survived in the beginning 
was because Andrei (wrongly) thought that a Unicode code point 
was equivalent to a grapheme.  If that had been the case, the 
cost associated with auto-decoding may have been justifiable.  
Unfortunately, that is not the case, which greatly diminishes 
most of the advantages that autodecoding was meant to have.  So 
it ended up being something that incurred a significant 
performance hit, yet did not offer the advantages it was 
supposed to.  To fully live up to Andrei's original vision, it 
would have to include grapheme segmentation as well.  
Unfortunately, graphemes are of arbitrary length and cannot in 
general fit in a single dchar (or any fixed-size type), and 
grapheme segmentation is extremely costly to compute, so doing 
it by default would kill D's string manipulation performance.



I remember something a bit different last time it was discussed:

 - removing auto-decoding was breaking a lot of code, it's used 
in lots of place

 - performance loss could be mitigated with .byCodeUnit everytime
 - Andrei correctly advocating against breakage

Personally I do use auto-decoding, often iterating by codepoint, 
and uses it for fonts and parsers. It's correct for a large 
subset of languages. You gave us a feature and now we are using 
it ;)

Re: Advent of D

[Russel Winder via Digitalmars-d]

On Thu, 2018-03-08 at 21:00 +, Jordi Gutiérrez Hermoso via
Digitalmars-d wrote:
> On Wednesday, 7 March 2018 at 21:35:06 UTC, Russel Winder wrote:
> > On Tue, 2018-03-06 at 18:09 +, Jordi Gutiérrez Hermoso via 
> > Digitalmars-d wrote:
> > > I wrote a blog post about working on Advent of Code in D. You 
> > > can read it here:
> > > 
> > > http://jordi.inversethought.com/blog/advent-of-d/
> > 
> > Another blog post deserving of formal publication in an ACCU 
> > journal.
> 
> Hm, I quickly looked at what that is. Some sort of informal 
> journal? You think if I adapted the blog post for a print 
> publication, they would take it?

The journals take a mix of articles written for the journal and blog
posts adapted for the journal. So yes.

I have taken the liberty of cc-ing the editors of the two journals so
as to make the connection.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

[Issue 9983] inout type can not be used as a parameter for structure template

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from anonymous4  ---
Looks like it can be solved by smart enough container constructors.
See this quick PoC:
---
struct Container(T)
{
T value;
inout(T) get() inout
{
return value;
}
}

/// Smart constructor
auto makeContainer(T)(T arg)
{
alias E=typeof(cast()arg[0]);
static if(is(T==inout(E)[]))
{
return inout(Container!(E[]))(arg);
}
else
{
return Container!T(arg);
}
}

auto f(inout int[] a)
{
return makeContainer(a);
}

void g(immutable int[] a)
{
auto b=f(a);
immutable Container!(int[]) c=b;
immutable int[] d=c.get;
immutable int[] e=b.get;
//static assert(false,typeof(b).stringof);
}

void g(int[] a)
{
auto b=f(a);
Container!(int[]) c=b;
int[] d=c.get;
int[] e=b.get;
//static assert(false,typeof(b).stringof);
}
---

--

Re: Embedded Linux really needs Dlang for the IOT market

[aberba via Digitalmars-d]

On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote:

On Friday, 9 March 2018 at 03:09:16 UTC, dangbinghoo wrote:

[...]


I'm working in BAS(Building Automation System) sector, and I 
use Dlang daily for some advance products targeting ARM/Mips 
boards.


D on Glibc/Linux/ARM works great today! It is well supported 
and getting LDC to cross-compile is as easy as those 100 and so 
words say! I'm using Ubuntu shell on Windows (WSL) and this 
makes things even more exciting. Actually the hardest part is 
getting the C cross tool-chain for your system, not LDC, I find 
this pretty amusing.


A tutorial or guide on "cross tool-chain for your system" will be 
very helpful. Say in ARM. Not that obvious to someone like me.




Recently I had to port the software to uClibc/Linux/ARM, hence 
my latest efforts on the port have followed with some patches 
for Druntime, Phobos and LDC. I think, minus 2 PRs, it is 
pretty close to complete. On my target system I've got it 
working including vibe.d.


Nice. Vibe.d sound great!! Especially for IoT stuff. Get some Pi 
to talk to APIs and services.




I suggest that you give it a try, and if you find issues 
contribute!

[Issue 18561] postblit should allow writing const/immutable members just like constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from anonymous4  ---
(In reply to Steven Schveighoffer from comment #2)
> This does not address postblits being called on const data types (with
> `this` being mutable during the postblit). That is a different bug.
I thought you meant this. As you can see const constructor can be already
called on const data, ability to call const postblit wouldn't be different.

--

Re: Released vibe.d 0.8.3

[aberba via Digitalmars-d-announce]

On Friday, 9 March 2018 at 10:07:28 UTC, Sönke Ludwig wrote:
The deprecation phase of the legacy "vibe-d:core" module starts 
with this release by defaulting to the new "vibe-core" package. 
Additionally, DMD 2.079.0 is finally supported, and some 
notable improvements have been made to the HTTP implementation. 
URLRouter in particular has received memory optimizations (to 
avoid fragmentation) that can result in a heavy reduction of 
memory use.


See the change log for instructions to opt for the legacy 
vibe-d:core module in case of any issues with vibe-core.


Change log:
https://vibed.org/blog/posts/vibe-release-0.8.3

DUB package:
https://code.dlang.org/packages/vibe-d/0.8.3


Congrats!

Re: Released vibe.d 0.8.3

[bauss via Digitalmars-d-announce]

On Friday, 9 March 2018 at 10:07:28 UTC, Sönke Ludwig wrote:
The deprecation phase of the legacy "vibe-d:core" module starts 
with this release by defaulting to the new "vibe-core" package. 
Additionally, DMD 2.079.0 is finally supported, and some 
notable improvements have been made to the HTTP implementation. 
URLRouter in particular has received memory optimizations (to 
avoid fragmentation) that can result in a heavy reduction of 
memory use.


See the change log for instructions to opt for the legacy 
vibe-d:core module in case of any issues with vibe-core.


Change log:
https://vibed.org/blog/posts/vibe-release-0.8.3

DUB package:
https://code.dlang.org/packages/vibe-d/0.8.3


Great news. Good job!

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords|safe|
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from anonymous4  ---
Should work the same is @system code; "don't break working code" only applies
to valid code; if code advertizes scoping, but doesn't respect it, it's invalid
and there shouldn't be any guarantee for it to work.

--