Re: D doesn't read the first character of a file (reads everything but the first chararacter) with either read() or readText()

2017-07-18 Thread Sebastien Alaiwan via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 02:21:59 UTC, Enjoys Math wrote:


DMD32 D Compiler v2.074.1

import std.file;

void main() {
   string bigInput = readText("input.txt");
}

The file is 7 MB of ascii text, don't know if that matters...

Should I upgrade versions?


Could you please share the first 32-bytes (in hex) of your file? 
Like:

$ hexdump -C input.txt



[Issue 13211] Expand macros in comments within code sections

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13211

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||ddoc
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12383
   Severity|enhancement |normal

--- Comment #3 from Vladimir Panteleev  ---
Whether or not macros should be expanded in code blocks at all, the current
behaviour is at least inconsistent, so there is certainly a bug here.

--


[Issue 12383] dlang.org operator overloading text with DDoc macro.

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12383

Vladimir Panteleev  changed:

   What|Removed |Added

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

--


Re: Is it possible to generate a pool of random D or D inline assembler programs, run them safely?

2017-07-18 Thread Sebastien Alaiwan via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 17:35:17 UTC, Enjoys Math wrote:
Without them crashing the app running them?  Say by wrapping 
with try / catch?


and, most probably a timeout, as  you're certainly going to run 
into infinite loops.



Reason is so I don't have to make my own VM.


Why not reuse an existing one? Some of them are very simple:
https://github.com/munificent/wren

It will be a lot easier than trying to generate random 
*compilable* D programs ; and will avoid requiring a compilation 
step in your mutation loop (I know the D compiler is fast, but 
still :-) ).





[Issue 12648] Array operation return type

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12648

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--


[Issue 2347] opIs is missing

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=2347

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Hardware|x86 |All
 Resolution|--- |WONTFIX
 OS|Linux   |All

--- Comment #4 from Vladimir Panteleev  ---
(In reply to Stewart Gordon from comment #1)
> I think that having opIs is philosophically wrong.  The whole point of is is
> to override any type-defined equality operator by forcing a byte-for-byte
> comparison.  There are probably plenty of template libraries and the like
> that rely on this.

Agreed. Currently `is` provides a guarantee that it compares bits and will
never invoke any other user-defined comparison mechanisms. This applies to
user-defined types (structs, classes) as well as floating-point types (where
x==x may not always be true due to NaNs). An opIs operator would break that
guarantee.

User-defined smart references and slices could instead expose identity
comparison via a ".ptr" property, which could then be compared using `==` or
`is`.

Also, I understand that such language additions would need to be done via a DIP
today.

@Andrei: I'll close this (also because this issue is close to a decade old),
but please reopen if you disagree.

--


[Issue 7464] Better Error Message When Using S.tupleof within S

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=7464

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #2 from Vladimir Panteleev  ---
FWIW, the code compiled before https://github.com/dlang/dmd/pull/595.

--


[Issue 7190] Tuple length incorrect

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=7190

Vladimir Panteleev  changed:

   What|Removed |Added

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

--


[Issue 10540] variable used before set for empty static arrays, with -inline -O

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10540

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #2 from Vladimir Panteleev  ---
No longer reproducible after https://github.com/dlang/dmd/pull/3467, closing.
Please reopen if you can still provide a reproducible test case.

--


[Issue 7953] DMD Error: variable r used before set when compiling with -O

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=7953

Vladimir Panteleev  changed:

   What|Removed |Added

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

--


[Issue 12212] Static array assignment makes slice implicitly

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12212

Vladimir Panteleev  changed:

   What|Removed |Added

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

--


[Issue 10540] variable used before set for empty static arrays, with -inline -O

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10540

Vladimir Panteleev  changed:

   What|Removed |Added

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

--


[Issue 15537] Private function is not accessible from other module when compiling with -debug flag

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15537

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Vladimir Panteleev  ---
The reason why this doesn't compile with -debug is mentioned briefly in the
assumeSorted documentation:

> In debug mode, a few random elements of r are checked for sortedness. 

-- https://dlang.org/library/std/range/assume_sorted.html

Thus, std.range is failing to use your private compare function when attempting
to perform this sortedness check.

Note that even if the code compiled without -debug, the result would still not
be useful, as you would not be able to pass the resulting SortedRange e.g. to
std.algorithm.searching.find. It would fail with the same problem, being unable
to access your private opCmp function.

Whether symbols passed by alias parameter should be exempted from visibility
checks is a separate matter.

You can work around this problem by making the comparison function public, but
also wrapping it inside a private struct:

private struct Hidden
{
public static bool myCmp(Data a, Data b) {
return a[0] < b[0];
}
}

auto bar() {
return [Data(1, "one"), Data(2, "two")].assumeSorted!(Hidden.myCmp);
}

--


[Issue 15537] Private function is not accessible from other module when compiling with -debug flag

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15537

Vladimir Panteleev  changed:

   What|Removed |Added

  Component|dmd |phobos

--


Re: proposed @noreturn attribute

2017-07-18 Thread Walter Bright via Digitalmars-d

On 7/18/2017 7:14 PM, Nicholas Wilson wrote:
It describe the behaviour of the function: I think it is neither necessary nor a 
good idea to express it as a type. assert(0) is already accepted as a valid 
return statement of any type.


I can't continue this without being repetitive, so we'll just have to disagree.


The backends for DMD, LDC and GDC would not be affected at all by the addition 
of a bottom type to the front end, and it would be trivial for the glue code 
to add the noreturn attribute for functions that return the bottom type.


Said glue would be unnecessary with an attribute *that already exists*.


In the glue code, replace:

if (function attribute is 'noreturn')
set backend attribute to 'noreturn';

with:

if (function return type is 'bottom')
set backend attribute to 'noreturn';
set backend function return type to 'void';

and it should be ready to rock :-)


[Issue 697] No const folding on asm db,dw, etc

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=697

--- Comment #9 from Vladimir Panteleev  ---
OK, I got the Mercurial server running again, and uploaded a copy of the
repository to GitHub. The files are here:

https://github.com/CyberShadow/dstress/tree/master/run/a

Still, looking at these test cases, it's still questionable whether there is
much value in them. For instance, asm_di_02_A.d has:

const short x = 0x40404040;

This is clearly invalid code.

The `db 1+2` part of this issue is a valid enhancement request, but should be
filed separately. If you have a need for the feature in your programs, please
file a new enhancement request.

--


Re: proposed @noreturn attribute

2017-07-18 Thread Nicholas Wilson via Digitalmars-d

On Wednesday, 19 July 2017 at 01:52:30 UTC, Walter Bright wrote:
I know how noreturn attributes work - I implemented them 
decades ago in DMC and DMC++. They are supported by the DMD 
optimizer and back end.


But they are a hack to the type system, and I suggest an 
unnecessary one.


It describe the behaviour of the function: I think it is neither 
necessary nor a good idea to express it as a type. assert(0) is 
already accepted as a valid return statement of any type.


The backends for DMD, LDC and GDC would not be affected at all 
by the addition of a bottom type to the front end, and it would 
be trivial for the glue code to add the noreturn attribute for 
functions that return the bottom type.


Said glue would be unnecessary with an attribute *that already 
exists*.


Re: proposed @noreturn attribute

2017-07-18 Thread Walter Bright via Digitalmars-d

On 7/18/2017 5:54 PM, Nicholas Wilson wrote:

There is just something fundamentally wrong with:
@noreturn int foo();
I would understand it to mean that if it were to return, foo would return an int 
but it is undefined behaviour for foo to dynamically return.


That's the C++ behavior. I know we are all accustomed to it and hence think it 
is intuitive, but it isn't. I know I've had a hard time breaking free of this 
sort of thinking, having been so deeply immersed in C++ for so long.



returning a value yet not returning. It smacks of "the language designer(s) 
are idiots." It winds up complicating things like:


auto x = a ? b : foo();

What is the type of x? @noreturn means a special case. A proper bottom type 
means it is not a special case.


int.


And if b is of type `T`? It doesn't make sense to have to give a type to 
something that does not return. (@noreturn functions are usually typed as 
returning `void` anyway, but that still doesn't make much sense.)


I know how noreturn attributes work - I implemented them decades ago in DMC and 
DMC++. They are supported by the DMD optimizer and back end.


But they are a hack to the type system, and I suggest an unnecessary one.

The backends for DMD, LDC and GDC would not be affected at all by the addition 
of a bottom type to the front end, and it would be trivial for the glue code to 
add the noreturn attribute for functions that return the bottom type.


[Issue 17663] header generation (-H) is broken with public override of private default

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17663

Vladimir Panteleev  changed:

   What|Removed |Added

   Severity|enhancement |normal

--


[Issue 697] No const folding on asm db,dw, etc

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=697

--- Comment #8 from Vladimir Panteleev  ---
Stewart, "someone" is not enough. For a bug report to be useful, anyone should
be able to reproduce the issue. There is very little value in keeping open a
bug report where you have to go on an archaeology quest to find crucial
details.

Since you still have the files, please attach them here (or to a new bug
report)?

--


Re: proposed @noreturn attribute

2017-07-18 Thread Nicholas Wilson via Digitalmars-d

On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote:
The issue here (for me) is to have a type system that matches 
type systems used in type theory. D already has strong 
abilities to do type calculus. Instead of inventing our own 
whackadoodle scheme, one hack at a time, why not match existing 
type calculus? Then, attempts to do type calculus in D will 
work as worked out by type theory.


Or, we could go with the C++ approach which historically is to 
add an ad-hoc solution for an existing problem, and then 
another ad-hoc solution for the whacky effects that turned out 
to have, rinse, repeat. (Look at all the different ways to do 
type deduction, a horrifying consequence. Or function 
overloading, which started with complex special cases, then 
changed to partial ordering for special cases.)


There is just something fundamentally wrong with:

@noreturn int foo();


I would understand it to mean that if it were to return, foo 
would return an int but it is undefined behaviour for foo to 
dynamically return.


returning a value yet not returning. It smacks of "the language 
designer(s) are idiots." It winds up complicating things like:


auto x = a ? b : foo();

What is the type of x? @noreturn means a special case. A proper 
bottom type means it is not a special case.


int. @noreturn need not pollute the type, given the use cases for 
@noreturn. Namely to document that the function does not 
dynamically return and aid the compiler in optimisation (are 
there any other uses?). `assert(0);` is already accepted in the 
front end as an acceptable return "value" for any type e.g. in


Bar foo(int x)
{
foreach (e; data[])
 if (e.x == x)
  return e;
assert(0);
}

The language semantics and compiler internals should be simpler 
and cleaner by using accepted type theory.


Not for LDC or GDC. They already have the ability to signal to 
their backends that a function does not dynamically return.


as I have posted before, one can do (in core.attribute),

enum __noreturn;

version(LDC)
{
import ldc.attributes : llvmAttr;
alias noreturn = AliasSeq!(llvmAttr("noreturn"),__noreturn);
}
else version(GNU)
{
import gcc.attribute : llvmAttr;
alias noreturn = AliasSeq!(attribute("noreturn"),__noreturn);
}
else // DMD
{
alias noreturn = __noreturn;
}

for a complete implementation for LDC and GDC, and DMD can do 
whatever it needs to with the presence of __noreturn, including 
fronted semantic analysis.




Re: proposed @noreturn attribute

2017-07-18 Thread via Digitalmars-d

On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote:

On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote:

But the point is that so much time and effort is being spent on
discussing and designing a feature that you have admitted 
yourself to be
"rarely used". As a disinterested bystander I find it somewhat 
amusing
(and sad) to see so much over-engineering of an overly-complex 
system
involving a new basic type in the language, which in turn 
entails all
sorts of corner cases in how it will interact with existing 
types and
constructs, not to mention the implementation complexities 
that will be
involved to pull it off -- all for what?  Just to be able to 
say
"function F doesn't return".  Seems like disproportionate 
effort for

only marginal returns (har har).


The issue here (for me) is to have a type system that matches 
type systems used in type theory. D already has strong 
abilities to do type calculus. Instead of inventing our own 
whackadoodle scheme, one hack at a time, why not match existing 
type calculus? Then, attempts to do type calculus in D will 
work as worked out by type theory.


Or, we could go with the C++ approach which historically is to 
add an ad-hoc solution for an existing problem, and then 
another ad-hoc solution for the whacky effects that turned out 
to have, rinse, repeat. (Look at all the different ways to do 
type deduction, a horrifying consequence. Or function 
overloading, which started with complex special cases, then 
changed to partial ordering for special cases.)



[...]


Agreed. Discovered vs invented as Philip Wadler classifies the 
two approaches in his talk: 
https://www.youtube.com/watch?v=IOiZatlZtGU, which I highly 
recommend watching.


Re: newCTFE Status July 2017

2017-07-18 Thread Seb via Digitalmars-d

On Tuesday, 18 July 2017 at 19:23:56 UTC, Stefan Koch wrote:

On Tuesday, 18 July 2017 at 19:11:37 UTC, H. S. Teoh wrote:


Shouldn't there be a way to reduce the test case so that you 
don't have to look through 300 temporaries?



Yes.
However, there is not automated way to reduce it.
So to find the source-code which actually leads to the 
mis-compiled part.

I still have to consider an awful lot of code :)


Why can't you use DustMite? It's an amazing tool!
https://github.com/CyberShadow/DustMite/wiki


Re: Is it possible to generate a pool of random D or D inline assembler programs, run them safely?

2017-07-18 Thread Adam D. Ruppe via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 17:35:17 UTC, Enjoys Math wrote:
Without them crashing the app running them?  Say by wrapping 
with try / catch?


Run them in a separate process, so it can die independently.



Re: New library: open multi-methods

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 22:41:13 UTC, Ali Çehreli wrote:

On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote:

Hello,

TL;DR: see here 
https://github.com/jll63/methods.d/blob/master/README.md


Added D to the Wikipedia entry, which can be expanded. :)

  https://en.wikipedia.org/wiki/Multiple_dispatch

Ali


Haha that settles it then, openmethods it is! I'll rename the 
repo and upload to the registry momentarily.


Re: New library: open multi-methods

2017-07-18 Thread Ali Çehreli via Digitalmars-d-announce

On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote:

Hello,

TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md


Added D to the Wikipedia entry, which can be expanded. :)

  https://en.wikipedia.org/wiki/Multiple_dispatch

Ali



Re: proposed @noreturn attribute

2017-07-18 Thread Timon Gehr via Digitalmars-d

On 18.07.2017 23:35, Moritz Maxeiner wrote:


Could you explain why `return foo();` is even legal for a `void foo() 
{}`?


Because the ad-hoc decision to make void a type that is not really a 
type leads to unnecessary friction, and this exceptional rule removes 
the friction in one common special case.


I wasn't aware of it before and the fact that you can 
(syntactically) return the non-existent return value of `foo` raises 
cognitive dissonance flags for me. I imagine there's a type system reason?


There should be. foo's return type could be a unit type, with just one 
value. Then foo does have a return value, but it is always the same and 
so does not need to be explicitly tracked.


[Issue 16079] memoize should cache objects too

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16079

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

https://github.com/dlang/phobos/commit/9e58ecab2aa6eb2d800d1e7e0635f7eee1a774aa
Fix issue 16079 - memoize should work with arrays and objects

https://github.com/dlang/phobos/commit/aefb5892a3ee1dbbb3433db951e261f3a1b5635c
Merge pull request #4367 from wilzbach/fix_16079

Fix issue 16079 - memoize should work with arrays and objects

--


Re: proposed @noreturn attribute

2017-07-18 Thread Moritz Maxeiner via Digitalmars-d

On Tuesday, 18 July 2017 at 21:45:27 UTC, Adam D. Ruppe wrote:

On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote:
Could you explain why `return foo();` is even legal for a 
`void foo() {}`?


Suppose you are writing a template function that forwards:

auto forward(alias fun, T...)(T args) {
   return fun(args);
}


It just saves you from having to static if(fun returns void).


That's a good pragmatic (syntactic sugar) reason, thanks.


Re: New library: open multi-methods

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 21:20:04 UTC, jmh530 wrote:

On Tuesday, 18 July 2017 at 21:16:11 UTC, jmh530 wrote:


I may not have been clear enough. My ideal solution wouldn't 
make any changes to that densematrix.d file, just the 
interface. So I don't have any issue with the matrix modules 
doing the math and the app doing the printing.




Well, I suppose the matrix interface would be saying that it 
can print, so maybe not as split up as you would like. While 
you could define a separate interface for printing, that would 
require a change to densematrix.


Exactly. Orthogonality is essential for good composition, that is 
the reason why OOP - well, the OOP that follows the 
Simula/Smalltalk tradition - failed so badly. CLOS got it right 
40 years ago; Simula, Smalltalk, C++, Java, etc they all got it 
wrong.


Re: An Issue I Wish To Raise Awareness On

2017-07-18 Thread Marco Leise via Digitalmars-d
Am Tue, 18 Jul 2017 18:10:58 +
schrieb Atila Neves :
> Now I've read your post properly: there is only one destructor. 
> With the fix I mentioned, just don't defined the `shared` 
> version, there's no need to. Postblit is still a problem, however.
> 
> Atila

The issue is wider than just `shared` by the way:
https://issues.dlang.org/show_bug.cgi?id=13628
Some may jump to say that an immutable struct can't be
destructed, but my perspective here is that immutable only
applies to what the compiler can introspect. A file descriptor
or an opaque struct pointer from a C API are just flat values
and escape the compiler. They can be stored in an immutable
struct and still need `close()` called on them.
Layman's head-const :p

-- 
Marco


Re: proposed @noreturn attribute

2017-07-18 Thread Walter Bright via Digitalmars-d

On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote:

But the point is that so much time and effort is being spent on
discussing and designing a feature that you have admitted yourself to be
"rarely used". As a disinterested bystander I find it somewhat amusing
(and sad) to see so much over-engineering of an overly-complex system
involving a new basic type in the language, which in turn entails all
sorts of corner cases in how it will interact with existing types and
constructs, not to mention the implementation complexities that will be
involved to pull it off -- all for what?  Just to be able to say
"function F doesn't return".  Seems like disproportionate effort for
only marginal returns (har har).


The issue here (for me) is to have a type system that matches type systems used 
in type theory. D already has strong abilities to do type calculus. Instead of 
inventing our own whackadoodle scheme, one hack at a time, why not match 
existing type calculus? Then, attempts to do type calculus in D will work as 
worked out by type theory.


Or, we could go with the C++ approach which historically is to add an ad-hoc 
solution for an existing problem, and then another ad-hoc solution for the 
whacky effects that turned out to have, rinse, repeat. (Look at all the 
different ways to do type deduction, a horrifying consequence. Or function 
overloading, which started with complex special cases, then changed to partial 
ordering for special cases.)


There is just something fundamentally wrong with:

@noreturn int foo();

returning a value yet not returning. It smacks of "the language designer(s) are 
idiots." It winds up complicating things like:


auto x = a ? b : foo();

What is the type of x? @noreturn means a special case. A proper bottom type 
means it is not a special case.



I recall that Rust initially did @noreturn as a special case, and later replaced 
that with a bottom type and integrated it into the type system. I understand 
that this had a positive ripple effect, such as reducing special cases in user 
generic code.


Noreturn functions are just a happy fallout of doing this correctly in the first 
place. The language semantics and compiler internals should be simpler and 
cleaner by using accepted type theory.


Re: proposed @noreturn attribute

2017-07-18 Thread Adam D. Ruppe via Digitalmars-d

On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote:
Could you explain why `return foo();` is even legal for a `void 
foo() {}`?


Suppose you are writing a template function that forwards:

auto forward(alias fun, T...)(T args) {
   return fun(args);
}


It just saves you from having to static if(fun returns void).


Re: proposed @noreturn attribute

2017-07-18 Thread Moritz Maxeiner via Digitalmars-d

On Tuesday, 18 July 2017 at 20:49:56 UTC, Timon Gehr wrote:

On 18.07.2017 20:46, Yuxuan Shui wrote:

On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote:

On 18.07.2017 14:19, Stefan Koch wrote:

[...]


D has a C-inspired first-order type system, so it is not 
necessarily crucial to have it in D. (The reason I got 
involved in this thread is that it was proposed to add Bottom 
as a type that is not really a type; 'void' is annoying 
enough as the 'null' of types. We don't really need another 
one of those.)


[...]


What about void?


You can't have a value of type void, but it is not empty either.

For example, this means that the following transformation is 
not always valid:


return foo();


Could you explain why `return foo();` is even legal for a `void 
foo() {}`? I wasn't aware of it before and the fact that you can 
(syntactically) return the non-existent return value of `foo` 
raises cognitive dissonance flags for me. I imagine there's a 
type system reason?




Re: Appending static arrays

2017-07-18 Thread Jack Applegame via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 12:39:01 UTC, Stefan Koch wrote:

whhhahhh template bloat

Yes, and also very slow. :)



Re: Mixin function names

2017-07-18 Thread Moinak Bhattacharrya via Digitalmars-d

On Tuesday, 18 July 2017 at 21:29:05 UTC, Timon Gehr wrote:

On 18.07.2017 23:28, Moinak Bhattacharrya wrote:

On Tuesday, 18 July 2017 at 21:22:47 UTC, Timon Gehr wrote:

On 18.07.2017 22:57, Moinak Bhattacharrya wrote:
Is it possible to mixin function names? IE something like 
this:


template strFunc(string s){
 int mixin(s)(int a){
 return a+1;
 }
}
...


No.


If not, is something like this being looked at?


The suggestion has been made, but there was no extensive 
discussion so far.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers



That's the DIP for static foreach. Is there a separate DIP for 
mixin identifiers?


Not yet.


:( I might look into making one, then. This feature would scratch 
a rather sizable itch.


[Issue 15933] GDC support for core.cpuid

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15933

Marco Leise  changed:

   What|Removed |Added

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

--- Comment #1 from Marco Leise  ---
This was fixed in 2.072 with commit
https://github.com/dlang/druntime/commit/c230cd4d52de1b05d15f61f6fb6d0e74b084f5c9pidgi
as far as I understand the tag range given by GitHub.

--


Re: Mixin function names

2017-07-18 Thread Timon Gehr via Digitalmars-d

On 18.07.2017 23:28, Moinak Bhattacharrya wrote:

On Tuesday, 18 July 2017 at 21:22:47 UTC, Timon Gehr wrote:

On 18.07.2017 22:57, Moinak Bhattacharrya wrote:

Is it possible to mixin function names? IE something like this:

template strFunc(string s){
 int mixin(s)(int a){
 return a+1;
 }
}
...


No.


If not, is something like this being looked at?


The suggestion has been made, but there was no extensive discussion so 
far.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers 



That's the DIP for static foreach. Is there a separate DIP for mixin 
identifiers?


Not yet.


Re: Mixin function names

2017-07-18 Thread Moinak Bhattacharrya via Digitalmars-d

On Tuesday, 18 July 2017 at 21:22:47 UTC, Timon Gehr wrote:

On 18.07.2017 22:57, Moinak Bhattacharrya wrote:

Is it possible to mixin function names? IE something like this:

template strFunc(string s){
 int mixin(s)(int a){
 return a+1;
 }
}
...


No.


If not, is something like this being looked at?


The suggestion has been made, but there was no extensive 
discussion so far.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers


That's the DIP for static foreach. Is there a separate DIP for 
mixin identifiers?


Re: Adding flags to dub build

2017-07-18 Thread Moritz Maxeiner via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 20:12:13 UTC, Jean-Louis Leroy wrote:
On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat 
wrote:
On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy 
wrote:

Hi,

I want to add a few flags while building with dub. I tried:

DFLAGS='-d-version=explain' dub test ...

...but DFLAGS does not seem to be honored. In fact I wouldn't 
mind adding a builtType to my dub.sdl (but then will it be 
inherited by the subpackages) but I don't see how to specify 
flags there either...maybe because it tries to hide 
variations in compiler switches?


J-L


Use "dflags" or "lflags" (linker)


It doesn't work either...


It's a build setting [1], not a command line option, you set it 
in the package file (dub.json/dub.sdl)...


https://code.dlang.org/package-format?lang=json#build-settings


Re: New library: open multi-methods

2017-07-18 Thread jmh530 via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 21:16:11 UTC, jmh530 wrote:


I may not have been clear enough. My ideal solution wouldn't 
make any changes to that densematrix.d file, just the 
interface. So I don't have any issue with the matrix modules 
doing the math and the app doing the printing.




Well, I suppose the matrix interface would be saying that it can 
print, so maybe not as split up as you would like. While you 
could define a separate interface for printing, that would 
require a change to densematrix.


Re: Mixin function names

2017-07-18 Thread Timon Gehr via Digitalmars-d

On 18.07.2017 22:57, Moinak Bhattacharrya wrote:

Is it possible to mixin function names? IE something like this:

template strFunc(string s){
 int mixin(s)(int a){
 return a+1;
 }
}
...


No.


If not, is something like this being looked at?


The suggestion has been made, but there was no extensive discussion so far.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers


Re: New library: open multi-methods

2017-07-18 Thread jmh530 via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 19:22:38 UTC, Jean-Louis Leroy wrote:


Look at 
https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d and https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d They know nothing about printing. They don't want to. The matrix modules do math, the app does printing.


J-L


I may not have been clear enough. My ideal solution wouldn't make 
any changes to that densematrix.d file, just the interface. So I 
don't have any issue with the matrix modules doing the math and 
the app doing the printing.


For instance, consider the traits in Rust
https://doc.rust-lang.org/book/first-edition/traits.html
My idea is like making the interfaces in D similar to the traits 
in Rust (or at least having the option to do something similar 
with them). Your @method void _print(Matrix m) would be similar 
to impl print for Matrix in Rust.


Nevertheless, I get that it may be a difficult thing to implement.


Re: Mixin function names

2017-07-18 Thread Adam D. Ruppe via Digitalmars-d
On Tuesday, 18 July 2017 at 20:57:51 UTC, Moinak Bhattacharrya 
wrote:

Is it possible to mixin function names? IE something like this:


Only if you mixin the entire function.

But what I like to do is to write the function with some internal 
name, then do `mixin("alias "~ new_name ~ " = 
your_internal_name;");` so it is available as new name but still 
written normally.


[Issue 17663] New: header generation (-H) is broken with public override of private default

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17663

  Issue ID: 17663
   Summary: header generation (-H) is broken with public override
of private default
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Example breakage:

// test_di_gen.d:
private:
public struct Export {}

dmd -H generates the following di file:

// D import file generated from 'test_di_gen.d'
private public struct Export
{
}

Needless to say "private public" does not compile.

background: I use "private:" in beginning of all my modules/structs to reverse
the default - I want my exports to be explicit and narrow.

--


Re: Building DMD on OpenBSD

2017-07-18 Thread Anonymous via Digitalmars-d

On Tuesday, 18 July 2017 at 05:11:30 UTC, Kai Nacke wrote:
In master there is already some OpenBSD support. Some time ago 
I worked on druntime support but I still need to finish this. 
Mostly there is nothing magic here - just translating the 
header files. The only non-obvious work is required for the 
module/shared library stuff (in rt.sections). If there is an 
OpenBSD expert around who can help here it would be nice.


Maybe talk to OpenBSD porters on their mailing list. Ill 
put my stuff on github as soon as I can.




Re: Mixin function names

2017-07-18 Thread Moinak Bhattacharrya via Digitalmars-d
On Tuesday, 18 July 2017 at 20:57:51 UTC, Moinak Bhattacharrya 
wrote:

Is it possible to mixin function names? IE something like this:

template strFunc(string s){
int mixin(s)(int a){
return a+1;
}
}

If not, is something like this being looked at?


Or, just something like this for any variable name.


Mixin function names

2017-07-18 Thread Moinak Bhattacharrya via Digitalmars-d

Is it possible to mixin function names? IE something like this:

template strFunc(string s){
int mixin(s)(int a){
return a+1;
}
}

If not, is something like this being looked at?


Re: Adding flags to dub build

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 20:12:13 UTC, Jean-Louis Leroy wrote:
On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat 
wrote:
On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy 
wrote:

Hi,

I want to add a few flags while building with dub. I tried:

DFLAGS='-d-version=explain' dub test ...

...but DFLAGS does not seem to be honored. In fact I wouldn't 
mind adding a builtType to my dub.sdl (but then will it be 
inherited by the subpackages) but I don't see how to specify 
flags there either...maybe because it tries to hide 
variations in compiler switches?


J-L


Use "dflags" or "lflags" (linker)


It doesn't work either...


The Source holds all the answers ;-)

DFLAGS='-d-version=explain' dub test openmethods:benchmarks 
--build '$DFLAGS'

...
Performing "$DFLAGS" build using ldc2 for x86_64.
...


Re: proposed @noreturn attribute

2017-07-18 Thread Timon Gehr via Digitalmars-d

On 18.07.2017 20:46, Yuxuan Shui wrote:

On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote:

On 18.07.2017 14:19, Stefan Koch wrote:

[...]


D has a C-inspired first-order type system, so it is not necessarily 
crucial to have it in D. (The reason I got involved in this thread is 
that it was proposed to add Bottom as a type that is not really a 
type; 'void' is annoying enough as the 'null' of types. We don't 
really need another one of those.)


[...]


What about void?


You can't have a value of type void, but it is not empty either.

For example, this means that the following transformation is not always 
valid:


return foo();

<->

auto x = foo();
return x;


[Issue 697] No const folding on asm db,dw, etc

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=697

--- Comment #7 from Stewart Gordon  ---
(In reply to Vladimir Panteleev from comment #6)
> The original test case as presented in the issue description now works, as
> per comment 3, so I'm going to close this.
> 
> (In reply to Don from comment #5)
> > I'm reopening this since there are 7 dstress bugs which depend on it.
> 
> DStress is no longer online, so these are no longer easily available.

Doesn't follow - somebody might have a local copy of Dstress from back in the
day.  Indeed, I've found that I have.  Not sure how complete it is, but I've
found all of those listed in comment 5 therein.  As I try under DMD 2.074, they
all give a compile error.

--


Re: Adding flags to dub build

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat wrote:
On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy 
wrote:

Hi,

I want to add a few flags while building with dub. I tried:

DFLAGS='-d-version=explain' dub test ...

...but DFLAGS does not seem to be honored. In fact I wouldn't 
mind adding a builtType to my dub.sdl (but then will it be 
inherited by the subpackages) but I don't see how to specify 
flags there either...maybe because it tries to hide variations 
in compiler switches?


J-L


Use "dflags" or "lflags" (linker)


It doesn't work either...

dflags='-d-version=explain' dub --vverbose test 
openmethods:benchmarks --build release --force

Using dub registry url 'http://code.dlang.org/'
Refreshing local packages (refresh existing: true)...
Looking for local package map at 
/var/lib/dub/packages/local-packages.json
Looking for local package map at 
/home/jleroy/.dub/packages/local-packages.json
Determined package version using GIT: openmethods 
0.0.1+commit.5.g94ad5a9

Refreshing local packages (refresh existing: false)...
Looking for local package map at 
/var/lib/dub/packages/local-packages.json
Looking for local package map at 
/home/jleroy/.dub/packages/local-packages.json

Collecting dependencies for openmethods
Building package openmethods:benchmarks in 
/home/jleroy/dev/d/methods.d/benchmarks/

Refreshing local packages (refresh existing: false)...
Looking for local package map at 
/var/lib/dub/packages/local-packages.json
Looking for local package map at 
/home/jleroy/.dub/packages/local-packages.json

Collecting dependencies for openmethods:benchmarks
Adding local /home/jleroy/dev/d/methods.d/
Found dependency openmethods >=0.0.0 @../
Collecting dependencies for openmethods
Checking for missing dependencies.
Configurations used for dependency resolution:
  openmethods (0): [invalid, 0.0.1+commit.5.g94ad5a9]
Interation (ci=0) openmethods invalid (C)
Interation (ci=-1) openmethods 0.0.1+commit.5.g94ad5a9
Refreshing local packages (refresh existing: false)...
Looking for local package map at 
/var/lib/dub/packages/local-packages.json
Looking for local package map at 
/home/jleroy/.dub/packages/local-packages.json

Collecting dependencies for openmethods:benchmarks
Adding local /home/jleroy/dev/d/methods.d/
Found dependency openmethods >=0.0.0 @../
Collecting dependencies for openmethods
Checking for upgrades.
Using cached upgrade results...
Package methods can be installed with version 0.0.1.
Use "dub upgrade" to perform those changes.
Add config openmethods library
Add config openmethods:benchmarks
Including openmethods:benchmarks  -> openmethods library
openmethods:benchmarks  -> openmethods library
Using configuration 'library' for openmethods
Using configuration '' for openmethods:benchmarks
Add config openmethods library
Add config openmethods:benchmarks application
Including openmethods:benchmarks application -> openmethods 
library

openmethods:benchmarks application -> openmethods library
Using configuration 'library' for openmethods
Using configuration 'application' for openmethods:benchmarks
Creating build generator.
Add config openmethods:benchmarks application
Add config openmethods library
Including openmethods:benchmarks application -> openmethods 
library

openmethods:benchmarks application -> openmethods library
Using configuration 'application' for openmethods:benchmarks
Using configuration 'library' for openmethods
Gathering build settings for openmethods:benchmarks (application)
Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ 
source/benchmarks.d
Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ 
source/
Executable configuration "application" of package 
openmethods:benchmarks defines no main source file, this may 
cause certain build modes to fail. Add an explicit 
"mainSourceFile" to the package description to fix this.

Gathering build settings for openmethods (library)
Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/
Configuration 'application' does not output a library. Falling 
back to "dub -b unittest -c application".

Add config openmethods:benchmarks application
Add config openmethods library
Including openmethods:benchmarks application -> openmethods 
library

openmethods:benchmarks application -> openmethods library
Using configuration 'application' for openmethods:benchmarks
Using configuration 'library' for openmethods
Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ 
source/openmethods.d

Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/
Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ .
Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ 
source/benchmarks.d
Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ 
source/

Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ .
Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ 
source/benchmarks.d
Fixing relative path: 

Re: New library: open multi-methods

2017-07-18 Thread Ali Çehreli via Digitalmars-d-announce

On 07/18/2017 12:22 PM, Jean-Louis Leroy wrote:

> Look at
> 
https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d

> and
> 
https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d

> They know nothing about printing. They don't want to. The matrix modules
> do math, the app does printing.

Related, our friend Luís Marques was the speaker in January 2016 here at 
the DLang Silicon Valley meetup. "A defense of so-called anemic domain 
models":


  https://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/

I'm totally sold on the idea.

Ali



Re: Adding flags to dub build

2017-07-18 Thread Guillaume Piolat via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote:

Hi,

I want to add a few flags while building with dub. I tried:

DFLAGS='-d-version=explain' dub test ...

...but DFLAGS does not seem to be honored. In fact I wouldn't 
mind adding a builtType to my dub.sdl (but then will it be 
inherited by the subpackages) but I don't see how to specify 
flags there either...maybe because it tries to hide variations 
in compiler switches?


J-L


Use "dflags" or "lflags" (linker)


Re: DMD library available as DUB package

2017-07-18 Thread NotSpooky via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote:
During the dconf hackathon I set out to create a DUB package 
for DMD to be used as a library. This has finally been merged 
[1] and is available here [2]. It contains the lexer and the 
parser.


A minimal example:

#!/usr/bin/env dub
/++ dub.sdl:
name "dmd_lexer_example"
dependency "dmd" version="~master"
+/

void main()
{
import ddmd.lexer;
import ddmd.tokens;
import std.stdio;

immutable sourceCode = "void test() {} // foobar";
scope lexer = new Lexer("test", sourceCode.ptr, 0, 
sourceCode.length, 0, 0);


while (lexer.nextToken != TOKeof)
writeln(lexer.token.value);
}

[1] https://github.com/dlang/dmd/pull/6771
[2] http://code.dlang.org/packages/dmd


Awesome, was waiting for this.



Adding flags to dub build

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-learn

Hi,

I want to add a few flags while building with dub. I tried:

DFLAGS='-d-version=explain' dub test ...

...but DFLAGS does not seem to be honored. In fact I wouldn't 
mind adding a builtType to my dub.sdl (but then will it be 
inherited by the subpackages) but I don't see how to specify 
flags there either...maybe because it tries to hide variations in 
compiler switches?


J-L



Re: New library: open multi-methods

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 18:03:30 UTC, jmh530 wrote:

On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:


Perhaps they are all needed but I'm thinking about the need 
for forward declaration, the need for the underscore prefix, 
etc.




He might be able to at least get rid of the forward declaration 
(not sure on the underscore).


The way it works now is that a class that inherits from an 
interface is not required in any way to implement the methods. 
Suppose he adds another attribute to an interface such that any 
class that inherits from it is required to have methods defined 
for specific functions.


So for instance, the Matrix example might look something like

@trait
interface Matrix
{
  @property int rows() const;
  @property int cols() const;
  @property double at(int i, int j) const;
  @trait void print();
}

I'm not sure this would work because anything that derives from 
Matrix must implement print. However, if it is possible to use 
the attribute to allow the derived classes to ignore print, 
then it might work. Alternately, if there is a way to process 
the interface and tell the compiler to somehow ignore the 
@trait member functions. I don't know if it'll work, but it's 
an idea.


Anyway, the mixin(registerMethods); could then be adjusted so 
that void print(virtual!Matrix m); is mixed in automatically 
because we now know how to construct it.


There are at least problems with this. Firstly it is intrusive - 
something I strive to avoid (although I could be 100% orthogonal 
only because I hijack a deprecated pointer in ClassInfo). Also, 
some methods may want to treat Matrix as a virtual argument, and 
some not.


Look at 
https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d and https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d They know nothing about printing. They don't want to. The matrix modules do math, the app does printing.


J-L


Re: newCTFE Status July 2017

2017-07-18 Thread Stefan Koch via Digitalmars-d

On Tuesday, 18 July 2017 at 19:11:37 UTC, H. S. Teoh wrote:


Shouldn't there be a way to reduce the test case so that you 
don't have to look through 300 temporaries?



Yes.
However, there is not automated way to reduce it.
So to find the source-code which actually leads to the 
mis-compiled part.

I still have to consider an awful lot of code :)




Re: An Issue I Wish To Raise Awareness On

2017-07-18 Thread Jonathan M Davis via Digitalmars-d
On Tuesday, July 18, 2017 18:06:56 Atila Neves via Digitalmars-d wrote:
> On Tuesday, 18 July 2017 at 15:03:07 UTC, Kagamin wrote:
> > On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov
> >
> > [ZombineDev] wrote:
> >> I think Atila was talking about this one:
> >> struct A
> >> {
> >>
> >>~this() {}
> >>
> >> }
> >>
> >> void main()
> >> {
> >>
> >>auto a = A();
> >>shared b = A();
> >>
> >> }
> >
> > This is strange. There's nothing that suggests that struct A
> > and its destructor is thread-safe, yet compiler assumes it is.
>
> Except for a programmer explicitly and manually calling the
> destructor (in which case, don't), the destructor is only ever
> called by one thread.

It could still be a problem if the struct has a member variable that is a
reference type, because then something else could refer to that object, and
if it's shared, then you would need to protect it, and the operations that
shared prevents should still be prevented. For full-on value types, it
should be a non-issue though.

- Jonathan M Davis



Re: newCTFE Status July 2017

2017-07-18 Thread H. S. Teoh via Digitalmars-d
On Tue, Jul 18, 2017 at 07:08:49PM +, Stefan Koch via Digitalmars-d wrote:
[...]
> The bad news:
> It miscompiles it.
> 
> The generated code is bogus :)
> 
> Fixing this could take a while.
> Because even with my improved debugging tools it's still over 3k of
> instructions to look through.
> 
> It does not help that over 300 temporaries are allocated.
[...]

Shouldn't there be a way to reduce the test case so that you don't have
to look through 300 temporaries?


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal 
lovers in dire need of being reminded to profess their hypothetical love for 
their long-forgotten.


Re: static foreach is now in github master

2017-07-18 Thread Martin Tschierschke via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 10:02:10 UTC, Seb wrote:

On Monday, 17 July 2017 at 21:27:40 UTC, Martin Nowak wrote:
On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu 
wrote:
For those who want to play with our new static foreach 
feature and are willing to take the steps to building their 
own dmd,


Or just wait for the next nightly until tomorrow around 5AM 
UTC.


curl -fsS https://dlang.org/install.sh | bash -s 
dmd-nightly


the feature is now merged in master: 
https://github.com/dlang/dmd/pull/6760


Great news.



And thanks to dmd-nightly, also on run.dlang.io:

https://run.dlang.io/?compiler=dmd-nightly=void%20main(string%5B%5D%20args)%0A%7B%0A%20%20%20%20static%20foreach%20(i;%20%5B0,1,2,3%5D)%0A%09%7B%0A%20%20%20%20%09pragma(msg,%20i);%0A%09%7D%0A%7D


Cool! Thank you!


Re: newCTFE Status July 2017

2017-07-18 Thread Stefan Koch via Digitalmars-d

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


Hi Guys,

I have good news and bad news.

The good news:

newCTFE just compiled my own version of std.bitmanip.bitfields
dubbed fastFields.
which can be seen here:

https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a

The bad news:
It miscompiles it.

The generated code is bogus :)

Fixing this could take a while.
Because even with my improved debugging tools it's still over 3k 
of instructions to look through.


It does not help that over 300 temporaries are allocated.

--
Stefan


Re: New library: open multi-methods

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 18:21:21 UTC, Ali Çehreli wrote:

That reminds me: Would the following be possible and better?

// From
void main()
{
  updateMethods();
  // ...
}

// To
mixin(constructMethods());
void main()
{
  // ...
}

constructMethods() could return the following string:

string constructMethods() {
  return q{
shared static this() { updateMethods(); }
  };
}

If I'm not missing something, this is better because nothing 
needs to be added to main and the methods are available before 
main starts executing (module initialization order issues still 
apply.).


Ah, I would love to get rid of that call in main(), but think 
beyond a one module program. The matrix example 
(https://github.com/jll63/methods.d/tree/master/examples/matrix/source) consists in three separate modules, plus an app, all defining specializations. They need the mixin, but if we put updateMehods() in there, it will be called many times. And it is a costly operation. Guarding the call with a flag will not work, because more methods may be registered afterwards. Unless you can think of a way the last mixin can detect it's the last?


Incidentally, in yomm11 that function (it's called initialize()) 
has to be called before any method is called, after any shared 
object/DLL is loaded and after a DLL is unloaded. I still have to 
write the code to de-register the methods and the specializations 
in that case by the way...


J-L

J-L


Re: proposed @noreturn attribute

2017-07-18 Thread Yuxuan Shui via Digitalmars-d

On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote:

On 18.07.2017 14:19, Stefan Koch wrote:

[...]


D has a C-inspired first-order type system, so it is not 
necessarily crucial to have it in D. (The reason I got involved 
in this thread is that it was proposed to add Bottom as a type 
that is not really a type; 'void' is annoying enough as the 
'null' of types. We don't really need another one of those.)


[...]


What about void?


Re: New library: open multi-methods

2017-07-18 Thread Jean-Louis Leroy via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:

> As for performance, I have a first result:
> 
https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122

> but I still have to implement the "first argument
optimization". I am
> working on it.

I could use some explanation for the results but I can for the 
blog article. ;)


I pit a method-based call against its equivalent using virtual 
functions. First calling a virtual function via a base class is 
pitted against a method with one virtual parameter. Then the same 
but calling via an interface. Lastly, I compare double dispatch 
with a method with two virtual arguments. I use 
std.datetime.comparingBenchmark, which reports the result as 
time(base)/time(target). So open methods are a bit slower than 
ordinary virtual function calls but not that much. In the 
meantime I have applied a second optimization for unary methods 
and this brings them within 33% of an ordinary, compiler 
implemented vfunc call. Which is OK because the situation is 
highly artificial. If the function does anything, the difference 
will be imperceptible.


I am more annoyed by double dispatch beating binary methods. I 
will have to look at the assembler, but it may be that the index 
pointer is too far from the object. To begin the real work, I 
need to fetch that pointer form an object. Currently it is stored 
in ClassInfo.deallocator, so I have to 1/ fetch the vptr 2/ fetch 
the ClassInfo* 3/ fetch 'deallocator'. What happens next depends 
on the arity.


Any chance of Walter giving me a pointer in the vtable? Aside the 
ClassInfo*? Or at least a pointer in ClassInfo, or reassign the 
deallocator when it is eventually retired?


It's not surprising that ldc (and gdc) can be much better than 
dmd in optimization.


I would like to try gdc but it conflicts with ldc2 - you know, 
the "alias __va_list = __va_list_tag;" issue. I found suggestions 
via google but nothing worked for me so far.




By the way, I'm in awe of your D skills in such a short time!


Thanks :) I found out that D was much more natural, "predictable" 
than C++. The most cryptic error messages happened when I forgot 
the "!", IIRC.


I'm sure there are parts of the code that can be cleaned up but 
it's taking advantage of many powerful features of the 
language. I still think the usage can be made easier but I'm 
not sure yet. I hope others will take a look at the code and 
come up with an easier interface. Perhaps they are all needed 
but I'm thinking about the need for forward declaration, the 
need for the underscore prefix, etc.


(in reverse order)

Regarding the prefix, it is needed to prevent overload resolution 
from trumping dynamic dispatch - see here: 
https://github.com/jll63/methods.d/blob/master/examples/whytheunderscore/source/app.d Allowing the same name would necessitate compiler support.


As for the the forward declaration - I don't think it is possible 
to dispense with it. All open methods systems I know of have it 
(defgeneric in CLOS, defmulti in Clojure, Stroustrup's 
proposal...). Consider:


class A { }
class B : A { }
class X : B { }
class Y : B { }

@method void _foo(virtual!X x) { ... }
@method void _foo(virtual!Y x) { ... }

What is the base method? foo(B)? foo(A)? It may well be the 
latter. Also don't forget that the complete specialization set is 
known, at the earliest, at link time. If you (arbitrarily) pick 
foo(B), another module may introduce a B or an A specialization.


As for suggestions and advise, they are very welcome :) already 
got a couple of PRs. Here are the remaining questions on my mind:


- the module/package name: I am pretty much set on openmethods 
though...


- throw an exception if a method is not define for the argument 
set, or ambiguous: having big doubts about this. We want the 
possibility of @nothrow methods, don't we? So I will probably 
call a delegate via a pointer (a la C++) which, by default, will 
abort().


- the method prefix: hesitating between just _ or maybe m_ ???

- replace version(explain) with debug levels?


Re: New library: open multi-methods

2017-07-18 Thread Ali Çehreli via Digitalmars-d-announce

On 07/18/2017 11:03 AM, jmh530 wrote:

> the mixin(registerMethods); could then be adjusted so that void
> print(virtual!Matrix m); is mixed in automatically because we now know
> how to construct it.

That reminds me: Would the following be possible and better?

// From
void main()
{
  updateMethods();
  // ...
}

// To
mixin(constructMethods());
void main()
{
  // ...
}

constructMethods() could return the following string:

string constructMethods() {
  return q{
shared static this() { updateMethods(); }
  };
}

If I'm not missing something, this is better because nothing needs to be 
added to main and the methods are available before main starts executing 
(module initialization order issues still apply.).


Ali



Re: proposed @noreturn attribute

2017-07-18 Thread Atila Neves via Digitalmars-d

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote:
On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu 
via Digitalmars-d wrote:

[...]

[...]

IMO, the observations "used rarely" and "attention-seeking 
notation" are better satisfied by an attribute named @noreturn 
than some strange, convoluted, arcane invocation like 
`typeof(assert(0))`.  Because:


[...]


object.d:

alias noreturn = typeof(assert(0));

Atila


Re: An Issue I Wish To Raise Awareness On

2017-07-18 Thread Atila Neves via Digitalmars-d

On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote:

On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote:

On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
TL;DR: Issue 17658 [1] makes using shared very 
annoying/practically impossible.


[...]


I fixed this already, should be in the next release.

Atila


Are you sure? Because DMD nightly still errors:

https://run.dlang.io?compiler=dmd-nightly=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D


(maybe we should remove the ban on URL shorteners for our own 
sites)


Now I've read your post properly: there is only one destructor. 
With the fix I mentioned, just don't defined the `shared` 
version, there's no need to. Postblit is still a problem, however.


Atila


Re: An Issue I Wish To Raise Awareness On

2017-07-18 Thread Atila Neves via Digitalmars-d

On Tuesday, 18 July 2017 at 15:03:07 UTC, Kagamin wrote:
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov 
[ZombineDev] wrote:

I think Atila was talking about this one:
struct A
{
~this() {}
}

void main()
{
auto a = A();
shared b = A();
}


This is strange. There's nothing that suggests that struct A 
and its destructor is thread-safe, yet compiler assumes it is.


Except for a programmer explicitly and manually calling the 
destructor (in which case, don't), the destructor is only ever 
called by one thread.


Atila


Re: New library: open multi-methods

2017-07-18 Thread jmh530 via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:


Perhaps they are all needed but I'm thinking about the need for 
forward declaration, the need for the underscore prefix, etc.




He might be able to at least get rid of the forward declaration 
(not sure on the underscore).


The way it works now is that a class that inherits from an 
interface is not required in any way to implement the methods. 
Suppose he adds another attribute to an interface such that any 
class that inherits from it is required to have methods defined 
for specific functions.


So for instance, the Matrix example might look something like

@trait
interface Matrix
{
  @property int rows() const;
  @property int cols() const;
  @property double at(int i, int j) const;
  @trait void print();
}

I'm not sure this would work because anything that derives from 
Matrix must implement print. However, if it is possible to use 
the attribute to allow the derived classes to ignore print, then 
it might work. Alternately, if there is a way to process the 
interface and tell the compiler to somehow ignore the @trait 
member functions. I don't know if it'll work, but it's an idea.


Anyway, the mixin(registerMethods); could then be adjusted so 
that void print(virtual!Matrix m); is mixed in automatically 
because we now know how to construct it.


Is it possible to generate a pool of random D or D inline assembler programs, run them safely?

2017-07-18 Thread Enjoys Math via Digitalmars-d-learn
Without them crashing the app running them?  Say by wrapping with 
try / catch?


You can assume that I've limited the opcode addresses to the 
program and/or the data section which I'll try to put right next 
to the code.


Reason is so I don't have to make my own VM.

I want to mutate computable functions in a genetic-algorithm 
style, so in order to include the full space of computable 
functions I need a full programming language, or a VM that 
includes conditional jump instructions.


The purpose of it is to make a real-time, short-lived function 
predictor.





[Issue 16412] instance variable shadowing with inheritance

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16412

feklushkin.de...@gmail.com changed:

   What|Removed |Added

 CC||feklushkin.de...@gmail.com

--


[Issue 16160] selective imports in aggregation shadow @property functions

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16160

feklushkin.de...@gmail.com changed:

   What|Removed |Added

 CC||feklushkin.de...@gmail.com

--


Re: How do I cast to from byte[] <-> double for making a small assembler language VM to work?

2017-07-18 Thread Enjoys Math via Digitalmars-d-learn
Thanks for the replies.  I will look at 3-address opcodes and 
consider unions.


*Wonders if it matters that Program is a struct with opSlice / 
opSliceAssign overloaded*.


Re: regex(q"<[^]>")

2017-07-18 Thread Temtaime via Digitalmars-d

On Tuesday, 18 July 2017 at 16:34:39 UTC, unDEFER wrote:

On Tuesday, 18 July 2017 at 08:56:12 UTC, Anton Fediushin wrote:
Not a bug, but I think that `regex()` should fail with a nice 
exception, not silently fail.


Yes, exception, not assert.


The forum is not a bugtracker



Re: New library: open multi-methods

2017-07-18 Thread Ali Çehreli via Digitalmars-d-announce

On 07/18/2017 12:06 AM, Jean-Louis Leroy wrote:

> Yes I will probably write something. You mean on the D Blog?

Not necessarily but why not. :)

> As for performance, I have a first result:
> 
https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122

> but I still have to implement the "first argument optimization". I am
> working on it.

I could use some explanation for the results but I can for the blog 
article. ;)


It's not surprising that ldc (and gdc) can be much better than dmd in 
optimization.


By the way, I'm in awe of your D skills in such a short time! I'm sure 
there are parts of the code that can be cleaned up but it's taking 
advantage of many powerful features of the language. I still think the 
usage can be made easier but I'm not sure yet. I hope others will take a 
look at the code and come up with an easier interface. Perhaps they are 
all needed but I'm thinking about the need for forward declaration, the 
need for the underscore prefix, etc.


Ali



Re: An Issue I Wish To Raise Awareness On

2017-07-18 Thread Atila Neves via Digitalmars-d
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov 
[ZombineDev] wrote:

On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote:

[...]


I think Atila was talking about this one:
struct A
{
~this() {}
}

void main()
{
auto a = A();
shared b = A();
}

https://is.gd/kOYlWY


That's what I meant. I was on a train and only skimmed through.

Atila


Re: Can't get expected strings

2017-07-18 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, July 18, 2017 13:49:11 helxi via Digitalmars-d-learn wrote:
> import std.stdio, std.datetime, std.conv, std.algorithm;
>
> void main()
> {
>  immutable DEADLINE = DateTime(2017, 7, 16, 23, 59,
> 59).to!SysTime;
>  immutable NOW = Clock.currTime;
>  immutable INTERVAL = (DEADLINE - NOW)
>  .abs
>  .to!string;
>  //if I put .until("secs") here, it prints
> the full-type
>  //immutable(Until!("a == b", string,
> string))("1 day, 23 hours, 47 minutes, 30 secs, 508 ms, 119 μs,
> and 6 hnsecs", "secs", yes, false)
>
>
>  writeln(INTERVAL);
>
>  //But I don't want these until("secs") below:
>  if (NOW > DEADLINE) writeln(INTERVAL.until("secs"), "seconds
> ago.");
>  //1 day, 23 hours, 48 minutes, 55 seconds ago.
>  else if (NOW < DEADLINE) writeln(INTERVAL.until("secs"),
> "seconds ahead.");
>  else writeln("Now.");
> }
>
> -
>
>
> Why is to!string providing inconsistent string?

Because the output of Duration.toString strips any units that are 0. It's
intended to be human readable, not machine parseable. If you want a specific
format, I'd suggest that you grab the units on your own and create the
string that you want rather than trying to parse the result of toString.

If you want the entire Duration in seconds, then do something like

auto diff = Clock.currTime - deadline;
writefln("%s seconds ago", diff.total!"seconds");

whereas if you want to split out the units so that you get the seconds
portion beyond the minute, then you'd do something like

auto diff = Clock.currTime - deadline;
writefln("%s seconds ago", diff.split!("minutes", "seconds").seconds);

http://dlang.org/phobos/core_time.html#.Duration.total
http://dlang.org/phobos/core_time.html#.Duration.split

- Jonathan M Davis




Re: regex(q"<[^]>")

2017-07-18 Thread unDEFER via Digitalmars-d

On Tuesday, 18 July 2017 at 08:56:12 UTC, Anton Fediushin wrote:
Not a bug, but I think that `regex()` should fail with a nice 
exception, not silently fail.


Yes, exception, not assert.


Re: replacement for squeeze and removechars.

2017-07-18 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, July 18, 2017 15:55:00 Seb via Digitalmars-d-learn wrote:
> On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote:
> > As Seb somewhat undiplomatically put, there are replacements
> > listed in the changelog.
>
> Sorry - it wasn't intended to be an offense or aggressive. I
> consider(ed) RTFM as common internet slang.

It is, but you have to be careful with it. It could be "Read the Friendly
Manual," or it could be "Read the F@#%ing Manual," depending on the intent
of the person writing it, and it's not always clear which the writer means.
And it's used so frequently to indicate that someone should have known to
read the manual that I expect that a lot of folks are going to take it the
wrong way - especially if that's all you say. So, while it _can_ be used in
a friendly manner, it's an acronym that I'd avoid.

- Jonathan M Davis



Re: How do I cast to from byte[] <-> double for making a small assembler language VM to work?

2017-07-18 Thread H. S. Teoh via Digitalmars-d-learn
Maybe use a union?

union U {
double d;
byte[double.sizeof] bytes;
}

U u;
u.bytes = ...;
double d = u.d;
... // do something with d

// or:
U u;
u.d = 3.14159;
byte[] b = u.bytes[];
... // do something with b

Casting a pointer may run into alignment issues, if your byte[] isn't
aligned to a double.


T

-- 
Only boring people get bored. -- JM


Re: replacement for squeeze and removechars.

2017-07-18 Thread Antonio Corbi via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 15:55:00 UTC, Seb wrote:

On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote:
As Seb somewhat undiplomatically put, there are replacements 
listed in the changelog.


Sorry - it wasn't intended to be an offense or aggressive. I 
consider(ed) RTFM as common internet slang.


Dont' worry Seb, I really appreciate very much your help.
A. Corbi


Re: replacement for squeeze and removechars.

2017-07-18 Thread Seb via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote:
As Seb somewhat undiplomatically put, there are replacements 
listed in the changelog.


Sorry - it wasn't intended to be an offense or aggressive. I 
consider(ed) RTFM as common internet slang.


Re: replacement for squeeze and removechars.

2017-07-18 Thread Antonio Corbi via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote:

On Tuesday, 18 July 2017 at 15:28:06 UTC, Antonio Corbi wrote:

Hi all,

I'm trying dmd-2.075.0-rc1 in one of my projects where I use 
`squeeze` and `removechars`. Both of them are flagged as 
obsolete and in the docs we are suggested to use functions 
from std.regex and/or std.algorithm.


Does any one kow a one-liner from std.regex or std.algorithm 
that can take the role of those deprecated functions?


Thank's
A. Corbi


As Seb somewhat undiplomatically put, there are replacements 
listed in the changelog.


Use std.regex.replaceAll to replace std.string.removechars:

import std.string;
import std.regex;

// old
"abc".removechars("a-z");

// new
"abc".replaceAll(regex("[a-z]"), "");



Use std.algorithm.iteration.uniq to replace std.string.squeeze:

import std.algorithm;
import std.string;

// old
"hello".squeeze;

// new
"hello".uniq;



Though it would be nice to have these alternatives listed right 
there in the deprecation message.


Thanks Meta and Seb!

Yes, the replacement is there 8), but as the deprecation message 
told me "to go to the docs", I only had in mind the library 
manual pages and not the changelog.


I agree with you that, at least, they could also be listed next 
to `squeeze` and `removechars`.


Thanks for your help!
A. Corbi


Re: static foreach is now in github master

2017-07-18 Thread Seb via Digitalmars-d-announce
On Tuesday, 18 July 2017 at 10:06:33 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 18 July 2017 at 10:02:10 UTC, Seb wrote:

And thanks to dmd-nightly, also on run.dlang.io:

https://run.dlang.io/?compiler=dmd-nightly=void%20main(string%5B%5D%20args)%0A%7B%0A%20%20%20%20static%20foreach%20(i;%20%5B0,1,2,3%5D)%0A%09%7B%0A%20%20%20%20%09pragma(msg,%20i);%0A%09%7D%0A%7D


This link doesn't work, looks like it cuts off at the first ; 
...


Oh - seems like that was due to a different behavior between FF 
and Chrome :/
(Chrome unescapes the semi-colon by default). This has been fixed 
now, so the link above or this shortlink should work: 
https://is.gd/1TCQOh


Re: replacement for squeeze and removechars.

2017-07-18 Thread Meta via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 15:28:06 UTC, Antonio Corbi wrote:

Hi all,

I'm trying dmd-2.075.0-rc1 in one of my projects where I use 
`squeeze` and `removechars`. Both of them are flagged as 
obsolete and in the docs we are suggested to use functions from 
std.regex and/or std.algorithm.


Does any one kow a one-liner from std.regex or std.algorithm 
that can take the role of those deprecated functions?


Thank's
A. Corbi


As Seb somewhat undiplomatically put, there are replacements 
listed in the changelog.


Use std.regex.replaceAll to replace std.string.removechars:

import std.string;
import std.regex;

// old
"abc".removechars("a-z");

// new
"abc".replaceAll(regex("[a-z]"), "");



Use std.algorithm.iteration.uniq to replace std.string.squeeze:

import std.algorithm;
import std.string;

// old
"hello".squeeze;

// new
"hello".uniq;



Though it would be nice to have these alternatives listed right 
there in the deprecation message.


Re: replacement for squeeze and removechars.

2017-07-18 Thread Seb via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 15:28:06 UTC, Antonio Corbi wrote:

Hi all,

I'm trying dmd-2.075.0-rc1 in one of my projects where I use 
`squeeze` and `removechars`. Both of them are flagged as 
obsolete and in the docs we are suggested to use functions from 
std.regex and/or std.algorithm.


Does any one kow a one-liner from std.regex or std.algorithm 
that can take the role of those deprecated functions?


Thank's
A. Corbi


RTFM:

https://dlang.org/changelog/2.075.0.html#pattern-deprecate


Re: proposed @noreturn attribute

2017-07-18 Thread Timon Gehr via Digitalmars-d

On 18.07.2017 14:19, Stefan Koch wrote:

On Tuesday, 18 July 2017 at 12:15:06 UTC, Timon Gehr wrote:

On 18.07.2017 12:17, John Colvin wrote:


Better to just not define it.


That's not an option. Bottom is a subtype of all types. It cannot 
remove members, even static ones.


Timon, how important is it to actually have bottom ?


D has a C-inspired first-order type system, so it is not necessarily 
crucial to have it in D. (The reason I got involved in this thread is 
that it was proposed to add Bottom as a type that is not really a type; 
'void' is annoying enough as the 'null' of types. We don't really need 
another one of those.)


Bottom is the most principled way to encode noreturn (but the D type 
system does not have a tradition of being very principled, so 
introducing it has a cost that does not really exist the same way in 
more orthogonal designs: it falls out of them naturally).


If you have a very expressive type system, it is important to have empty 
types, because there you cannot actually decide algorithmically whether 
any given type is in fact empty. Another reason why one might want an 
empty type is that it is the neutral element for disjoint union (up to 
isomorphism). (But D does not have those built-in.)



... and what does it actually represent ?


It's a type that has no instances. If I say

int foo();

this means foo returns one of {0,1,-1,2,-2,3,-3,...,int.max,int.min}.

If I say

Bottom foo();

this means foo returns one of {}.

I.e., there is no value which foo might return. Hence it cannot return.

It can be argued that it is a bit silly to say:

int foo()@noreturn;

I.e., this function returns one of 
{0,1,-1,2,-2,3,-3,...,int.max,int.min}, but actually, it does not return 
anything. The first piece of information is redundant.



The closure of all possible types ?
like auto but if auto where not replaced ?


Your intuition is correct. In a higher-order type system, you can have:

(∀a. a) foo();

This says that foo returns a value that has any type you wish it to have.
Of course, there is no single value that has all types (ignoring e.g. 
full OO languages that have null references), hence we have no way to 
actually construct a value satisfying the constraints, so (∀a. a) is an 
empty type.


In languages with subtyping, Bottom is often just a subtype of all other 
types. (The name "Bottom" stems from here: 
https://en.wikipedia.org/wiki/Lattice_(order)#Bounded_lattice . The 
bounded lattice in question is the subtyping lattice, where A ≤ B means 
A is a subtype of B.)


One reason why it is nice to have a bounded subtyping lattice is that 
then, you can express subtyping constraints uniformly: A≤B does not 
constraint B if A is Bottom, and it does not constrain A if B is Top.






replacement for squeeze and removechars.

2017-07-18 Thread Antonio Corbi via Digitalmars-d-learn

Hi all,

I'm trying dmd-2.075.0-rc1 in one of my projects where I use 
`squeeze` and `removechars`. Both of them are flagged as obsolete 
and in the docs we are suggested to use functions from std.regex 
and/or std.algorithm.


Does any one kow a one-liner from std.regex or std.algorithm that 
can take the role of those deprecated functions?


Thank's
A. Corbi


Re: Idiomatic way of writing nested loops?

2017-07-18 Thread Russel Winder via Digitalmars-d-learn
On Tue, 2017-07-18 at 08:41 +, Anton Fediushin via Digitalmars-d-learn
wrote:
> On Tuesday, 18 July 2017 at 03:36:04 UTC, Nicholas Wilson wrote:
> > With regards to parallel, only use it on the outermost loop. 
> > Assuming you have more items in the outermost loop than you do 
> > threads parallelising more than one loop won't net you any 
> > speed.
> 
> Thank you! Yes, `parallel` runs only 4 threads on my machine, so 
> there is no reason to use it in nested loops.

But how many processors, cache sizes, memory speed, etc, etc, etc. The only
way of knowing what the fastest performance is is to try some things and get
some performance data. Even then the result only applies to that data on
that computer.

This is the sort of situation where philosophising about performance often
ends up with totally the wrong code.

-- 
Russel.
=
Dr Russel Winder t:+44 20 7585 2200   voip:sip:
russel.win...@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:rus...@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

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


Re: Idiomatic way of writing nested loops?

2017-07-18 Thread Russel Winder via Digitalmars-d-learn
On Tue, 2017-07-18 at 03:36 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
> On Monday, 17 July 2017 at 11:07:35 UTC, Anton Fediushin wrote:
> > […]
> > 
> > Also, I have a question about running this in parallel: if I 
> > want to use nested loops with `parallel` from 
> > `std.parallelism`, should I add `parallel` to every loop like 
> > this?
> > --
> > foreach(a; ["foo", "bar"].parallel) {
> >   foreach(b; ["baz", "foz", "bof"].parallel) {
> > foreach(c; ["FOO", "BAR"].parallel) {
> >   // Some operations on a, b and c
> > }
> >   }
> > }
> > --
> > I am worried about running thousands of threads, because in 
> > this case first `parallel` runs 2 tasks, every task runs 3 
> > tasks and every task runned inside a task runs 2 more tasks.

It is important to separate threads and tasks carefully here: as far as I am
aware the .parallel creates tasks not threads. The only threads are the ones
in the thread pool animatng the tasks. This having the thousands of tasks is
not a problem per se, since these are not threads.

The question of what the best decomposition for parallelism is has to be
determined by benchmarking – guesswork usually gets it wrong.

My prejudice here though is that for a loop structure such as this, unless
the computation at the centre is a biggy, you probably don't want the
.parallel on the inner loop. But I repeat only benchmarking will tell what
the best parallelism decomposition is.

> > So, how to write this in idiomatic D manner and run it _if 
> > possible_ in parallel?
> 
> With regards to parallel, only use it on the outermost loop. 
> Assuming you have more items in the outermost loop than you do 
> threads parallelising more than one loop won't net you any speed.

I am not convinced by this "idiom" of only the outer loop. It may be true
for some cases, but certtainly not all. This is task and thread pool based
parallelism here, not vector parallelism. Without knowing the actual
computational structure of the statements at the centre, there can be no
known best parallelism structure. Experimentation on medium sized data sets
before moving to the real ones is required to get the likely best
performance.


-- 
Russel.
=
Dr Russel Winder t:+44 20 7585 2200   voip:sip:
russel.win...@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:rus...@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

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


Re: An Issue I Wish To Raise Awareness On

2017-07-18 Thread Kagamin via Digitalmars-d
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov 
[ZombineDev] wrote:

I think Atila was talking about this one:
struct A
{
~this() {}
}

void main()
{
auto a = A();
shared b = A();
}


This is strange. There's nothing that suggests that struct A and 
its destructor is thread-safe, yet compiler assumes it is.


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

2017-07-18 Thread 鲜卑拓跋枫 via Digitalmars-d

On Sunday, 16 July 2017 at 03:45:09 UTC, Dsby wrote:

On Saturday, 15 July 2017 at 15:57:18 UTC, 鲜卑拓跋枫 wrote:

On Friday, 14 July 2017 at 05:07:11 UTC, Dsby wrote:

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

[...]


我也希望能用D做出来。
我们也在研究过raft, akka这些技术。 
raft算法的翻译我同事也有个port到D版本的。只是具体什么样,我没参与也没关心。

我们也在上海,我看链接里介绍,你现在也在上海工作,在EMC?
只是不知道你们开始做没?



做DMesos的目的一是Just for Fun, 二是在实战中提高D语言的功力。
D语言若能有更多一些大项目,则能更好地扩大其影响力并促进进一步的发展:)。


D 的确缺少大点的项目。
那个raft实现具体我没关心。
而且最近我在公司推nogc呢。



嗯 D在内存管理这块相比其他商业化已经成熟的主流语言确实还有一定差距。


Re: Get complete function declaration

2017-07-18 Thread SrMordred via Digitalmars-d-learn

On Tuesday, 18 July 2017 at 13:53:11 UTC, Ivan Kazmenko wrote:

On Tuesday, 18 July 2017 at 13:35:49 UTC, SrMordred wrote:
There is a way to get the full function(or any other 
structure) declaration with traits? Or I will have to mount it 
with std.traits functions?


eg.
void add(int x, int y){}

GetFullFunctionDeclaration!add; //return "void add(int x, int 
y)"


There are several function traits in std.traits (see 
https://dlang.org/phobos/std_traits.html), which can hopefully 
be combined to reconstruct a function declaration.


I don't see a single method which would do what you want out of 
the box.  Perhaps there is none, since different use cases 
would require different small subsets of features, and all the 
orthogonal features are already available.


Ivan Kazmenko.


Thanks!
I´ll have to build one so :)


[Issue 12389] Operating system C functions should be marked as 'nothrow'

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12389

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #2 from Vladimir Panteleev  ---
(In reply to qznc from comment #1)
> Resolved as of https://github.com/dlang/druntime/commit/3c9aee8fcb1d9 ?

Seems like it.

Closing; please reopen or file a new bug if any specific modules are still
missing the annotation.

--


[Issue 13039] combinations

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13039

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||patch

--


[Issue 697] No const folding on asm db,dw, etc

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=697

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #6 from Vladimir Panteleev  ---
The original test case as presented in the issue description now works, as per
comment 3, so I'm going to close this.

(In reply to Don from comment #5)
> I'm reopening this since there are 7 dstress bugs which depend on it.

DStress is no longer online, so these are no longer easily available.

Please reopen or file a new issue if you can provide a reproducible test case.

--


Re: DMD library available as DUB package

2017-07-18 Thread Meta via Digitalmars-d-announce

On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote:
During the dconf hackathon I set out to create a DUB package 
for DMD to be used as a library. This has finally been merged 
[1] and is available here [2]. It contains the lexer and the 
parser.


A minimal example:

#!/usr/bin/env dub
/++ dub.sdl:
name "dmd_lexer_example"
dependency "dmd" version="~master"
+/

void main()
{
import ddmd.lexer;
import ddmd.tokens;
import std.stdio;

immutable sourceCode = "void test() {} // foobar";
scope lexer = new Lexer("test", sourceCode.ptr, 0, 
sourceCode.length, 0, 0);


while (lexer.nextToken != TOKeof)
writeln(lexer.token.value);
}

[1] https://github.com/dlang/dmd/pull/6771
[2] http://code.dlang.org/packages/dmd


Nice, I was not aware that DMD as a library was so close to being 
a reality.


[Issue 9641] Wrong module init order when a thread is created in a module ctor

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=9641

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Martin Nowak from comment #1)
> I think the fix would need a mutex which blocks all created threads until
> all shared module constructors are finished. This might easily cause
> deadlocks though.

Sounds very similar to how Windows blocks threads created in DllMain. The
deadlock issue is there as well (threads will remain suspended until
initialization completes).

--


[Issue 17604] Reject mutable fields initialized with reference types to data segment

2017-07-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17604

Vladimir Panteleev  changed:

   What|Removed |Added

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

--


  1   2   >