post 2.071 mixin template & import rules

[captaindet via Digitalmars-d]

the way import declarations work has changed quite a bit with 2.071. two 
aspects have been written up nicely by steve schveighoffer ( 
http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071 ). 
breaking as they might be for some, they are (a) a mere enforcement of 
the rules as they were always set out and (b) a change in look-up order 
preventing hijacking/overshadowing.


it appears that there had been an even more radical change as well with 
respect to the way mixin templates work. this has not been properly 
communicated yet. at least i could not find a write-up and a related 
thread conveyed rather guesswork than knowledge. ( 
https://forum.dlang.org/post/nl2bgi$2oim$1...@digitalmars.com )


from this thread i tried to distill the gist below... so that if my 
understanding is confirmed by the language devs, it may serve as an 
explanation of changes complementary to steve's blog post.




mixin templates - https://dlang.org/spec/template-mixin.html :
"A TemplateMixin takes an arbitrary set of declarations from the body of 
a TemplateDeclaration and inserts them into the current context."


as of the the specs https://dlang.org/spec/module.html imports are 
declarations too and before 2.071 the mixin template design spec above 
would work for them just the same. as in:


```
mixin template AddImp (){
import core.thread;
}
mixin AddImp;
```

this would import core.thread just alright into the current scope. 
regardless where the instantiation happens, module level as well as 
within classes etc. (note that the mixin template definition can be in 
another module and itself be constructed by more mixin templates or 
string mixins.)


especially if

```
module a;
mixin template AddImp (){
public import core.thread;
}
```

and

```
module b;
mixin AddImp;
```

ie on module level, then in module b core.thread as a whole would be 
visible/accessible/imported.


apparently starting with 2.071 import declarations are not treated as 
declarations in the sense of mixin templates anymore. meaning that whole 
module imports (private and public) in mixin template definitions are 
not inserted into the instantiating scope anymore. neither if 
instantiated on module level, nor if in a class etc. it is not that the 
look-up order has changed for them, they are blatantly ignored now.


(and this is what i am not happy with it. it would be more consisting if 
the imports would be inserted in the current scope just as they were 
before but with the local definitions having precedence - similar to how 
issue 10378 was fixed - just as it would be if you actually wrote 
"import core.thread;" instead of "mixin AddImp;" also, it would not 
leave me with a ton of code that needs rewriting.)


on the other hand, if not a whole module is imported but individual 
symbols via selective import, it still works the same as before. eg:


```
module a;
mixin template AddImp (){
public import core.thread : Thread;
}
```

and

```
module b;
mixin AddImp;
```

will make Thread available in all of module b.



please correct my view of things if i got it wrong.

thanks

/det

Re: Gravatar is blocked by GFW

[mogu via Digitalmars-d]

On Friday, 1 July 2016 at 01:43:40 UTC, Seb wrote:

On Thursday, 30 June 2016 at 23:49:16 UTC, mogu wrote:
Could dlang.org filter IP addresses from China and use another 
gravatar mirrors? Here's one solution:

https://wordpress.org/plugins/wp-duoshuo-gravatar/

Now I have to always open the VPN to access the forum. This 
may blocks many people interested in D from China. Please help.


Have a look at web.d in DFeed, maybe you can tweak it to 
support alternative providers?


https://github.com/CyberShadow/DFeed/blob/master/web.d#L1243

(otherwise this repo is probably the best place to report 
issues)


I do not know anything about web. I'll report an issue.

Re: Gravatar is blocked by GFW

[mogu via Digitalmars-d]

On Friday, 1 July 2016 at 01:35:51 UTC, Jack Stouffer wrote:

On Thursday, 30 June 2016 at 23:49:16 UTC, mogu wrote:
Could dlang.org filter IP addresses from China and use another 
gravatar mirrors? Here's one solution:

https://wordpress.org/plugins/wp-duoshuo-gravatar/

Now I have to always open the VPN to access the forum. This 
may blocks many people interested in D from China. Please help.


Does this cause the entire forum to be blocked or just the 
profile pictures?


Profile pictures. Homepage of dlang.org also has gravatar 
resources. So always loading.

Re: daffodil, a D image processing library

[ketmar via Digitalmars-d-announce]

On Friday, 1 July 2016 at 01:47:44 UTC, Jack Stouffer wrote:

Way to be a dismissive asshole.


why so serious? it is clearly a joke.

Re: daffodil, a D image processing library

[ketmar via Digitalmars-d-announce]

On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:

Doesn't use allocators

great library! definitely worth a closer look.

Re: daffodil, a D image processing library

[rikki cattermole via Digitalmars-d-announce]

On 01/07/2016 1:47 PM, Jack Stouffer wrote:

On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:

Doesn't use allocators or Manu's color work, yup yup not interested.


Way to be a dismissive asshole.

Let me rewrite that sentence for you:

"Hey, nice work, we really need something like this. I'm a bit concerned
about the GC usage though, have you checked out std.allocators or the
proposed std.color? I think these will help make your library much faster."


I thought I was being quite lighthearted really given how many different 
implementations there are these days.

If the author would like me to apologize I will.

Re: daffodil, a D image processing library

[Jack Stouffer via Digitalmars-d-announce]

On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
Doesn't use allocators or Manu's color work, yup yup not 
interested.


Way to be a dismissive asshole.

Let me rewrite that sentence for you:

"Hey, nice work, we really need something like this. I'm a bit 
concerned about the GC usage though, have you checked out 
std.allocators or the proposed std.color? I think these will help 
make your library much faster."

Re: Gravatar is blocked by GFW

[Seb via Digitalmars-d]

On Thursday, 30 June 2016 at 23:49:16 UTC, mogu wrote:
Could dlang.org filter IP addresses from China and use another 
gravatar mirrors? Here's one solution:

https://wordpress.org/plugins/wp-duoshuo-gravatar/

Now I have to always open the VPN to access the forum. This may 
blocks many people interested in D from China. Please help.


Have a look at web.d in DFeed, maybe you can tweak it to support 
alternative providers?


https://github.com/CyberShadow/DFeed/blob/master/web.d#L1243

(otherwise this repo is probably the best place to report issues)

Re: Gravatar is blocked by GFW

[Jack Stouffer via Digitalmars-d]

On Thursday, 30 June 2016 at 23:49:16 UTC, mogu wrote:
Could dlang.org filter IP addresses from China and use another 
gravatar mirrors? Here's one solution:

https://wordpress.org/plugins/wp-duoshuo-gravatar/

Now I have to always open the VPN to access the forum. This may 
blocks many people interested in D from China. Please help.


Does this cause the entire forum to be blocked or just the 
profile pictures?

Re: daffodil, a D image processing library

[rikki cattermole via Digitalmars-d-announce]

On 01/07/2016 9:35 AM, Benjamin Schaaf wrote:

daffodil is a image processing library inspired by python's Pillow
(https://pillow.readthedocs.org/). It is an attempt at designing a
clean, extensible and transparent API.

https://github.com/BenjaminSchaaf/daffodil
https://benjaminschaaf.github.io/daffodil/

The library makes full use out of D's templates and metaprogramming. The
internal storage mechanism is entirely configurable from almost every
endpoint. File headers are directly loaded into structs defining them,
removing most of the difficulties in reading them according to spec. The
image type and loading API is entirely extensible, making extra image
formats entirely self-contained.

Currently only loading and saving of simple BMP images is supported,
with convolution and Gaussian Blur filters and flip transformations. Its
still early in development, but I'd love to get some feedback on it.

Example:
---
import daffodil;
import daffodil.filter;
import daffodil.transform;

void main() {
auto image = load!32("daffodil.bmp");

image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");

image.flipped!"y".save("upside_down_daffodil.bmp");
}
---

The license is MIT, so feel free to do whatever you want with the code.
Issues and pull requests are of course welcome ;)

Alongside I've also written (an admittedly hacky) sphinx
(http://www.sphinx-doc.org/en/stable/) extension that provides a domain
and autodocumenter for D, using libdparse and pyd.


Doesn't use allocators or Manu's color work, yup yup not interested.

Re: Tuple fields/types

[Meta via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 21:53:42 UTC, Jordan Wilson wrote:

Hello,

For tuples, does the fieldNames property have a 1-1 
correspondence with the Types property?


It appears that way in my testing:

alias MyData = Tuple!(string,"a",int,"b");
foreach (i, type; MyData.Types){
writeln (MyData.fieldNames[i]," ",type.stringof);
// a string
// b int
}

But I can't figure out for sure from the documentation:

alias fieldNames = staticMap!(extractName, fieldSpecs);
alias Types = staticMap!(extractType, fieldSpecs);

Thanks,

Jordan


It's an implementation detail but I wouldn't expect the order to 
ever change.

Re: Google's code ownership

[sarn via Digitalmars-d]

On Wednesday, 29 June 2016 at 22:35:03 UTC, qznc wrote:

However, I'm not sure if "finding reviewers" is the bottleneck?


Not everything applies because Google doesn't host its repo on 
Github (obviously), but code ownership works very well there.  It 
helps avoid the bystander effect, and encourages casual 
contributors (like bugfixers) because they know they have a 
specific person to ping.  As long as code ownership is a position 
of responsibility, not power, I think it's a good idea for most 
large software projects.

Re: front stability

[Steven Schveighoffer via Digitalmars-d]

On 6/30/16 7:50 PM, Walter Bright wrote:

On 6/2/2016 5:51 AM, Steven Schveighoffer wrote:

I have always treated ranges with this expectation:

1. front gets you the current element of the range. Calling front
multiple times
without calling popFront should get you the same value.
2. popFront moves you to the next element of the range if it exists.


Right. Also:

3. empty can be called multiple times in a row, and must always return
the same result.
4. it is not legal to call front() on an empty range, but it is not
required to call empty() first
5. it is not legal to call popFront() on an empty range, but it is not
required to call empty() or front() first.


Jack, can you update the rules to reflect this?


I'd say violating the expectations of what popFront and front do is more
egregious than a particular use case, no matter how valid that case
is. I'd like
to fix this bug, but I see there were quite a few major D contributors
in the
camp that wanted this function to behave the way it is. So I'd rather
first
debate the merits here.


This was debated at length in the past. The result was the rules above.
Ranges that do not follow those rules need to be fixed. I don't think
there's a need to debate it again.


Thank you, I will set up a PR to fix generate.

-Steve

Re: Tuple fields/types

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 21:53:42 UTC, Jordan Wilson wrote:

Hello,

For tuples, does the fieldNames property have a 1-1 
correspondence with the Types property?


It appears that way in my testing:

alias MyData = Tuple!(string,"a",int,"b");
foreach (i, type; MyData.Types){
writeln (MyData.fieldNames[i]," ",type.stringof);
// a string
// b int
}

But I can't figure out for sure from the documentation:

alias fieldNames = staticMap!(extractName, fieldSpecs);
alias Types = staticMap!(extractType, fieldSpecs);

Thanks,

Jordan


static map (and map in general) is a 1:1 correspondence, so yes.

Re: Blocking points for further D adoption

[dalailambda via Digitalmars-d]

On Thursday, 30 June 2016 at 23:48:29 UTC, Mike Parker wrote:
DMD *is* the official compiler. That's what a reference 
compiler is. The other compilers are there for those who want 
them and are developed independently of DMD. It's no different 
from the situation with Java (with the exception that Oracle 
doesn't link to other compilers on their JDK download page). No 
one says you *have* to use LDC or GDC for production, or that 
you can't use DMD. It's just as a recommendation for those who 
care about squeezing out every last drop of performance.


Sure, but overwhelmingly the community suggests to use DMD for 
development for fast compilation speeds and then use LDC/GDC for 
production. I'm not saying that the law mandates it but the 
impression I get as a newcommer to the community is that DMD is 
the ugly stepchild that isn't suitable for real world use case.


As an example, look at whenever a benchmark comes up, someone 
will say "have you tried compiling with LDC?". I feel the is 
relevant since, as a systems language, performance should be a 
feature.

Re: front stability

[Walter Bright via Digitalmars-d]

On 6/30/2016 8:32 AM, Steven Schveighoffer wrote:

This doesn't solve it, and it can't be solved -- halting problem. We have some
expectations that are assumed and some that are mechanically tested. This PR
clarifies the assumptions.


I made some range drivers that brutally test the protocol:

http://www.digitalmars.com/sargon/asinputrange.html
http://www.digitalmars.com/sargon/asforwardrange.html

I think they should be part of Phobos.

Re: front stability

[Walter Bright via Digitalmars-d]

On 6/2/2016 8:21 AM, deadalnix wrote:

I opened some bugs about that in the past, but got shut down. It is especially
problematic since some ranges (like filter) are calling front several time when
iterating.


Please reopen them.

Re: Blocking points for further D adoption

[Mike Parker via Digitalmars-d]

On Thursday, 30 June 2016 at 23:48:29 UTC, Mike Parker wrote:

On Thursday, 30 June 2016 at 22:48:44 UTC, dalailambda wrote:

I think if dub were distributed with DMD, along with a utility 
to install global programs (that way a D plugin can just call 
`dub install workspace-d` or similar), it would make it very 
easy to get started with D.


DUB only recently hit 1.0. Now that it has, it is planned to 
begin bundling it with DMD.


Oh, and I forgot to add that DUB is not intended generally 
intended as a package installer. That said, you've got 'dub fetch 
package-name' already, which will pull a package down into the 
cache. If it's an executable, you can then do 'dub run 
package-name'.

Re: front stability

[Walter Bright via Digitalmars-d]

On 6/2/2016 5:51 AM, Steven Schveighoffer wrote:

I have always treated ranges with this expectation:

1. front gets you the current element of the range. Calling front multiple times
without calling popFront should get you the same value.
2. popFront moves you to the next element of the range if it exists.


Right. Also:

3. empty can be called multiple times in a row, and must always return the same 
result.
4. it is not legal to call front() on an empty range, but it is not required to 
call empty() first
5. it is not legal to call popFront() on an empty range, but it is not required 
to call empty() or front() first.



I'd say violating the expectations of what popFront and front do is more
egregious than a particular use case, no matter how valid that case is. I'd like
to fix this bug, but I see there were quite a few major D contributors in the
camp that wanted this function to behave the way it is. So I'd rather first
debate the merits here.


This was debated at length in the past. The result was the rules above. Ranges 
that do not follow those rules need to be fixed. I don't think there's a need to 
debate it again.

Gravatar is blocked by GFW

[mogu via Digitalmars-d]

Could dlang.org filter IP addresses from China and use another 
gravatar mirrors? Here's one solution:

https://wordpress.org/plugins/wp-duoshuo-gravatar/

Now I have to always open the VPN to access the forum. This may 
blocks many people interested in D from China. Please help.

Re: Blocking points for further D adoption

[Mike Parker via Digitalmars-d]

On Thursday, 30 June 2016 at 22:48:44 UTC, dalailambda wrote:

I think if dub were distributed with DMD, along with a utility 
to install global programs (that way a D plugin can just call 
`dub install workspace-d` or similar), it would make it very 
easy to get started with D.


DUB only recently hit 1.0. Now that it has, it is planned to 
begin bundling it with DMD.




[0] As much as the "reference compiler vs faster compiler" 
distinction, I feel like languages that have a single official 
compiler that you can use for development and production (e.g. 
Go/Rust) are much friendlier.


DMD *is* the official compiler. That's what a reference compiler 
is. The other compilers are there for those who want them and are 
developed independently of DMD. It's no different from the 
situation with Java (with the exception that Oracle doesn't link 
to other compilers on their JDK download page). No one says you 
*have* to use LDC or GDC for production, or that you can't use 
DMD. It's just as a recommendation for those who care about 
squeezing out every last drop of performance.

[Issue 15191] DIP25: Taking address of ref return is not type checked soundly

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/7e057ad1a5dfb86b3cc2d3ba7167c44c053c0253
fix Issue 15191 - DIP25: Taking address of ref return is not type checked
soundly

https://github.com/dlang/dmd/commit/c9e42913421dcaf1b7202a91b237b598b3600d48
Merge pull request #5892 from WalterBright/fix15191

fix Issue 15191 - DIP25: Taking address of ref return is not type che…

--

[Issue 15191] DIP25: Taking address of ref return is not type checked soundly

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Does a Interpretation-Engine fit in phobos ?

[lobo via Digitalmars-d]

On Thursday, 30 June 2016 at 11:09:10 UTC, ketmar wrote:

On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
Off-topic: Is it possible/feasible/desirable to let dmd use 
dub packages?


please, no. not everybody out there is dub fan.


You can always use dub to fetch packages into ~/.dub/packages and 
build them. The artifacts are then available for whatever build 
system you choose for your own project.


I don't use DUB for my own projects because it drops garbage all 
through my source tree. The day it can do out of source builds is 
the day I'll revisit the DUB bazaar.



bye,
lobo

Re: front stability

[Jesse Phillips via Digitalmars-d]

On Thursday, 2 June 2016 at 12:51:18 UTC, Steven Schveighoffer 
wrote:
The counter-argument seems to be that if you cache the front 
element, then then making a copy of the range via take can 
repeat the cached element[4]. I find this argument severely 
lacking -- non-forward ranges are not meant to be copied and 
expected to operate properly, it's why we require calling save.


[4] 
https://github.com/dlang/phobos/pull/2606#issuecomment-58740715


I think front returning the same value every time is the 
appropriate behavior for every range (I've had many times I wish 
this weren't true so I wouldn't have to implement caching).


Map is no different, yes the function could technically change 
each time front is called, but that is an issue in the user code 
and not the implementation of map (map should only accept pure 
functions :))


I think the example of take() is a valid criticism. It is the 
issue of value ranges vs reference ranges all over again. Due to 
these distinct range types, providing a range to a function 
invalidates that range within the scope. It is not possible to 
know if the range will start at the same spot prior to calling 
function or if it will start after. In the case generator, we see 
a hybrid which isn't the only range that will do front() caching.


Practically we don't run into issues with undefined behavior in 
our code, probably because we don't change out the type of range 
being used very often. I don't have a solution for this problem, 
but think having generator() add a new uncertainty (does calling 
front() a second time advance my range?) is a very bad precedence 
to set in Phobos.

Re: Blocking points for further D adoption

[dalailambda via Digitalmars-d]

As someone who has recently chosen D for a major project (a 
game/engine), I can confidently say that the biggest distinction 
for me between getting start with D versus something like Go is 
developer tooling. For Go I installed Go, installed a go intellij 
plugin, which automatically installed gocode and I was up and 
running. For D I had to install DMD (and learn about all the 
different compilers)[0], install dub, install workspace-d, 
install visual studio code (because the visual studio plugin had 
a linking error), and then I could finally have a complete setup.


I think if dub were distributed with DMD, along with a utility to 
install global programs (that way a D plugin can just call `dub 
install workspace-d` or similar), it would make it very easy to 
get started with D.


For reference, Cargo (Rust's package manager) allows `cargo 
install` 
https://github.com/rust-lang/rfcs/blob/master/text/1200-cargo-install.md


[0] As much as the "reference compiler vs faster compiler" 
distinction, I feel like languages that have a single official 
compiler that you can use for development and production (e.g. 
Go/Rust) are much friendlier.

Re: GTKD - CSS class color "flash" delay

[TheDGuy via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 20:11:17 UTC, Mike Wey wrote:

Is the complete source available some ware?


Yes, here: http://pastebin.com/h0Nx1mL6

Re: Call to Action: making Phobos @safe

[Seb via Digitalmars-d]

On Thursday, 30 June 2016 at 21:31:25 UTC, Walter Bright wrote:

On 6/30/2016 11:54 AM, Bennet Leff wrote:
On Sunday, 26 June 2016 at 13:13:01 UTC, Robert burner Schadek 
wrote:
It would be awesome if you would create that process model in 
the wiki and at

it to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List

So it does not get lost and people can find it.


Could you elaborate on list option 9 "create a module that 
enables code to be
run on GPU." Wouldn't the Derelict OpenCL bindings satisfy 
that need?


I don't know. John Colvin is working on this, he could give a 
far better appraisal of the state.


Some pointers:

https://github.com/John-Colvin/clWrap
http://dconf.org/2016/talks/colvin.html

Get program stats at run time

[Special opOps via Digitalmars-d-learn]

How can I get the program stats at run time such as minimum and 
maximum amount of memory and cpu used, cpu architecture, os, etc?

Tuple fields/types

[Jordan Wilson via Digitalmars-d-learn]

Hello,

For tuples, does the fieldNames property have a 1-1 
correspondence with the Types property?


It appears that way in my testing:

alias MyData = Tuple!(string,"a",int,"b");
foreach (i, type; MyData.Types){
writeln (MyData.fieldNames[i]," ",type.stringof);
// a string
// b int
}

But I can't figure out for sure from the documentation:

alias fieldNames = staticMap!(extractName, fieldSpecs);
alias Types = staticMap!(extractType, fieldSpecs);

Thanks,

Jordan

daffodil, a D image processing library

[Benjamin Schaaf via Digitalmars-d-announce]

daffodil is a image processing library inspired by python's 
Pillow (https://pillow.readthedocs.org/). It is an attempt at 
designing a clean, extensible and transparent API.


https://github.com/BenjaminSchaaf/daffodil
https://benjaminschaaf.github.io/daffodil/

The library makes full use out of D's templates and 
metaprogramming. The internal storage mechanism is entirely 
configurable from almost every endpoint. File headers are 
directly loaded into structs defining them, removing most of the 
difficulties in reading them according to spec. The image type 
and loading API is entirely extensible, making extra image 
formats entirely self-contained.


Currently only loading and saving of simple BMP images is 
supported, with convolution and Gaussian Blur filters and flip 
transformations. Its still early in development, but I'd love to 
get some feedback on it.


Example:
---
import daffodil;
import daffodil.filter;
import daffodil.transform;

void main() {
auto image = load!32("daffodil.bmp");

image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");

image.flipped!"y".save("upside_down_daffodil.bmp");
}
---

The license is MIT, so feel free to do whatever you want with the 
code. Issues and pull requests are of course welcome ;)


Alongside I've also written (an admittedly hacky) sphinx 
(http://www.sphinx-doc.org/en/stable/) extension that provides a 
domain and autodocumenter for D, using libdparse and pyd.

Re: Ocean preview finally open sourced

[Chris via Digitalmars-d-announce]

On Thursday, 30 June 2016 at 21:20:16 UTC, Leandro Lucarella 
wrote:


I'd say some parts should work out of the box (there many 
things that are completely OS agnostic, like containers, cache, 
bindings to other libraries like PCRE, etc.), and some other it 
would be quite some work (for example all the I/O is tied to 
epoll, there is one class to work with direct I/O that's super 
Linux specific, etc.).


Hm. I'd have to see what works. I can't afford to be stuck to one 
OS.

Re: Call to Action: making Phobos @safe

[Walter Bright via Digitalmars-d]

On 6/30/2016 11:54 AM, Bennet Leff wrote:

On Sunday, 26 June 2016 at 13:13:01 UTC, Robert burner Schadek wrote:

It would be awesome if you would create that process model in the wiki and at
it to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List

So it does not get lost and people can find it.


Could you elaborate on list option 9 "create a module that enables code to be
run on GPU." Wouldn't the Derelict OpenCL bindings satisfy that need?


I don't know. John Colvin is working on this, he could give a far better 
appraisal of the state.

Re: Associative array of const items

[Q. Schroll via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 17:08:45 UTC, Jonathan Marler wrote:
Is there a way to have an associative array of const values? I 
thought it would have been:


const(T)[K] map;
map[x] = y;

but the second line gives Error: cannot modify const 
expression.  I would think that the const(T)[K] would behave 
similarly to const(T)[], where you can modify the array, just 
not the individual elements, but associative arrays don't seem 
to have the same semantics.  Is there a way to achieve these 
semantics with an associative array?


It is possible to initialize the array with a AA literal as
const(int)[string] aa = [ "1": 1, "2": 2 ];
but AAs don't have opIndexAssign etc.
The reasonable things you do to const(T)[] is shorten it or 
reassign it completely.
For an AA, this is removing elements or adding new ones. While 
the first is without problems, the problem is how to determine if 
aa["1"] = 1 is a (legal) initialization or (illegal) reassignment 
of a const(T). Unfortunately, there is no function to add 
key-value-pairs that throws an Error if the key is already there 
or else reinitializes the value.

Re: Ocean preview finally open sourced

[Leandro Lucarella via Digitalmars-d-announce]

On Thursday, 30 June 2016 at 20:59:42 UTC, Chris wrote:
How much would it take to make it cross platform (Windows, 
Mac). Unfortunately, we still have to cater for those two 
outliers :)


I'd say some parts should work out of the box (there many things 
that are completely OS agnostic, like containers, cache, bindings 
to other libraries like PCRE, etc.), and some other it would be 
quite some work (for example all the I/O is tied to epoll, there 
is one class to work with direct I/O that's super Linux specific, 
etc.).

[Issue 12357] Untyped string variable fails silently. No compiler warning given.

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/ac01da550f85db3f0e77eb40a5a3850578ca21ba
Fix Issue 12357 - Deprecate calling text, wtext and dtext with 0 arguments

https://github.com/dlang/phobos/commit/5b02e869979bc0dda4c880b9e2b15c429c87c0a7
Merge pull request #4460 from MetaLang/fix12357

Fix Issue 12357 - Deprecate calling text, wtext and dtext with 0 arguments

--

Re: Get current date and time with std.datetime

[Luke Picardo via Digitalmars-d-learn]

On Monday, 24 October 2011 at 15:29:41 UTC, Jonathan M Davis 
wrote:

On Friday, October 07, 2011 19:58:12 Joel Christensen wrote:

> http://d-programming-language.org/intro-to-datetime.html

Thanks Jonathan, that helped I think, (haven't read it all, 
though). But I've got errors with some of the date times not 
being able to change them with int's values.


task.d(44): Error: function std.datetime.DateTime.month () 
const is not

callable using argument types (int)
task.d(44): Error: cannot implicitly convert expression 
(month0) of type

int to Month


Month is an enum. So, any function taking a month must take an 
enum value, not an integer. e.g. Month.jan, Month.feb, 
Month.mar, etc. If you want to pass it an integral value, you 
have to cast. e.g. cast(Month)1, cast(Month)2, cast(Month)3, 
etc.


- Jonathan M Davis


Why is it so hard to simply get the current date and time 
formatted properly in a string?


There are no examples of this in your documentation yet this is 
probably one of the most used cases.

Re: Call to Action: making Phobos @safe

[Walter Bright via Digitalmars-d]

On 6/30/2016 4:09 AM, Steven Schveighoffer wrote:

I would further say -- if you see a @trusted unit test, whoever wrote it doesn't
understand the point of @trusted. Be sure and check the code it is testing too,
and file bugs if appropriate.


I agree. Using @trusted properly turns out to have some surprising subtleties, 
but this one is pretty much a no-brainer.

Re: Ocean preview finally open sourced

[Chris via Digitalmars-d-announce]

How much would it take to make it cross platform (Windows, Mac). 
Unfortunately, we still have to cater for those two outliers :)

Re: GTKD - CSS class color "flash" delay

[Mike Wey via Digitalmars-d-learn]

On 06/30/2016 08:53 AM, TheDGuy wrote:

On Wednesday, 29 June 2016 at 10:41:21 UTC, TheDGuy wrote:

I tried to debug a little and what i don't understand is, that i get
two times 'blue' on the console, even though yellow and blue lit up
but yellow stayed at the flash color:

private void letButtonsFlash(){
foreach(Button btn;bArr){
btn.setSensitive(false);
}
for(int i = 0; i < level; i++){
index = i;
Button currentButton = bArr[rndButtonBlink[i]]; //Array
holds randomized Buttons
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName ~
"-flash");
Timeout t = new Timeout(() =>
this.timeout_delay(currentButton),1,false);
}

foreach(Button btn;bArr){
btn.setSensitive(true);
}
}
bool timeout_delay(Button currentButton){
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
writeln(CSSClassName); //try to debug
currentButton.getStyleContext().removeClass(CSSClassName ~
"-flash");
return false;
}

The reason for the problem that buttons are flashing simultaneously
might be, that the Timeout is running in an extra thread and therefore
another Timeout is created by the mainthread in the for-loop even
though the last one hasn't finished yet.

But what i don't understand is why the last button doesn't go back to
the normal CSSClass and that the first button has two timeouts
(according to my console debug text)?

It would be very much appreciated if someone who has GTKD installed
can try my code:

http://pastebin.com/h0Nx1mL6


Okay, i am quite sure now that this is some kind of bug:

https://picload.org/image/rrrgwpgi/gtkd_timeout.png

private void letButtonsFlash(){
foreach(Button btn;bArr){
btn.setSensitive(false);
}
for(int i = 0; i < level; i++){
index = i;
Button currentButton = bArr[rndButtonBlink[i]]; //Array
holds randomized Buttons
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName ~
"-flash");
writeln("Creating Timeout for : " ~ CSSClassName);
Timeout t = new Timeout(() =>
this.timeout_delay(currentButton),1,false);
}

foreach(Button btn;bArr){
btn.setSensitive(true);
}
}
bool timeout_delay(Button currentButton){
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().removeClass(CSSClassName ~
"-flash");
writeln("Removing flash CSS color for: " ~ CSSClassName);
return false;
}


Is the complete source available some ware?

--
Mike Wey

Re: front stability

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 30 June 2016 at 19:34:47 UTC, H. S. Teoh wrote:
arbitrary type. It doesn't seem to make sense that the 
assignment operator should suddenly be prohibited just because 
it happens to have members named .front, .empty, .popFront.


Seems like this could be resolved by requiring all range code to 
use an enclosure type that wraps the range functionality.

Re: front stability

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 30, 2016 at 07:23:24PM +, default0 via Digitalmars-d wrote:
> On Thursday, 30 June 2016 at 18:07:41 UTC, Steven Schveighoffer wrote:
[...]
[...]
> > Unfortunately, for the likes of forward ranges, copying mainly
> > always does the same thing as .save does. So you have tons and tons
> > of code that doesn't properly use .save. Such is the way things are,
> > and I'm not sure it will ever get better :(
> > 
> > -Steve
> 
> Can we have ranges that disallow using them like rangeCache = range;
> without sacrificing usability in other cases? Going forward having
> ranges that simply do not compile when used that way would probably
> make lots of people actually honor .save and allow the compiler to
> point out buggy code (even if, in the end, .save really comes down to
> a no-op for many ranges).

Andrei has mentioned that, in retrospect, we should have defined forward
ranges such that copying the range object *is* saving. (Though it is
unclear to me what is to be done with by-reference ranges like range
classes, since you'd still need a separate method to be able to copy the
class object. Unless you wrap them in a struct that calls the copy
method in its postblit.)

That aside, though, I'm not sure how you'd enforce not copying a range.
The range API is defined by constraints rather than a language-level
Concept, so the actual range object could be any arbitrary type. It
doesn't seem to make sense that the assignment operator should suddenly
be prohibited just because it happens to have members named .front,
.empty, .popFront.  Besides, outside of generic code, what if the
user-defined range is actually such that assignment does the Right
Thing(tm)?  The cases that we want to prohibit are restricted only to
generic code, since code that already "knows" the concrete type
shouldn't be arbitrarily restricted like this.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't 
seem to remove the bugs on my system! -- Mike Dresser

Re: front stability

[default0 via Digitalmars-d]

On Thursday, 30 June 2016 at 18:07:41 UTC, Steven Schveighoffer 
wrote:

On 6/30/16 11:56 AM, Mathias Lang via Digitalmars-d wrote:
2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via 
Digitalmars-d
>:


I have always treated ranges with this expectation:


I think the case is pretty clear here, and I'm in agreement 
with you.


I just want to add a note on the following point:
2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via
Digitalmars-d >:

The counter-argument seems to be that if you cache the 
front
element, then then making a copy of the range via take can 
repeat
the cached element[4]. I find this argument severely 
lacking --
non-forward ranges are not meant to be copied and expected 
to

operate properly, it's why we require calling save.


The compiler is blatantly guilty of doing so:
https://issues.dlang.org/show_bug.cgi?id=15413


I don't think that's a bug. The range definition says nothing 
about what happens on copying, or that non-forward ranges 
shouldn't be copied. What it says is that if you make a copy 
and use both, then there is no guarantee what happens. This is 
the use case in the argument I referenced.


Unfortunately, for the likes of forward ranges, copying mainly 
always does the same thing as .save does. So you have tons and 
tons of code that doesn't properly use .save. Such is the way 
things are, and I'm not sure it will ever get better :(


-Steve


Can we have ranges that disallow using them like rangeCache = 
range; without sacrificing usability in other cases? Going 
forward having ranges that simply do not compile when used that 
way would probably make lots of people actually honor .save and 
allow the compiler to point out buggy code (even if, in the end, 
.save really comes down to a no-op for many ranges).

Re: Call to Action: making Phobos @safe

[Bennet Leff via Digitalmars-d]

On Sunday, 26 June 2016 at 13:13:01 UTC, Robert burner Schadek 
wrote:
It would be awesome if you would create that process model in 
the wiki and at it to your action list 
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List


So it does not get lost and people can find it.


Could you elaborate on list option 9 "create a module that 
enables code to be run on GPU." Wouldn't the Derelict OpenCL 
bindings satisfy that need?

Re: Ocean preview finally open sourced

[Stefan Koch via Digitalmars-d-announce]

On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella 
wrote:
Hello again Dland! I'm happy to finally announce the open 
sourcing of our Ocean base library, just it time to keep our 
word and make it in June ;-)


[...]


I like the structTable :)

Re: front stability

[Steven Schveighoffer via Digitalmars-d]

On 6/30/16 11:56 AM, Mathias Lang via Digitalmars-d wrote:

2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d
>:

I have always treated ranges with this expectation:


I think the case is pretty clear here, and I'm in agreement with you.

I just want to add a note on the following point:
2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via
Digitalmars-d >:

The counter-argument seems to be that if you cache the front
element, then then making a copy of the range via take can repeat
the cached element[4]. I find this argument severely lacking --
non-forward ranges are not meant to be copied and expected to
operate properly, it's why we require calling save.


The compiler is blatantly guilty of doing so:
https://issues.dlang.org/show_bug.cgi?id=15413


I don't think that's a bug. The range definition says nothing about what 
happens on copying, or that non-forward ranges shouldn't be copied. What 
it says is that if you make a copy and use both, then there is no 
guarantee what happens. This is the use case in the argument I referenced.


Unfortunately, for the likes of forward ranges, copying mainly always 
does the same thing as .save does. So you have tons and tons of code 
that doesn't properly use .save. Such is the way things are, and I'm not 
sure it will ever get better :(


-Steve

Re: DConf Videos

[Jack Stouffer via Digitalmars-d]

On Tuesday, 7 June 2016 at 17:48:28 UTC, Dicebot wrote:

On Tuesday, 7 June 2016 at 04:25:42 UTC, Mike Parker wrote:
It's only been a month. In the past, it's generally been a few 
weeks after each conference before the video uploads began. 
I'm sure they'll be coming soon.


I've reminded Dylan about it. Should be out soon, but no exact 
ETA.


Still no word?

Re: Does a Interpretation-Engine fit in phobos ?

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 30 June 2016 at 15:53:19 UTC, ZombineDev wrote:
Also almost every dynamic language has some sort of eval 
function can be used to evaluate arbitrary code at run-time.


And almost every language guideline suggest to never use it. When 
people have to use it, it usually ends in a library/language 
extension making it obsolete...


LOL, I have never heard about a user complaining that a product 
has too many features, as long as they don't get in the way.


Really? It is quite common to complain about standard libraries 
being stuck with obsolete features. Which is quite confusing to 
both beginners and intermediate programmers.


data base queries, etc.) Such functionality has been a huge 
success for .NET. E.g. they enabled some advanced LINQ features 
which are used under the hood of almost every .NET project.


In Java and C#, the VM is the most stable language. In D/C++/C 
the IR is completely implementation defined.


A VM does not belong in a standard library. It is going to suck. 
If it doesn't suck today, then it will most certainly suck 
tomorrow or the day after.


packages. For example, that would allow linters to leverage the 
compiler lexer and parser instead of implementing their own, 
which often can't handle all language features.


The standard library is for abstracting system specific aspects 
that libraries need to deal with. The most important aspect of a 
standard library is for writing libraries with a strong focus on 
consistency, not compilers or even applications. A standard 
library should have very high quality and performance 
requirements.


The D standard library is already too bloated to reach a high 
quality level and probably also suffer in the performance 
department.


Keep auxiliary stuff out, or D will never reach a competitive 
level.

Re: Does a Interpretation-Engine fit in phobos ?

[default0 via Digitalmars-d]

On Thursday, 30 June 2016 at 15:53:19 UTC, ZombineDev wrote:

On Thursday, 30 June 2016 at 14:14:41 UTC, Wyatt wrote:

On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
Ok, seriously, it sounds like an awesome feat, but I don't 
think it is necessary to put it into Phobos. First, a dub 
package, please.


Agree.  Does Java even have something like that?


I'm afraid you couldn't be more wrong. Both Java and .NET have 
many provide ways for generating and executing byte code at 
run-time. Sometimes this the only way to implement something 
efficiently when runtime reflection is needed. See for example:

https://msdn.microsoft.com/en-us/library/mt654263.aspx,
https://msdn.microsoft.com/en-us/library/mt654267.aspx,
http://openjdk.java.net/groups/compiler/doc/package-overview/index.html,
http://asm.ow2.org/,
https://commons.apache.org/proper/commons-bcel/manual.html,
https://github.com/cglib/cglib,
http://jboss-javassist.github.io/javassist/,
https://www.jetbrains.com/mps/index.html,
https://docs.microsoft.com/en-us/dotnet/core/api/system.reflection.emit and
https://www.postsharp.net/features

Also almost every dynamic language has some sort of eval 
function can be used to evaluate arbitrary code at run-time. 
This has it's security and maintainability challenges, but 
without any doubt there are situations where this is very 
helpful.


That's sort of the exemplar for "hopelessly overdone standard 
library".


LOL, I have never heard about a user complaining that a product 
has too many features, as long as they don't get in the way. 
Instead users complain when something is **not available**, 
because that prevents them from getting their job done. What's 
wrong with having a module in the standard library that you 
personally won't use, but others will find helpful?


There are many ways in which code-generation can interact with 
the language runtime. By including it in the standard library, 
we can ensure that it is thoroughly tested on all supported 
platforms. Of course the other benefit is that it can be used 
from other modules in the standard library for implementing 
various optimizations (e.g. optimizing regex, linear algebra, 
data base queries, etc.) Such functionality has been a huge 
success for .NET. E.g. they enabled some advanced LINQ features 
which are used under the hood of almost every .NET project.


Off-topic: Is it possible/feasible/desirable to let dmd use 
dub packages?


DMD shouldn't have to download things from the public internet 
to do its job.


I don't think you understood the question. The question is how 
should DMD's code base be structured / modularized. Of course 
after the DMD is compiled it shouldn't need to use the 
internet, but that's not the point. The question is if it's a 
good idea to split the project in small safe-contained reusable 
packages. For example, that would allow linters to leverage the 
compiler lexer and parser instead of implementing their own, 
which often can't handle all language features.


Another huge area is compiler plugins which are quite popular 
in Rust and .NET

https://doc.rust-lang.org/book/compiler-plugins.html
https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview

About compiler plugins in Rust:
In a nutshell Rust plugin's let you write normal imperative 
run-time type-checked Rust code that is executed at 
compile-time on the AST and they let you do absolutely 
anything (File/Network I/O, launching threads, ...) including 
rewriting the AST. People use it to extend the language "as a 
library": implement coroutines, plain-Rust-to-GLSL libraries 
that allow you to write shaders in Rust, GPGPU language 
extensions, and also to write very powerful libraries: regex 
engines, serialization libraries, database libraries that 
connect at compile-time to the data-base to validate your SQL 
queries and give you compile-time errors if they are 
invalid... EDSLs... All in normal, imperative, run-time Rust 
code, without shadow worlds (except for the AST API).

- some guy on reddit

.NET Compiler Platform ("Roslyn"): Analyzers and the Rise of 
Code-Aware Libraries:

https://www.youtube.com/watch?v=Ip6wrpYFHhE

I guess it would make sense to extract parts of dmd into dub 
packages. As a next step, dmd could use those packages 
instead of duplicating code.


Does it?  Which parts?  I'm afraid I don't see the benefit.

-Wyatt


LOL x2


My 2 cents on compiler plugins is that as cool and powerful and 
amazing as they sound they put quite the burden on their user. 
Compilers are complicated beasts. In order to write some code 
that correctly uses their API you first have to learn quite a lot 
of stuff (how to use their specific API, how their AST looks, 
what you can and can't do, why this particular error pops up 
etc). And from what I know in those languages, unlike in D, there 
is no **simple** go-to way of doing work at CT that you just need 
done.


I had the pleasure of writing a pseudo compiler extension for 
static interfaces 

Re: static if enhancement

[Wyatt via Digitalmars-d]

On Thursday, 30 June 2016 at 11:06:56 UTC, Steven Schveighoffer 
wrote:

On 6/29/16 11:40 AM, Wyatt wrote:
I might be stepping on a land mine by bringing it up, but 
isn't this

sort of thing what contracts are for?


No landmines here, but no, that isn't what contracts are for. 
Perhaps you mean constraints?


Sure. IME, contracts are generally written as a series of 
constraints anyway.


A constraint will prevent compilation vs. allowing compilation 
but emitting a failure at runtime. I agree this is a better 
mechanism, or just plain allow the compiler to make a proper 
error when you call gun.


Isn't doing it at compile time as simple as using e.g. static 
assert(hasMember(T, "gun"))?  I do feel like I've been in 
situations before where this kind of thing was better as a 
recoverable runtime exception, but I can't remember where.


The more I think about this, though, the less the proposal makes 
sense for the problem.  Like, I get that it might be a tiny bit 
annoying, but I see a lot more potential for human error; pulling 
a "goto FAIL" and running code that shouldn't be or such.


-Wyatt

Associative array of const items

[Jonathan Marler via Digitalmars-d-learn]

Is there a way to have an associative array of const values? I 
thought it would have been:


const(T)[K] map;
map[x] = y;

but the second line gives Error: cannot modify const expression.  
I would think that the const(T)[K] would behave similarly to 
const(T)[], where you can modify the array, just not the 
individual elements, but associative arrays don't seem to have 
the same semantics.  Is there a way to achieve these semantics 
with an associative array?

Re: Cast vs Virtual Method vs TypeId?

[QAston via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 00:25:53 UTC, Jonathan Marler wrote:
I'd like to hear peoples thoughts on the various solutions for 
the following problem.  Say you have some hierarchy of classes 
like:


class GameObject {
  // ...
}
class Entity : GameObject {
  // ...
}
class Player : Entity {
  // ...
}
class Enemy : Entity {
  // ...
}
// ...

Assume you have a function that accepts a GameObject but does 
something special if that GameObject happens to be an instance 
of the Player class. How would you go about determining this? 
(Note: assume you need to make the distinction at runtime, so 
you can't use a static if with an 'is' expression inside a 
template.)


I'd like to hear what people think in 2 cases
  1) Only need to know if it's an instance of the Player class.
  2) Need to know if it's an instance of the Player class AND 
need an instance of the Player class.


The potential solutions I thought of were:

1) typeid (Only handles case 1)

if(typeid(obj) == typeid(Player) {
  // treat as player object
}

If you don't need an instance of the Player class, maybe this 
one is good? I don't know in terms of efficiency if this is 
better, or casting is better.  Maybe cast uses the typeid under 
the hood to determine if the cast can be performed?


2) Custom Type Enum (Only handles case 1)

enum GameObjectType {
  gameObject, player, ...
}
class GameObject {
  GameObjectType type;
}

if(obj.type == GameObjectType.player) {
  // treat it as a player object
  // Note: if you need to use Player class specific fields
  //   then you'll need to use the cast or virtual function
  //   design which kinda defeats the purpose of this 
design in the

  //   case where it is actually a Player object.
}

This method may be similar to the typeid method, not sure since 
I don't know how typeid works under the hood.  If it's similar 
then this would just be a waste of memory and should not be 
used in favor of the typeid method.


3) Cast (Handles case 1 and 2)

auto player = cast(Player)obj;
if(player) {
  // treat it as a player object
}

I don't know how cast works under the hood so it's hard to 
compare it to other methods.  Any information on how cast works 
under the hood would be great.


4) Virtual Method (Handles case 1 and 2)

class GameObject {
  Player asPlayer() { return null; }
}
class Player {
  override Player asPlayer() { return this; }
}

auto player = obj.asPlayer;
if(player) {
  // treat it as a player object
} else {
  // treat it as any other game object
}

This solution handles the same cases as regular casting, but I 
can't compare them since I don't know how casting works under 
the hood.  One thing to consider is that this method scales 
linearly since you need to add a new virtual method for every 
type you want to support, so the vtable gets larger as you add 
more types.



Any other solutions? Thoughts?  Thanks in advance for the 
feedback.


This problem is not D specific, there are lots of different 
approaches.
If you're not going to add new types to the hierarchy very often 
the visitor pattern is a good choice, see[1]. You can also use 
composition instead of inheritance to share code by using mixins 
+ templates. Or you can try more traditional 
entity-component-systems.


Take a look at game engines written in D, they may have some good 
D specific ideas already.


http://www.deadalnix.me/2012/08/25/visitor-pattern-revisited-in-d/

Re: Cast vs Virtual Method vs TypeId?

[Jonathan Marler via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 00:27:57 UTC, rikki cattermole wrote:

On 30/06/2016 12:25 PM, Jonathan Marler wrote:
Assume you have a function that accepts a GameObject but does 
something
special if that GameObject happens to be an instance of the 
Player
class. How would you go about determining this? (Note: assume 
you need
to make the distinction at runtime, so you can't use a static 
if with an

'is' expression inside a template.)


void func(GameObject o) {
if (Player player = cast(Player)o) {
// something special
}
}


Thanks for the response.  Do you also have any information on how 
cast works under the hood?

Ocean preview finally open sourced

[Leandro Lucarella via Digitalmars-d-announce]

Hello again Dland! I'm happy to finally announce the open 
sourcing of our Ocean base library, just it time to keep our word 
and make it in June ;-)


https://github.com/sociomantic-tsunami/ocean

To quote the README:

---
Ocean is a general purpose library, compatible with both D1 and 
D2, with a focus
on supporting the development of high-performance, real-time 
applications. This

focus has led to several noteworthy design choices:

* Ocean is not cross-platform. The only supported platform is 
Linux.
* Ocean assumes a single-threaded environment. Fiber-based 
multi-tasking is

  favoured, internally.
* Ocean aims to minimise use of the D garbage collector. GC 
collect cycles
  can be very disruptive to real-time applications, so Ocean 
favours a model of

  allocating resources once then reusing them, wherever possible.

Ocean began life as an extension of Tango, some elements of which 
were

eventually merged into Ocean.
---

Please consider this as a very early release, this is why we are 
"branding" it as a "preview". This is basically because, despite 
being working on the open sourcing full steam since DConf ended, 
we couldn't manage to set up all the infrastructure to be able to 
put all our development efforts in the public repo yet. So 
unfortunately the main development will still happen inside 
Sociomantic for this first phase (we'll only synchronize 
releases). When this will switch finally happens will depend on 
how much work it would imply to build a public infrastructure 
(mainly for automatic testing), and honestly, what's the 
community reception (we understand it might not be all that 
tempting being a D1 project that gets automatically converted to 
D2, thus not very idiomatic D2 :).


Anyway, the main big step is done. You can take a look at the 
code, use it or steal parts of it if you find them useful 
(although please have a look at the licensing terms, even when 
all our code is Boost, there is code inherited from Tango that 
isn't), criticize it, and if you are really nice, fill issues and 
make pull requests!


Also, in the near future we plan to write a blog post explaining 
a bit more about what Ocean is about, we'll let you know when 
it's ready, but we didn't want to delay the release for it :-)


Thank you!

[Issue 15413] Foreach over range with @disable this doesn't work

[via Digitalmars-d-bugs]

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

--- Comment #2 from ZombineDev  ---
I meant:

foreach (v; ir)
{
// user code
}

// =v

for ( ; !ir.empty; ir.popFront())
{
auto v = ir.front;
// user code
}

--

[Issue 15413] Foreach over range with @disable this doesn't work

[via Digitalmars-d-bugs]

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

--- Comment #1 from ZombineDev  ---
I wonder if the solution could be as simple* as changing the lowering to:

for ( ; !ir.empty; ir.popFront()) {
auto v = __r.front;
}

That way foreach will work with truly input-only ranges (such as ones with
@disabled this(this)) and the users could optionally insert a .save call, if
needed, when they're working with forward ranges.

If this is an unacceptable breaking change, we could use the new lowering only
when the postblit is disabled.

* I'm not very familiar the compiler internals, so I have no idea if this would
be actually simple in practice.

--

[Issue 15413] Foreach over range with @disable this doesn't work

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

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

--

Re: Does a Interpretation-Engine fit in phobos ?

[ZombineDev via Digitalmars-d]

On Thursday, 30 June 2016 at 14:14:41 UTC, Wyatt wrote:

On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
Ok, seriously, it sounds like an awesome feat, but I don't 
think it is necessary to put it into Phobos. First, a dub 
package, please.


Agree.  Does Java even have something like that?


I'm afraid you couldn't be more wrong. Both Java and .NET have 
many provide ways for generating and executing byte code at 
run-time. Sometimes this the only way to implement something 
efficiently when runtime reflection is needed. See for example:

https://msdn.microsoft.com/en-us/library/mt654263.aspx,
https://msdn.microsoft.com/en-us/library/mt654267.aspx,
http://openjdk.java.net/groups/compiler/doc/package-overview/index.html,
http://asm.ow2.org/,
https://commons.apache.org/proper/commons-bcel/manual.html,
https://github.com/cglib/cglib,
http://jboss-javassist.github.io/javassist/,
https://www.jetbrains.com/mps/index.html,
https://docs.microsoft.com/en-us/dotnet/core/api/system.reflection.emit and
https://www.postsharp.net/features

Also almost every dynamic language has some sort of eval function 
can be used to evaluate arbitrary code at run-time. This has it's 
security and maintainability challenges, but without any doubt 
there are situations where this is very helpful.


That's sort of the exemplar for "hopelessly overdone standard 
library".


LOL, I have never heard about a user complaining that a product 
has too many features, as long as they don't get in the way. 
Instead users complain when something is **not available**, 
because that prevents them from getting their job done. What's 
wrong with having a module in the standard library that you 
personally won't use, but others will find helpful?


There are many ways in which code-generation can interact with 
the language runtime. By including it in the standard library, we 
can ensure that it is thoroughly tested on all supported 
platforms. Of course the other benefit is that it can be used 
from other modules in the standard library for implementing 
various optimizations (e.g. optimizing regex, linear algebra, 
data base queries, etc.) Such functionality has been a huge 
success for .NET. E.g. they enabled some advanced LINQ features 
which are used under the hood of almost every .NET project.


Off-topic: Is it possible/feasible/desirable to let dmd use 
dub packages?


DMD shouldn't have to download things from the public internet 
to do its job.


I don't think you understood the question. The question is how 
should DMD's code base be structured / modularized. Of course 
after the DMD is compiled it shouldn't need to use the internet, 
but that's not the point. The question is if it's a good idea to 
split the project in small safe-contained reusable packages. For 
example, that would allow linters to leverage the compiler lexer 
and parser instead of implementing their own, which often can't 
handle all language features.


Another huge area is compiler plugins which are quite popular in 
Rust and .NET

https://doc.rust-lang.org/book/compiler-plugins.html
https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview

About compiler plugins in Rust:
In a nutshell Rust plugin's let you write normal imperative 
run-time type-checked Rust code that is executed at 
compile-time on the AST and they let you do absolutely anything 
(File/Network I/O, launching threads, ...) including rewriting 
the AST. People use it to extend the language "as a library": 
implement coroutines, plain-Rust-to-GLSL libraries that allow 
you to write shaders in Rust, GPGPU language extensions, and 
also to write very powerful libraries: regex engines, 
serialization libraries, database libraries that connect at 
compile-time to the data-base to validate your SQL queries and 
give you compile-time errors if they are invalid... EDSLs... 
All in normal, imperative, run-time Rust code, without shadow 
worlds (except for the AST API).

- some guy on reddit

.NET Compiler Platform ("Roslyn"): Analyzers and the Rise of 
Code-Aware Libraries:

https://www.youtube.com/watch?v=Ip6wrpYFHhE

I guess it would make sense to extract parts of dmd into dub 
packages. As a next step, dmd could use those packages instead 
of duplicating code.


Does it?  Which parts?  I'm afraid I don't see the benefit.

-Wyatt


LOL x2

Re: front stability

[Mathias Lang via Digitalmars-d]

2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d <
digitalmars-d@puremagic.com>:

> I have always treated ranges with this expectation:
>
>
I think the case is pretty clear here, and I'm in agreement with you.

I just want to add a note on the following point:
2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d <
digitalmars-d@puremagic.com>:

> The counter-argument seems to be that if you cache the front element, then
> then making a copy of the range via take can repeat the cached element[4].
> I find this argument severely lacking -- non-forward ranges are not meant
> to be copied and expected to operate properly, it's why we require calling
> save.
>

The compiler is blatantly guilty of doing so:
https://issues.dlang.org/show_bug.cgi?id=15413

Re: Version info in library reference

[Chris via Digitalmars-d]

On Thursday, 30 June 2016 at 15:47:52 UTC, Chris wrote:


I've just had the case where LDC (based on 2.070.2) did not 
compile code based on Phobos 2.071.1, which is nothing unusual 
of course. Only it would have been nice, if the function 
`std.algorithm.maxPos` had had the info "since 2.071.0" 
attached to it. How am I supposed to know that `maxPos` is new 
while `minPos` was already available in 2.070.0. It'd make 
things a bit smoother, especially because not all compilers use 
the same version of Phobos.


LDC is apparently in sync now:

http://forum.dlang.org/post/czukvcubxxuskbknk...@forum.dlang.org

But still, version info in the library would be vry nice.

Re: Version info in library reference

[Chris via Digitalmars-d]

On Wednesday, 27 April 2016 at 12:47:01 UTC, Jacob Carlborg wrote:

On 2016-04-27 11:14, Chris wrote:
Something I've wanted to ask for a while: Would it be possible 
to add
version info to the library reference (henceforth)? In Apple's 
Cocoa API
reference they always say since `10.8` etc. which used to be 
very helpful.


In Swift they even added language support for using different 
versions of the API's.


I've just had the case where LDC (based on 2.070.2) did not 
compile code based on Phobos 2.071.1, which is nothing unusual of 
course. Only it would have been nice, if the function 
`std.algorithm.maxPos` had had the info "since 2.071.0" attached 
to it. How am I supposed to know that `maxPos` is new while 
`minPos` was already available in 2.070.0. It'd make things a bit 
smoother, especially because not all compilers use the same 
version of Phobos.

[Issue 16223] New: BigUint: undefined shift for small instantiation type

[via Digitalmars-d-bugs]

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

  Issue ID: 16223
   Summary: BigUint: undefined shift for small instantiation type
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jbc.enge...@gmail.com

Module std.internal.math.biguintcore contains the code:
```
static BigUint mulInt(T = ulong)(BigUint x, T y) pure nothrow
{
if (y==0 || x == 0) return BigUint(ZERO);
uint hi = cast(uint)(y >>> 32);
```
The ">>> 32" is undefined for sizeof(T)*8 <= 32 (so for T = int, uint, char,
...). There should at least be a check that the function is not instantiated
for types equal or smaller than 32 bits.

No bug yet, because the only usage of mulInt is with T=ulong (bigint.d).

--

Re: front stability

[Steven Schveighoffer via Digitalmars-d]

On 6/30/16 10:59 AM, jmh530 wrote:

On Thursday, 30 June 2016 at 14:17:22 UTC, Steven Schveighoffer wrote:


Jack Stouffer has created a PR to formalize this.

Please comment if you have objections (the group that argued for
current generate behavior was absent from this post that was meant to
be a debate). I think this is the right thing to do.


It looks like this is just documentation changes. This really doesn't
prevent anyone from making a Range that violates front stability. For
instance, suppose isInputRange is changed so that

auto h = r.front; // can get the front of the range

becomes

auto h = r.front; // can get the front of the range
auto j = r.front;
assert(h == j);  //ensure front stability


This doesn't solve it, and it can't be solved -- halting problem. We 
have some expectations that are assumed and some that are mechanically 
tested. This PR clarifies the assumptions.


-Steve

Cool D project: Remove cycle detection code from runtime

[Steven Schveighoffer via Digitalmars-d]

For those who wish to have a deeper understanding of D's runtime and/or 
binary files, there is a project I think would be a nice fun challenge.


Currently, when D builds, it uses the linker to assemble a table of 
ModuleInfo structures, each of which define the pieces of the module 
that the runtime needs to be aware of. One of these things is the static 
constructors and destructors, both shared (run at startup) and unshared 
(run at thread start). Note that this is a simplification, I'm not 
actually sure how the compiler and linker assemble this stuff.


Because we don't have control over the linker, and indeed the compiler 
cannot tell which modules will be included in the final binary, we must 
run an interesting, yet annoying, check every time you run a D 
executable -- topological sorting of the module constructors.


The reason is simple, let's say you have 2 modules:

chicken.d:
import egg;

static int x;

static this()
{
   x = egg.x + 1;
}

egg.d:
import chicken;

static int x;
static this()
{
   x = chicken.x + 1;
}

Which x came first? The answer is easy -- it depends on the order the 
modules are linked (obviously)!


To avoid such a disastrous situation, the runtime can fetch dependency 
data out of the executable (stored by the compiler/linker), and do a 
proper determination of the ordering for the static constructors. If, 
for instance, chicken stopped importing egg, or vice versa, then the 
static constructors would have a well-defined order. If instead there is 
a cyclic dependency, the runtime will halt execution and print an error 
informing you of the cycle.


The solution for detecting cycles is quite interesting (and recently I 
discovered that the cycle detection algorithm was broken, and I've 
re-implemented the cycle detection, this time with a test case [1]), but 
one very annoying piece of this is that the cycle detection has to run 
every time the executable is run, or every time a shared object is 
loaded. This is a sheer waste of computing power -- we are sorting the 
same static data every time we load because we lack the hooks to the 
linker to make it happen at compile time. There's not much we can do to 
improve the linker, but we CAN monkey around with the executable file :)


I propose that we (well, mostly someone other than me) write a tool that 
reads the generated linked code, extracts the relevant module 
information, sorts the data per the same algorithm as defined in 
druntime, then writes the ordering into a reserved index space (for both 
shared and TLS construction), or returns an error if there is a cycle. 
Then the runtime can be modified to detect if this tool has been run and 
avoid doing the cycle detection code. The tool will become part of the 
build normally done by your makefile. Druntime will use a flag written 
by the tool to determine that a pre-sort has been done.


This requires knowledge of executable/object format, knowledge of the 
layout of the module info, knowledge of DMD (you have to properly output 
the space for the reserved spaces), knowledge of druntime's runtime 
intialization, and knowledge of graph algorithms (specifically 
topological sorting and cycle detection).


Any hackers out there want to try this? You get to close an old bug if 
so: https://issues.dlang.org/show_bug.cgi?id=2457


-Steve

[1] https://github.com/dlang/druntime/pull/1602

Re: Release D 2.071.1

[default0 via Digitalmars-d-announce]

On Thursday, 30 June 2016 at 12:55:27 UTC, Johan Engelen wrote:

On Monday, 27 June 2016 at 22:11:53 UTC, Martin Nowak wrote:

Glad to announce D 2.071.1.


Thanks.
LDC master is now also at 2.071.1.

-Johan


I dare say you guys are awesome :o) Having those two frontends 
synced is really a big deal imho.

Re: front stability

[Jack Stouffer via Digitalmars-d]

On Thursday, 30 June 2016 at 14:59:11 UTC, jmh530 wrote:
It looks like this is just documentation changes. This really 
doesn't prevent anyone from making a Range that violates front 
stability.


No, but what it will do is to make it clear that these are either 
bugs or intended behavior, as this is still a point of 
disagreement.



For instance, suppose isInputRange is changed so that

auto h = r.front; // can get the front of the range

becomes

auto h = r.front; // can get the front of the range
auto j = r.front;
assert(h == j);  //ensure front stability


This cannot be done at compile time.

Re: front stability

[jmh530 via Digitalmars-d]

On Thursday, 30 June 2016 at 14:17:22 UTC, Steven Schveighoffer 
wrote:


Jack Stouffer has created a PR to formalize this.

Please comment if you have objections (the group that argued 
for current generate behavior was absent from this post that 
was meant to be a debate). I think this is the right thing to 
do.


It looks like this is just documentation changes. This really 
doesn't prevent anyone from making a Range that violates front 
stability. For instance, suppose isInputRange is changed so that


auto h = r.front; // can get the front of the range

becomes

auto h = r.front; // can get the front of the range
auto j = r.front;
assert(h == j);  //ensure front stability

This doesn't seem to work for the map example above, but could it 
be adapted so that it does?

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote:


Sorry, I had missed this. I see you were able to make progress.


It's fine.
Honestly the hardest thing was to actually get started.

Once I see something working the excitement carries me forward :)

I would appreciate a critical opinion, anytime!

Re: What's the secret to static class members

[Dejan Lekic via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 01:11:09 UTC, Mike Parker wrote:


I think it's safe to say this guy is just trolling and we can 
ignore him.


I was about to say the same, Mike. He is either trolling, or 
genuinely did not even bother to learn some language basics...

Re: thread-safe shared field access

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/30/16 10:10 AM, jj75607 wrote:

For example I have a shared from different threads variable. What piece
of code is correctly thread-safe?

First:
  shared class A
  {
  shared(int) x;


Note, no need to mark x shared. 'A' implicitly shares everything.



  void test1()
  {
  x = 10;
  x += 5
  writeln(x);
  }
  }

Or second:
  import core.atomic;
  shared class A
  {
  shared(int) x;

  void test1()
  {
  atomicStore(x, 10);
  atomicOp!("+=")(x, 5);
  writeln(atomicLoad(x));
  }
  }


I don't believe the first will compile. This is probably the only thing 
that D adds for shared data (it enforces that you use atomics to read or 
modify shared primitives). And yes, the second is correct while the 
first is not.


Note that writeln is still writing a copy of the atomically loaded x. 
you could as easily done:


auto xcopy = atomicOp!("+=")(x, 5);
writeln(xcopy);

To avoid the atomic load.

-Steve

Re: front stability

[Steven Schveighoffer via Digitalmars-d]

On 6/2/16 8:51 AM, Steven Schveighoffer wrote:

I have always treated ranges with this expectation:

1. front gets you the current element of the range. Calling front
multiple times without calling popFront should get you the same value.
2. popFront moves you to the next element of the range if it exists.


Jack Stouffer has created a PR to formalize this.

Please comment if you have objections (the group that argued for current 
generate behavior was absent from this post that was meant to be a 
debate). I think this is the right thing to do.


https://github.com/dlang/phobos/pull/4511

-Steve

Re: Battle-plan for CTFE

[Timon Gehr via Digitalmars-d-announce]

On 08.06.2016 03:20, Stefan Koch wrote:

On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote:

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:


I will post more details as soon as I dive deeper into the code.


Okay I briefly evaluated the current IR dmd uses for backend
communication, and it seems usable for the purposes of a
CTFE-Interpreter/JIT.

The Memory-Management issue is mostly orthogonal to CTFE.
But nonetheless very important.


I have to admit currently I am a bit stuck.

@Timon Gehr cooperation would be highly appreciated.



Sorry, I had missed this. I see you were able to make progress.

Re: Does a Interpretation-Engine fit in phobos ?

[Wyatt via Digitalmars-d]

On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
Ok, seriously, it sounds like an awesome feat, but I don't 
think it is necessary to put it into Phobos. First, a dub 
package, please.


Agree.  Does Java even have something like that?  That's sort of 
the exemplar for "hopelessly overdone standard library".


Off-topic: Is it possible/feasible/desirable to let dmd use dub 
packages?


DMD shouldn't have to download things from the public internet to 
do its job.


I guess it would make sense to extract parts of dmd into dub 
packages. As a next step, dmd could use those packages instead 
of duplicating code.


Does it?  Which parts?  I'm afraid I don't see the benefit.

-Wyatt

thread-safe shared field access

[jj75607 via Digitalmars-d-learn]

For example I have a shared from different threads variable. What 
piece of code is correctly thread-safe?


First:
  shared class A
  {
  shared(int) x;

  void test1()
  {
  x = 10;
  x += 5
  writeln(x);
  }
  }

Or second:
  import core.atomic;
  shared class A
  {
  shared(int) x;

  void test1()
  {
  atomicStore(x, 10);
  atomicOp!("+=")(x, 5);
  writeln(atomicLoad(x));
  }
  }

Re: year to date pull statistics (2016-06-25)

[Andrei Alexandrescu via Digitalmars-d]

On 06/29/2016 08:58 PM, Brad Roberts via Digitalmars-d wrote:

total open: 295
created since 2016-01-01 and still open: 159

  created  closed  delta
2016-06-26 - today  47  37-10
2016-06-19 - 2016-06-25 44  24-20
2016-06-12 - 2016-06-18 37  48 11
2016-06-05 - 2016-06-11 40  42  2
2016-05-29 - 2016-06-04 59  66  7
2016-05-22 - 2016-05-28 46  33-13
2016-05-15 - 2016-05-21 40  36 -4
2016-05-08 - 2016-05-14 82  55-27
2016-05-01 - 2016-05-07 37  59+22
2016-04-24 - 2016-04-30 74  85+11
2016-04-17 - 2016-04-23 51  58 +7
2016-04-10 - 2016-04-16 52  58 +6
2016-04-03 - 2016-04-09 64  44-20
2016-03-27 - 2016-04-02 65  60 -5
2016-03-20 - 2016-03-26 65  62 -3
2016-03-13 - 2016-03-19 44  51 +7
2016-03-06 - 2016-03-12 41  46 +5
2016-02-28 - 2016-03-05 54  47 -7
2016-02-21 - 2016-02-27 29  20 -9
2016-02-14 - 2016-02-20 32  36 +4
2016-02-07 - 2016-02-13 52  52  0
2016-01-31 - 2016-02-06 54  61 +7
2016-01-24 - 2016-01-30 40  37 -3
2016-01-17 - 2016-01-23 31  21-10
2016-01-10 - 2016-01-16 39  42 +3
2016-01-03 - 2016-01-09 26  33 +7
2016-01-01 - 2016-01-02  2   5 +3
--- ------
   12471218-29

https://auto-tester.puremagic.com/chart.ghtml?projectid=1


My dream: this is part of dlang.org, laid out in its style, and 
automatically kept up to date. -- Andrei

Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored

[Martin Nowak via Digitalmars-d]

On Thursday, 30 June 2016 at 13:05:58 UTC, Martin Nowak wrote:
Use selective imports instead to introduce just the necessary 
steps.

s/steps/symbols/

Re: compilation error with shared ReadWriteMutex

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/30/16 8:41 AM, jj75607 wrote:

On Thursday, 30 June 2016 at 12:25:54 UTC, Steven Schveighoffer wrote:

On 6/30/16 8:18 AM, jj75607 wrote:

  [...]


You don't need to mark this shared, because the entire class is
shared, all members are implicitly marked shared.

[...]


Thanks! Is this a compilation only 'cast' with no runtime works?


Yes. cast() just removes the any qualifiers.

-Steve

Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored

[Martin Nowak via Digitalmars-d]

On Thursday, 30 June 2016 at 12:20:26 UTC, captaindet wrote:
this is really bad news for meta programming. i would have to 
do this with ugly string mixins from now on, or is this 
unintended behavior for string mixins as well?


No it's not, importing whole modules or packages into the scope 
of a user of your template is fairly problematic, b/c from there 
on any change in the imported modules will affect all users.
Use selective imports instead to introduce just the necessary 
steps.
In rare cases where the whole module is needed, you can use 
string mixins.
For converting existing code you can use -transition import 
and/or checkimports.

Re: Release D 2.071.1

[Johan Engelen via Digitalmars-d-announce]

On Monday, 27 June 2016 at 22:11:53 UTC, Martin Nowak wrote:

Glad to announce D 2.071.1.


Thanks.
LDC master is now also at 2.071.1.

-Johan

[Issue 16222] template failed to infer/coerce types for instantiation

[via Digitalmars-d-bugs]

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

--- Comment #2 from Ketmar Dark  ---
(In reply to ag0aep6g from comment #1)
> In your example, you could of course just take a const(char)[] directly,
> without any template parameters. So that isn't a good motivating example to
> change the behavior.

this is common pattern in my code, actually. i want my functions to accept
`string`, `const(char)[]` and `char[]` seamlessly, yet they should not do
unnecessary dups when i need to copy value. that is, there is no need to dup
`string` (obviously), but it's better to dup `char[]` and `const(char)[]`.
without template, i can't tell if `string` or `const(char)[]` was passed.

i was so sure that compiler does conversion of `null` to empty slice that
didn't even checked it beforehand. and today i was caught by the first case.

--

Re: compilation error with shared ReadWriteMutex

[jj75607 via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 12:25:54 UTC, Steven Schveighoffer 
wrote:

On 6/30/16 8:18 AM, jj75607 wrote:

  [...]


You don't need to mark this shared, because the entire class is 
shared, all members are implicitly marked shared.


[...]


Thanks! Is this a compilation only 'cast' with no runtime works?

Re: opEquals on shared object

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/30/16 8:30 AM, jj75607 wrote:

On Thursday, 30 June 2016 at 12:21:03 UTC, Steven Schveighoffer wrote:

On 6/30/16 6:26 AM, jj75607 wrote:

Hello!

I need to overload opEquals on shared class C

shared class C
{
override bool opEquals(Object o) { return false; }
}

But compilation fails with the message:
Error: function f700.C.opEquals does not override any function, did you
mean to override 'object.Object.opEquals'?

What am I doing wrong?


Object.opEquals is not marked shared. You can't override a non-shared
method with a shared one.

You need to remove override.

But... unfortunately, this may not work in practice. The opEquals
handling for objects is pretty much screwed unless you have unshared
mutable objects. I think it may work for const objects, but not in a
good way.

-Steve


Thanks!

But what should I do to fix that code?

shared class C
{
bool opEquals(Object o) { return false; }
}

class A(T)
{
void f(T a, T b)
{
if(a == b)
writeln("equals");
else
writeln("non equals");
}
}


int main(string[] argv)
{
auto a1 = new A!int;
a1.f(1,2);

auto a2 = new A!(shared(C));
shared C c = new shared(C);
a2.f(c,c);


return 0;
}

It fails with
Error: none of the overloads of 'opEquals' are callable using
argument types (shared(C), shared(C))


This is an artifact of the object.opEquals entry point function. It 
handles calling your object's opEquals properly.


Try changing C.opEquals to accept a shared(Object).

If that doesn't work, you may be out of luck until the druntime team 
figures this out. Please file an issue if you can't get it to work.


-Steve

Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored

[Mathias Lang via Digitalmars-d]

2016-06-30 14:20 GMT+02:00 captaindet via Digitalmars-d <
digitalmars-d@puremagic.com>:
>
> does this mean mixin templates now have no way of adding imports to the
> scope they are mixed in?
>

That's exactly what it means. Likewise a base class cannot add an import
that will be visible by it's sub classes.
string mixin will still work though.

> or is all this a special case for classes? how about at module level?
where is all this mentioned in the specs?

What about module level ?
I suggest you look at the linked P.R.
It should describe the new import behaviour, as well as the new lookup rule
(previously underdocumented).
If it doesn't address all your questions, feel free to comment on it, so it
can benefit everyone.

Re: opEquals on shared object

[jj75607 via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 12:21:03 UTC, Steven Schveighoffer 
wrote:

On 6/30/16 6:26 AM, jj75607 wrote:

Hello!

I need to overload opEquals on shared class C

shared class C
{
override bool opEquals(Object o) { return false; }
}

But compilation fails with the message:
Error: function f700.C.opEquals does not override any 
function, did you

mean to override 'object.Object.opEquals'?

What am I doing wrong?


Object.opEquals is not marked shared. You can't override a 
non-shared method with a shared one.


You need to remove override.

But... unfortunately, this may not work in practice. The 
opEquals handling for objects is pretty much screwed unless you 
have unshared mutable objects. I think it may work for const 
objects, but not in a good way.


-Steve


Thanks!

But what should I do to fix that code?

shared class C
{
bool opEquals(Object o) { return false; }
}

class A(T)
{
void f(T a, T b)
{
if(a == b)
writeln("equals");
else
writeln("non equals");
}
}


int main(string[] argv)
{
auto a1 = new A!int;
a1.f(1,2);

auto a2 = new A!(shared(C));
shared C c = new shared(C);
a2.f(c,c);


return 0;
}

It fails with
Error: none of the overloads of 'opEquals' are callable using 
argument types (shared(C), shared(C))

Re: Does a Interpretation-Engine fit in phobos ?

[ZombineDev via Digitalmars-d]

On Thursday, 30 June 2016 at 10:28:03 UTC, Stefan Koch wrote:

Hi,

I recently had a breakthrough in my CTFE work.

Though because habits die hard.
I am writing the bytecode-engine in a CTFEable style.
Therefore I can be used as a quite comfortable IR for CTFE 
things as well.


It should be fairly easy to generate a inline-asm-string from 
the byteCode  at compiletime.
And thereby creating the possibility of generating optimized 
code at compile-time.


I was wondering if such a thing would fit in phobos.

Please share your opinions with me :)

Regards,
Stefan


I think that's a great idea! It could be also useful for further 
optimizing ctRegex, among other things.


But I agree with others - please put it on DUB first so we can 
test it more widely before it's ready for Phobos. As we all know 
getting something accepted into Pbobos is not a walk in the park, 
unless you already have the perfect design: 
http://dlangcomicstrips.tumblr.com/image/128280515097

:D

BTW AFAIK @9il has done something similar for his BLAS library. 
His code generates inline LLVM IR at CT for LDC and generates 
vanilla D code for DMD.


Some realated discussions:
https://github.com/ldc-developers/ldc/issues/1438
https://github.com/ldc-developers/ldc/issues/1482

[Issue 16222] template failed to infer/coerce types for instantiation

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to Ketmar Dark from comment #0)
> consider the following code:
> 
>   auto test(T : const(char)[]) (T s) { return s.length; }
>   void main () { assert(test(null) == 0); }
> 
> compiling this gives the following error: "no property 'length' for type
> 'typeof(null)'"
> 
> while i see why it complains, i think compiler should convert `null` to
> empty slice here, as i clearly specified the type i want to accept. sure, i
> can workaround this with explicit template constrain... but this is what i
> wanted to avoid in the first place!

The spec [1] isn't clear on this.

The currently implemented behavior of a constraint `T : Foo` is to restrict T
to those types that implicitly convert to Foo, but T is still set as usual
(from an explicit argument or from IFTI).

The behavior you suggest would make it so that T is always set to Foo.
Obviously, this would be a breaking change.

Both approaches are compatible with the examples in the spec, as far as I see.

In your example, you could of course just take a const(char)[] directly,
without any template parameters. So that isn't a good motivating example to
change the behavior.

In favor of the current behavior there is std.exception.assertThrown [2], for
example. It uses a specialization to restrict T to Throwable, but it uses the
(more restricted) passed T in its checks.

> also, another bug with the same `test`:
>   assert(test([]) == 0);
> 
> this time compiler says: "
> template z01.test cannot deduce function from argument types !()(void[]),
> candidates are..."
> 
> i think compiler should convert empty slice to the `immutable(char)[]` here.

Agreed. The empty array literal [] should behave like null and the empty string
literal "" here. I guess this means we need a typeof([]) that implicitly
converts to any T[] (unlike void[]).


[1] http://dlang.org/spec/template.html#parameters_specialization
[2] http://dlang.org/phobos/std_exception.html#.assertThrown

--

Re: compilation error with shared ReadWriteMutex

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/30/16 8:18 AM, jj75607 wrote:

I wrote shared class with rwmutex

  import core.sync.rwmutex;
  shared class Shared
  {
  ReadWriteMutex rwmutex;
  int[] items;

  this()
  {
  rwmutex = new ReadWriteMutex();
  }
  }

But it fails with:

  Error: cannot implicitly convert expression (new
ReadWriteMutex(cast(Policy)1)) of type core.sync.rwmutex.ReadWriteMutex
to shared(ReadWriteMutex)

I add `shared' keyword to the `rwmutex' variable

  shared class Shared
  {
  shared(ReadWriteMutex) rwmutex;


You don't need to mark this shared, because the entire class is shared, 
all members are implicitly marked shared.



  int[] items;

  this()
  {
  rwmutex = new shared(ReadWriteMutex)();


This is what fixes the original compilation error. You are constructing 
a shared object, so it can be correctly assigned to the shared member.



  }
  }

And got another compilation error:

  Error: non-shared method core.sync.rwmutex.ReadWriteMutex.this is not
callable using a shared object


Yep. Nothing in core.sync can be marked shared. Ironic, isn't it?

In seriousness, someone need to work on getting core.sync shareable. The 
library was written way before shared was a thing (it's actually from D1 
days). It makes no sense that Mutexes and the like cannot be shared. 
That is their core purpose.



How can I use shared class with mutex correctly?


casting:

rwmutex = cast(shared) new ReadWriteMutex();

...

(cast()rwmutex).lock(); // casts away all attributes.

Note, beware of removing const/immutable attributes (i.e. don't do this 
in functions marked const or immutable).


-Steve

Re: opEquals on shared object

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/30/16 6:26 AM, jj75607 wrote:

Hello!

I need to overload opEquals on shared class C

shared class C
{
override bool opEquals(Object o) { return false; }
}

But compilation fails with the message:
Error: function f700.C.opEquals does not override any function, did you
mean to override 'object.Object.opEquals'?

What am I doing wrong?


Object.opEquals is not marked shared. You can't override a non-shared 
method with a shared one.


You need to remove override.

But... unfortunately, this may not work in practice. The opEquals 
handling for objects is pretty much screwed unless you have unshared 
mutable objects. I think it may work for const objects, but not in a 
good way.


-Steve

Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored

[qznc via Digitalmars-d]

On Thursday, 30 June 2016 at 11:40:38 UTC, Mathias Lang wrote:
2016-06-30 11:09 GMT+02:00 qznc via Digitalmars-d < 
digitalmars-d@puremagic.com>:




I don't see this properly documented [0].

It seems that imports in mixins are not visible even if 
declared public? This means mixin imports are special?


The issue also features a "protected imported". I guess nobody 
knows what that is supposed to mean?


[0] https://dlang.org/spec/module.html#ImportDeclaration



There's an issue for that ( 
https://issues.dlang.org/show_bug.cgi?id=16004 ) and an 
associated P.R. ( https://github.com/dlang/dlang.org/pull/1325 
). So far I haven't got any feedback on it. There's not much I 
can do short of pinging people.


I looked through the PR, but I guess Martin Nowak has to ok it.

Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored

[captaindet via Digitalmars-d]

Author here. I originally thought the issue was that an 'imported' scope
imports are not considered anymore.


this is exactly what i was/am afraid of ...[see below]


As Walter explained in this issue and in
https://issues.dlang.org/show_bug.cgi?id=15966 this behaviour changed to
prevent hijacking and is intended.


15966 is about "protected" and the very example in 15925 uses a 
protected import too. not sure about the protected story. the scary 
thing is that the example in issue 15925 also fails to work if it is a 
public import inside the mixin template. does this mean mixin templates 
now have no way of adding imports to the scope they are mixed in? this 
is really bad news for meta programming. i would have to do this with 
ugly string mixins from now on, or is this unintended behavior for 
string mixins as well?


or is all this a special case for classes? how about at module level? 
where is all this mentioned in the specs?


this leaves me quite confused.

compilation error with shared ReadWriteMutex

[jj75607 via Digitalmars-d-learn]

I wrote shared class with rwmutex

  import core.sync.rwmutex;
  shared class Shared
  {
  ReadWriteMutex rwmutex;
  int[] items;

  this()
  {
  rwmutex = new ReadWriteMutex();
  }
  }

But it fails with:

  Error: cannot implicitly convert expression (new 
ReadWriteMutex(cast(Policy)1)) of type 
core.sync.rwmutex.ReadWriteMutex to shared(ReadWriteMutex)


I add `shared' keyword to the `rwmutex' variable

  shared class Shared
  {
  shared(ReadWriteMutex) rwmutex;
  int[] items;

  this()
  {
  rwmutex = new shared(ReadWriteMutex)();
  }
  }

And got another compilation error:

  Error: non-shared method core.sync.rwmutex.ReadWriteMutex.this 
is not callable using a shared object


How can I use shared class with mutex correctly?

Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored

[Mathias Lang via Digitalmars-d]

2016-06-30 11:09 GMT+02:00 qznc via Digitalmars-d <
digitalmars-d@puremagic.com>:

>
> I don't see this properly documented [0].
>
> It seems that imports in mixins are not visible even if declared public?
> This means mixin imports are special?
>
> The issue also features a "protected imported". I guess nobody knows what
> that is supposed to mean?
>
> [0] https://dlang.org/spec/module.html#ImportDeclaration
>

There's an issue for that ( https://issues.dlang.org/show_bug.cgi?id=16004
) and an associated P.R. ( https://github.com/dlang/dlang.org/pull/1325 ).
So far I haven't got any feedback on it. There's not much I can do short of
pinging people.

[Issue 16222] New: template failed to infer/coerce types for instantiation

[via Digitalmars-d-bugs]

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

  Issue ID: 16222
   Summary: template failed to infer/coerce types for
instantiation
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

consider the following code:

  auto test(T : const(char)[]) (T s) { return s.length; }
  void main () { assert(test(null) == 0); }

compiling this gives the following error: "no property 'length' for type
'typeof(null)'"

while i see why it complains, i think compiler should convert `null` to empty
slice here, as i clearly specified the type i want to accept. sure, i can
workaround this with explicit template constrain... but this is what i wanted
to avoid in the first place!


also, another bug with the same `test`:
  assert(test([]) == 0);

this time compiler says: "
template z01.test cannot deduce function from argument types !()(void[]),
candidates are..."

i think compiler should convert empty slice to the `immutable(char)[]` here.

--

Re: Does a Interpretation-Engine fit in phobos ?

[Seb via Digitalmars-d]

On Thursday, 30 June 2016 at 11:09:10 UTC, ketmar wrote:

On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
Off-topic: Is it possible/feasible/desirable to let dmd use 
dub packages?


please, no. not everybody out there is dub fan.


Off-topic:

@ketmar: if it's on dub (d's official package manager), it's 
easily visible to others and searchable.
Moreover most people prefer to have a dependency manager to 
download the sources and compile it. Can't you just grab the 
referenced source repository manually?


Please open a new thread if that doesn't work for you ;-)

Re: EnumToFlags

[Basile B. via Digitalmars-d-learn]

On Thursday, 30 June 2016 at 02:39:22 UTC, JS wrote:
I created a type that makes working with flags much easier. 
Please review for issues and enhancements. It would be nice to 
simplify the value size code.


[...]


You can look at this, it's more or less the same concept:

https://github.com/BBasile/iz/blob/master/import/iz/enumset.d#L226

Two things that important:
- enum members are not always integer numbers.
- enum used as flags is only fast when members values are 
consecutives.


I've recently discovered that it can even be used to make UDAs, 
what a "yeah" ;)

Re: Call to Action: making Phobos @safe

[Steven Schveighoffer via Digitalmars-d]

On 6/29/16 4:57 PM, Walter Bright wrote:

On 6/29/2016 10:25 AM, Atila Neves wrote:

On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:

On 6/25/2016 3:44 PM, Walter Bright wrote:

4. Add @safe to the unittest


A unittest that is deliberately unsafe should be annotated with @system.
Meaning that any un-annotated unittest needs corrective action one
way or the
other.


What about existing tests that are marked @trusted?


Marking a unittest as @trusted seems pointless.



I would further say -- if you see a @trusted unit test, whoever wrote it 
doesn't understand the point of @trusted. Be sure and check the code it 
is testing too, and file bugs if appropriate.


-Steve

Re: Does a Interpretation-Engine fit in phobos ?

[ketmar via Digitalmars-d]

On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
Off-topic: Is it possible/feasible/desirable to let dmd use dub 
packages?


please, no. not everybody out there is dub fan.

Re: static if enhancement

[Steven Schveighoffer via Digitalmars-d]

On 6/29/16 11:40 AM, Wyatt wrote:

On Friday, 24 June 2016 at 18:27:07 UTC, Steven Schveighoffer wrote:

void fun(T)(T obj)
{
static if (!hasMember(T, "gun")) throw new Exception("No gun");
obj.gun;
}

Call with something that doesn't have a gun member, and even without
the reachability warnings (no -w switch), it doesn't compile. However,
with an else clause, it would compile.


I might be stepping on a land mine by bringing it up, but isn't this
sort of thing what contracts are for?


No landmines here, but no, that isn't what contracts are for. Perhaps 
you mean constraints?


A constraint will prevent compilation vs. allowing compilation but 
emitting a failure at runtime. I agree this is a better mechanism, or 
just plain allow the compiler to make a proper error when you call gun.


It's not so much that this example is meant be a justification, but more 
an explanation of what the enhancement will do.


In any case, I've drifted back towards being against this change. It 
leaves the compilability of code up to the quality of the compiler's 
flow analysis.


-Steve

OT: some C++ insights (just for fun)

[Ola Fosheim Grøstad via Digitalmars-d]

From the slides:
https://codeplay.com/public/uploaded/filehost/0cbdaf_c++17post-oulu2016.pdf

«
Doesn’t everybody know that C++ is great?

No, just from last week
• “C++ is a bloated old language”
• “Why can’t they let good enough alone?”
• “We used D because C++ doesn’t have compile time functions” 
(GPSE paper)
• “We built a library to help people coming from ordinary 
languages such as Haskell,

Python, and Ruby” (Columbia University class)
»

What is the GPSE paper he mentioned?

NanoVG and OUI ports

[ketmar via Digitalmars-d-announce]

yes, it's me again. hello. this time i ported NanoVG[1] drawing 
library (only OpenGL2 backend) and OUI[2] intermediate UI 
library. they require some modules from Adam's arsd library[3] to 
work -- mostly simpledisplay for screen setup and minimal OpenGL 
bindings, and arsd.png to load png images. one can also use my 
jpeg decoder to add jpeg support.


ttf rendering powered by FreeType: feel free to take Derelict 
bindings, and change one import in "fontstash.d".


this time the things are not single-file ports, though.

have fun and happy hacking.

ah, i forgot link to ports! here they are: NanoVG and OUI[4], 
demo[5].


p.s. default dmd flags does ~35 FPS on OUI sample. but dmd -O, 
even without inlining, does solid 60 FPS.



[1] https://github.com/memononen/nanovg
[2] https://bitbucket.org/duangle/oui-blendish/overview
[3] https://github.com/adamdruppe/arsd
[4] http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg
[5] http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo