[Issue 3827] Warn against and then deprecate implicit concatenation of adjacent string literals

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/31f070f607398bcef72110f40c125a7f2ea7761b
Fix issue 3827 - Deprecate implicit string concatenation

Implicit string concatenation is an old feature that can now be replaced by
explicit concatenation.
It was also a source of bug, even for experienced D programmer, and the
deprecation has been agreed
on in 2010: http://forum.dlang.org/post/ibi742$gi2$1...@digitalmars.com

https://github.com/dlang/dmd/commit/4fa0ddfcfa7e9914a4ce128595f04c67cbb7b5df
Merge pull request #6155 from
mathias-lang-sociomantic/deprecate-implicit-concat

Fix issue 3827 - Deprecate implicit string concatenation

--

[Issue 3827] Warn against and then deprecate implicit concatenation of adjacent string literals

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: DIP 1002 (TryElseExpression) added to the queue

[Walter Bright via Digitalmars-d]

On 9/27/2016 2:30 AM, Dicebot wrote:

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

PR: https://github.com/dlang/DIPs/pull/43

Abstract:

In Python, the try/catch/finally syntax is augmented with an additional clause,
termed else. It is a fantastically useful addition to the conventional syntax.
It works like this:

```
try:
do_something()
except Exception as e:
pass # Runs when an error inheriting from Exception was raised
else:
pass # Runs when no error was raised
finally:
pass # Runs unconditionally, evaluates last
```


The DIP says that a state variable is currently necessary, but that is 
incorrect:

try
{
scope (exit)
{
Runs unconditionally, evaluates last
}
scope (success)
{
runs when no error was raised
}
do_something();
}
catch (Exception e)
{
Runs when an error inheriting from Exception was raised
}

Implementation:

  The try/catch/else/finally could be 'lowered' into the above form.

These references should be included in the DIP:

  http://dlang.org/spec/statement.html#ScopeGuardStatement
  http://dlang.org/exception-safe.html

My opinion:

Due to the existence of the ScopeGuardStatement, I feel this new syntax is 
redundant and needs a much better justification.

Re: DIP 1002 (TryElseExpression) added to the queue

[Walter Bright via Digitalmars-d]

On 9/27/2016 6:22 AM, Steven Schveighoffer wrote:

Hm... I always thought scope(exit) is lowered to:

try
{
}
finally
{
   // scope exit code here
}

Which one is the building block? ;)


try/catch/finally is the building block, other constructs are lowered to that.

Re: Overloading relational operators separately; thoughts?

[Walter Bright via Digitalmars-d]

On 9/27/2016 6:18 PM, Minty Fresh wrote:

So, I'm just interested in other people's thoughts are on the subject, and
whether there are any plans to allow overloading these operators separately.


The limitations are deliberate based on the idea that comparison operators need 
to be consistent and predictable, and should have a close relationship to the 
mathematical meaning of the operators. Overloading <= to mean something other 
than "less than or equal" is considered poor style in D, and the same goes for 
the other arithmetic operators.


The use of them to create DSLs (a technique called "expression templates" in 
C++) is discouraged in D, for several reasons. The recommended way to create 
DSLs in D is to parse strings using CTFE. An excellent example of that is the 
std.regex package.


There are no plans to change this.

Re: Overloading relational operators separately; thoughts?

[Minty Fresh via Digitalmars-d]

On Wednesday, 28 September 2016 at 03:12:05 UTC, Jonathan M Davis 
wrote:
On Wednesday, September 28, 2016 01:18:58 Minty Fresh via 
Digitalmars-d wrote:
Basically, having them be overloaded separately is error-prone, 
and it leads to folks overloading them in ways that have 
nothing to do with what they mean for the built-in types, which 
makes code harder to read and maintain. D has a concatenation 
operator specifically because Walter thought that it was 
horrible to use + for concatenation.


If you want to write DSLs, then use strings and mixins. D gives 
you a _lot_ of power in that area, and it avoids the problems 
associated with making overloaded operators do things other 
than what those operators are normally intended to do. With 
strings, you can make your DSL look however you want - even 
doing stuff like using various Unicode symbols as operators if 
you want to. Even with how C++ overloads operators, overloading 
operators gives you fairly limited options with what you can do 
with a DSL, whereas you have full freedom with strings - and 
without the problems that come with trying to make your DSL 
look like normal D code.


- Jonathan M Davis


Using strings and mixins does have quite a number of downsides. 
The additional work required to past the DSL aside, you also 
usually lose the scope in which things are declared (especially 
if you wish to reference or declare variables/functions/other 
constructs within your DSL), error reporting becomes much less 
precise, and the transition between the outer code and the inner 
DSL becomes jarring (especially in terms of syntax highlighting).


That said, I love the fact D has a separate operator for 
concatenation. It's extremely useful to not have that ambiguity.


Another thought is, operators not behaving as expected doesn't 
strike me as a failure of the language, given the language 
supports operator overloading. It's a failure in documentation to 
explain what the operators are intended to do, or a failure in 
implementation to behave as they should.


Lastly, if operators are intended to behave so strictly, why does 
this not extend then to binary arithmetic operators (+, -, *, /, 
%, etc.)
They don't follow the same rules as the binary relational 
operators, after all.

Re: Overloading relational operators separately; thoughts?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 28, 2016 01:18:58 Minty Fresh via Digitalmars-d wrote:
> So, I'm just interested in other people's thoughts are on the
> subject, and whether there are any plans to allow overloading
> these operators separately.

Basically, having them be overloaded separately is error-prone, and it leads
to folks overloading them in ways that have nothing to do with what they
mean for the built-in types, which makes code harder to read and maintain.
D has a concatenation operator specifically because Walter thought that it
was horrible to use + for concatenation.

If you want to write DSLs, then use strings and mixins. D gives you a _lot_
of power in that area, and it avoids the problems associated with making
overloaded operators do things other than what those operators are normally
intended to do. With strings, you can make your DSL look however you want -
even doing stuff like using various Unicode symbols as operators if you want
to. Even with how C++ overloads operators, overloading operators gives you
fairly limited options with what you can do with a DSL, whereas you have
full freedom with strings - and without the problems that come with trying
to make your DSL look like normal D code.

- Jonathan M Davis

[Issue 16554] Wrong result of string constant

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |INVALID

--- Comment #3 from Steven Schveighoffer  ---
(In reply to apham from comment #2)
>   writeln('-', " minus#: ", cast(int) '-');
>   writeln("-", " len: ", "-".length);
>   writeln("-1", " len: ", "-1".length);
>   writeln("-12345", " len: ", "-12345".length);

All of the above are using normal ascii dash character (byte 0x2d).

>   writeln("–2_147_483_648", " len: ", "–2_147_483_648".length);

This uses different character, it even appears different on my display
(sequence 0xe2 0x80 0x93). Try this instead:

 writeln("-2_147_483_648", " len: ", "-2_147_483_648".length);

--

Re: Diet-NG 1.0.0 released

[Emre Temelkuran via Digitalmars-d-announce]

On Monday, 26 September 2016 at 13:00:46 UTC, Sönke Ludwig wrote:

(small correction:)

_diet_output.put("Hello ");
_diet_output.htmlEscape("World");
_diet_output.put("");


Sönke, I am your biggest fan, but you never reply me.

Overloading relational operators separately; thoughts?

[Minty Fresh via Digitalmars-d]

Currently, D offers fine grained overloading for most of the 
unary and arithmetic binary operators, but at some point a 
decision was made to lump together all of the relational 
operators (and if necessary, the equality operators) into a 
single function `opCmp`.
And while it does add a lot of convenience and consistency to how 
operators behave, it does also put a lot of limitations on what 
they can do.


For example, it's not currently possible to implement comparison 
operators that would behave lazily and only compute a certain 
value once a function call forces the computation.


Similarly, it's not possible to construct a DSL that would 
produce code or a query in another language, by returning values 
behave like AST nodes rather than actually performing a 
comparison.


ie.
  table.users
   .where!((users) => users.joined_on >= 3.days.ago)
   .joins(table.posts)
   .on!((posts, users) => posts.user_id == users.id)
   .limit(10)
   .toSql;

It's a little odd to me that D puts so little focus on DSLs, 
since language features like template constraints, `opDispatch`, 
and even the fact that binary operators are overloadable via a 
single templated function are all very useful tools for 
implementing them.


So, I'm just interested in other people's thoughts are on the 
subject, and whether there are any plans to allow overloading 
these operators separately.

[Issue 16554] Wrong result of string constant

[via Digitalmars-d-bugs]

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

apham  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from apham  ---
The const is not consistent. run below codes

import std.stdio;

void main()
{
writeln('-', " minus#: ", cast(int) '-');
writeln("-", " len: ", "-".length);
writeln("-1", " len: ", "-1".length);
writeln("-12345", " len: ", "-12345".length);
writeln("–2_147_483_648", " len: ", "–2_147_483_648".length);
}

--

Re: New user, even she does not know yet

[Emre Temelkuran via Digitalmars-d-announce]

On Monday, 26 September 2016 at 12:06:58 UTC, Daniel Kozak wrote:

https://onedrive.live.com/?authkey=!AEQ5lsngH-Oe3DA=87E57DF7155C89C9!24197=87E57DF7155C89C9


She will be the nextgen D'er. :D

[Issue 16555] Stack corruption when calling multi-parameter outer function from nested function

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
The stack corruption I think is on the expected location of x when calling the
function.

Note that outer function is not needed, this also produces (same) corrupt
output:

import std.stdio;

void main()
{
void inner(double x)
{
if(x == 999) // to show that x itself isn't corrupt
{
writefln("x=%s a=%s b=%s c=%s d=%s e=%s f=%s g=%s h=%s", x, 1.0,
2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0);
//outer(x, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0);
}
}

inner(999.0);
}

Not sure how to edit the description, but definitely the number of parameters
plays a role, and probably the inner function.

--

[Issue 16557] New: +++++ Lexmark printer 1=855=709=2847 TEChnical SuppORt HelpliNE PHOne nUMBer

[via Digitalmars-d-bugs]

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

  Issue ID: 16557
   Summary: + Lexmark printer 1=855=709=2847 TEChnical SuppORt
HelpliNE PHOne nUMBer
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: sanketarya...@gmail.com

Created attachment 1619
  --> https://issues.dlang.org/attachment.cgi?id=1619=edit
support phone number ++ Lexmark 360 support phone number Lexmark helpline
support number 1855   7O9   2847 Lexmark internet security customer service
1855   7O9   2847 Lexmark internet security techni

support phone number ++ Lexmark 360 support phone number
Lexmark helpline support number 1855   7O9   2847
Lexmark internet security customer service 1855   7O9   2847
Lexmark internet security technical support 1855   7O9   2847
Lexmark oem customer service1855   7O9   2847 
Lexmark pc cillin technical support 1855   7O9   2847
Lexmark phone support 1855   7O9   2847
Lexmark removal tool download 1855   7O9   2847
Lexmark subscription renewal 1855   7O9   2847
Lexmark support contact
Lexmark support hotline
Lexmark support phone number
Lexmark tech support phone number
Lexmark technical support
Lexmark technical support chat
Lexmark technical support phone number
Lexmark technical support phone number usa
Lexmark telephone number
Lexmark titanium printer
Lexmark titanium internet security
Lexmark titanium maximum
Lexmark titanium maximum security
Lexmark titanium problems
Lexmark titanium removal tool
Lexmark titanium reviews
Lexmark titanium support
Lexmark printer removal service
uninstall Lexmark smart surfing for mac
usa customer care number for Lexmark printer
Lexmark printer phone number support for technical issue in usa
Lexmark printer support phone number
Lexmark printer technical support help desk phone number
Lexmark printer technical support number
Lexmark printer technical support phone number
Lexmark customer service number
Lexmark customer service telephone number
Lexmark customer services email
Lexmark customer support email address
Lexmark customer support number
Lexmark customer support phone number
Lexmark customer service phone number
Lexmark internet security contact phone number
Lexmark internet security customer service phone number
Lexmark internet security phone number
Lexmark internet security help phone number
Lexmark internet security phone number in usa
Lexmark internet security support phone number
Lexmark internet security technical support
Lexmark phone number customer service
Lexmark phone numbers customer support
Lexmark phone support number
Lexmark security contact phone number
Lexmark security phone number customer service
Lexmark security support phone number
Lexmark support contact number
Lexmark support email address
Lexmark support phone number
Lexmark support telephone number
Lexmark support telephone number usa
Lexmark support telephone number
Lexmark tech support number

Lexmark printer customer care phone number
Lexmark printer customer service billing
Lexmark printer customer service email address
Lexmark printer customer service live chat
Lexmark printer customer service telephone number
Lexmark printer customer support usa phone number
Lexmark printer help desk support phone number free in usa
Lexmark printer phone number customer service us
Lexmark printer phone number support
Lexmark printer support phone number
Lexmark printer tech support phone number free in usa
Lexmark printer tech support phone number
Lexmark printer technical support customer service
Lexmark printer technical support number
Lexmark printer telephone number
Lexmark printer toll free customer care number
Lexmark printer toll free number in usa
Lexmark printer contact phone number in usa
Lexmark printer customer service number
Lexmark printer customer service phone number
Lexmark printer customer service telephone number
Lexmark printer customer support number
Lexmark printer customer support phone number
Lexmark printer customer support phone number
Lexmark printer help desk phone number in usa
Lexmark printer phone number
Lexmark tech support phone number
Lexmark tech support phone number free
Lexmark technical support phone number
Lexmark technical support cutomer phone number
Lexmark technical support phone number
Lexmark technical support number free in usa
Lexmark technical support number toll free number
Lexmark technical support phone number
Lexmark technologies phone number
Lexmark telephone support number
Lexmark printer customer support phone number
Lexmark printer customer service phone number
Lexmark customer support phone number
Lexmark phone number customer service
Lexmark technical support telephone number
contact Lexmark printer customer service phone number
customer service number for Lexmark printer
phone number 

[Issue 16556] Named imports violate privacy

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

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

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


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

--

[Issue 15896] private ignored when import bindings are used

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||e...@weka.io

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

--

[Issue 16556] New: Named imports violate privacy

[via Digitalmars-d-bugs]

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

  Issue ID: 16556
   Summary: Named imports violate privacy
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Private qualifier is ignored on explicit imported names.

module a;

private int x;



module b;

import a : x; // If you remove ": x" suffix, it will not compile.

void main() {
  x += 1; // <-- compiles
}

--

[Issue 16555] New: Stack corruption when calling multi-parameter outer function from nested function

[via Digitalmars-d-bugs]

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

  Issue ID: 16555
   Summary: Stack corruption when calling multi-parameter outer
function from nested function
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@kyllingen.net

When a nested function calls an outer function with a large number of
parameters, the first argument becomes corrupted.

Test case:

void outer(
double x,
double a, double b, double c, double d,
double e, double f, double g, double h)
{
import std.stdio;
writefln("x=%s a=%s b=%s c=%s d=%s e=%s f=%s g=%s h=%s",
x, a, b, c, d, e, f, g, h);
}

void main()
{
void inner(double x)
{
outer(x, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0);
}

inner(999.0);
}

Here, the value of x in outer() is garbage.  That is, the program SHOULD print:

x=999 a=1 b=2 c=3 d=4 e=5 f=6 g=7 h=8

But instead, it prints something like:

x=6.95253e-310 a=1 b=2 c=3 d=4 e=5 f=6 g=7 h=8

Reducing the number of parameters of outer() makes the problem go away.  Also,
interestingly, if the program is compiled with -O or -inline, the correct
behaviour is restored.

--

Re: Linking D code into existing C programs

[David Nadlinger via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:46:23 UTC, Johan Engelen 
wrote:
On Monday, 26 September 2016 at 23:32:05 UTC, Walter Bright 
wrote:
Linking C libraries and object code into D programs has always 
worked easily in D. The other way around, not so well.


[snip]

How much of an issue is this with D? Is it something we need 
to address?


We've been toying with this in setting up LDC's build such that 
it works on different platforms. […]
We've now moved to using the system linker separately to do the 
linking.


To clarify: What we are doing in LDC is of course not what was 
suggested in the initial post, i.e. linking D object files into C 
executables without any (explicit) druntime dependencies and 
expecting this to work.


The problem we were facing in particular is that many C/C++ 
libraries (such as LLVM) come with a list of linker flags to use 
in the form of pkg-config or a similar tool. These will usually 
be formatted for the default way of linking C on the system (i.e. 
through a gcc-compatible interface). Thus, you can't just prefix 
them with -L and forward them to the D compiler since that 
forwards them directly to the low-level linker (-Xlinker, …).


This is a problem which *every* D project that wants to 
seamlessly link against system C libraries on Linux needs to 
solve.


There are two obvious ways to improve the situation:
 - Like Johan suggested, add a D compiler flag that prints the 
default linker flags used to create D executables.
 - Add a D compiler flag to forward flags directly to the linker 
driver used, without using -Xlinker.


Unfortunately, the LDC build system of course needs to work with 
existing host compilers anyway, so these wouldn't have helped us 
with shipping the first DDMD-based version. The most robust 
solution I could come up with was to extract the linker command 
line used from `$DMD -v some_test_executable.d` to then pass the 
same flags directly to the system gcc when building the D program.


 — David

Usage of DDOC_KEYWORD and DDOC_TEMPLATE_PARAM macros

[Jacob Carlborg via Digitalmars-d-learn]

I'm working on a Ddoc theme and I have trouble figuring out when the 
DDOC_KEYWORD and DDOC_TEMPLATE_PARAM macros are used. Are the compiler 
outputting them or should the developer be using those directly? If the 
compiler is outputting them, then when is it doing that?


--
/Jacob Carlborg

[Issue 16554] Wrong result of string constant

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

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

--- Comment #1 from ag0ae...@gmail.com ---
You're using an en dash for the minus sign there. That's code point U+2013,
which is encoded in UTF-8 with three code units / bytes. .length gives the
length in code units, so 16 is correct.

Closing as invalid. Please reopen if I missed something.

--

[Issue 16554] New: Wrong result of string constant

[via Digitalmars-d-bugs]

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

  Issue ID: 16554
   Summary: Wrong result of string constant
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: critical
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: ap...@hotmail.com

import std.stdio;

void main()
{
// expect 14 but 16 
writeln("len of –2_147_483_648: ", "–2_147_483_648".length);  
}

--

Re: Lazily evaluated property pointing to read only object

[vit via Digitalmars-d-learn]

On Saturday, 24 September 2016 at 11:51:56 UTC, Basile B. wrote:

On Saturday, 24 September 2016 at 10:59:50 UTC, mikey wrote:
On Saturday, 24 September 2016 at 10:16:34 UTC, Basile B. 
wrote:

You don't need to cast, from "mutable" to "const" is implicit:
https://dlang.org/spec/const3.html#implicit_conversions


Ok, but using const would be an accepted way of doing this? 
The options I could see were to have "_o" as a const or 
immutable type and just create a const on the first call to 
the lazily evaluated property, or to do what I did and have 
"_o" as a non-const and then convert it to cost on the way 
out. However


To store it as const I guess I'd have to make it a non-const 
pointer to a const object, and is that not kind of what 
immutable is?


Yes, the problem is that if you want to create a true 
const(Object) (with const part of the type) you have to 
initialize it in a constructor (so no lazyness). It indeed 
looks like the immutable mechanism. I don't know **exactly** 
why but I guess that's a special case for classes since there's 
no other way to initialize them.


Finally, with the property your object is seen as const(Object) 
outside. The only difference is inside ConstProp.


use Rebindable:


class Obj {
string _s;

this()pure{
this("");
}
this(string s)pure{
_s = s;
}

@property string desc() const { return _s; }
@property void desc(string s) { _s = s; }

override string toString() const {
return _s;
}
}

class ConstProp {
import std.typecons : Rebindable;
Rebindable!(immutable Obj) _o;
string _s;

this(string s) {
_s = s;
}

immutable(Obj) lazily(){
if (_o is null) {
_o = new Obj("working " ~ _s);
}
return _o;
}
}

[Issue 16489] [backend][optimizaton][registers] DMD is 10-20 times slower for GLAS

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
Ok, I understand. This is the 'slicing' optimization where an aggregate can be
sliced up and stored in multiple registers. I went over it with deadalnix a
while ago, as it was identified as a key optimization. It applies more
generally than just for SIMD.

I also worked out a scheme for implementing it in the DMD BE, I don't think it
is that hard, or I've misunderstood it. The slicing can be done if:

1. all accesses lie within slices (not across slice boundaries)
2. a pointer to the aggregate is not taken (because then you lose control of
(case 1)).

The slicing then becomes a rewrite of the IR so the aggregate is decomposed
into multiple independent variables, and the rest of the backend then proceeds
normally.

--

[Issue 16553] Tuesday Post @ 18557092847 Lexmark pRINter tech support))))) I855709....2847 <<<<<<(((((((( phone number usa All

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mathias.l...@sociomantic.co
   ||m
 Resolution|--- |INVALID

--- Comment #1 from Mathias Lang  ---
Spam

--

[Issue 16552] USA Toll Free @@||1-855-7O9-2847)hp wireless printer technical support phone number 1855 7O9.2847 wireless wireless printer Helpline usa

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |INVALID

--- Comment #1 from Steven Schveighoffer  ---
Is there a way to delete spam?

--

[Issue 16552] USA Toll Free @@||1-855-7O9-2847)hp wireless printer technical support phone number 1855 7O9.2847 wireless wireless printer Helpline usa

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC|schvei...@yahoo.com |

--

[Issue 16553] New: Tuesday Post @ 18557092847 Lexmark pRINter tech support))))) I855709....2847 <<<<<<(((((((( phone number usa All

[via Digitalmars-d-bugs]

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

  Issue ID: 16553
   Summary: Tuesday Post @ 18557092847 Lexmark pRINter tech
support) I8557092847 << phone
number usa All
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sanketarya...@gmail.com

Created attachment 1618
  --> https://issues.dlang.org/attachment.cgi?id=1618=edit
Lexmark printer tech support)  Lexmark printer tech support))  ((
phone number usa ( phone number usa non desktop support, Lexmark printer
customer service,  contact Lexmark Printer suppor

Lexmark printer tech support)  Lexmark printer tech support))  ((
phone number usa ( phone number usa
non desktop support, Lexmark printer customer service,  contact Lexmark Printer
support, Lexmark pc
 Lexmark printer tech support))   (( phone number usa
support, Lexmark printer customer care number, Lexmark support for Printer,
Lexmark Printer customer care, Lexmark

customer care phone number, hewlett packard help, phone number for Lexmark,
Lexmark online help, Lexmark printer

customer care, Lexmark helpline phone number, Lexmark Printer customer support,
Lexmark technical support chat,

Lexmark computer help, Lexmark support numbers, Lexmark technical support
contact number, Lexmark telephone

number, Lexmark Printer technical support phone number, Lexmark Printer
helpline, Lexmark support Printer,

Lexmark support online, Lexmark Printer contact number, Lexmark help phone
number, Lexmark Printer customer care

number, contact hewlett packard by phone, Lexmark Printer phone support,
hewlett packard Printer 

support, Lexmark tech support phone, Lexmark technical help, Lexmark printer
tech support number, contact Lexmark by

phone, Lexmark support call, Lexmark computers support, hewlett packard
customer service telephone number,

phone number for hewlett packard, Lexmark online support chat, Lexmark printer
customer service number, Lexmark

online chat support, Lexmark Printer customer service, hewlett packard customer
service phone, Lexmark

printer tech support, Lexmark service phone number, hewlett packard Printer
help, phone number for Lexmark

Printer, Lexmark troubleshooting phone number, Lexmark 844 number, hewlett
packard technical support

number, contact Lexmark support phone, phone number for Lexmark Printer
support, Lexmark customer support

chat, Lexmark help and support number, contact hewlett packard, Lexmark printer
support phone number, Lexmark

Printer customer service phone number, Lexmark printer customer service phone
number, Lexmark computer

support phone number, Lexmark pavilion support, Lexmark computer customer
service, Lexmark customer services,

hewlett packard telephone number, Lexmark helpline no, Lexmark help desk
number, contact Lexmark support phone

number, hewlett packard contact, Lexmark phone numbers, Lexmark Printer
customer care number, Lexmark

Printer help and support, contact Lexmark technical support, Lexmark contact
numbers, contact Lexmark support

chat, call Lexmark tech support, Lexmark customer service phone, Lexmark help
support, Lexmark computer tech support,

Lexmark assistance phone number, Lexmark customer service telephone number,
hewlett packard Printer

support phone number, Lexmark contact support number, Lexmark support center
phone number, Lexmark support

phone numbers, tech support for Lexmark, Lexmark it support, Lexmark printer
helpline, Lexmark technical, Lexmark printer

technical support number, Lexmark Printer tech support phone number, Lexmark
Printer support phone

number, hewlett packard help desk phone number, Lexmark computer tech support
phone number, Lexmark

customer service number for printer, Lexmark Printer helpline number, contact
Lexmark support by phone,

hewlett packard support center, Lexmark printer customer care no, Lexmark
Printer support telephone number,


Lexmark support services, Lexmark customer service number for Printer, Lexmark
product support num

--

[Issue 16552] New: USA Toll Free @@||1-855-7O9-2847)hp wireless printer technical support phone number 1855 7O9.2847 wireless wireless printer Helpline usa

[via Digitalmars-d-bugs]

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

  Issue ID: 16552
   Summary: USA Toll Free @@||1-855-7O9-2847)hp wireless printer
technical support phone number 1855 7O9.2847 wireless
wireless printer Helpline usa
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: sanketarya...@gmail.com

Created attachment 1617
  --> https://issues.dlang.org/attachment.cgi?id=1617=edit
Lexmark customer service telephone number Lexmark PRINTER customer support
number  Lexmark PRINTER technical support  Lexmark PRINTER customer support
phone number  Lexmark PRINTER customer service ph

Lexmark customer service telephone number
Lexmark PRINTER customer support number
 Lexmark PRINTER technical support
 Lexmark PRINTER customer support phone number
 Lexmark PRINTER customer service phone number
 Lexmark PRINTER customer support number
 Lexmark PRINTER customer service number
 phone number for Lexmark  PRINTER customer service
 Lexmark PRINTER customer support
 contact Lexmark PRINTER customer service phone number
 Lexmark PRINTER customer service phone number us
 Lexmark PRINTER phone number customer service us
 phone number Lexmark  PRINTER customer service
 Lexmark PRINTER phone number customer service
 customer service number for Lexmark  PRINTER
 Lexmark PRINTER customer service phone
 Lexmark PRINTER tech support phone number
 Lexmark tech support phone number
 Lexmark tech support phone number us
 Lexmark PRINTER tech support number
 phone number for Lexmark  tech support
 Lexmark tech support number
 Lexmark customer support phone number
 Lexmark customer service phone number
 Lexmark phone number customer service
 Lexmark PRINTER phone number customer service
 phone number for Lexmark  customer service
 Lexmark customer service phone number
 Lexmark PRINTER customer service phone number
 Lexmark customer service phone numbers
 Lexmark PRINTER customer service phone number
 Lexmark phone number customer support
 phone number for Lexmark  customer support
 Lexmark PRINTER customer service
 Lexmark PRINTER phone number customer service
 Lexmark support phone number
 phone number for Lexmark  customer service
 Lexmark PRINTER help phone number
 Lexmark PRINTER customer service telephone number
 Lexmark technical support telephone number
 Lexmark support telephone number
 Lexmark helpline phone number
 Lexmark PRINTER technical support phone number
Lexmark tech support phone number free
Lexmark technologies phone number
Lexmark telephone support number
Lexmark support telephone number usa
Lexmark customer service number
Lexmark PRINTER plus tech support
Lexmark technical support phone number
Lexmark PRINTER technical support number
Lexmark PRINTER technical support help desk phone number
Lexmark technical support number toll free number
Lexmark technical support phone number
Lexmark PRINTER customer support phone number
Lexmark PRINTER customer service phone number
Lexmark PRINTER customer support phone number
Lexmark PRINTER customer service phone number
phone number for Lexmark PRINTER customer service
contact Lexmark  PRINTER customer service phone number
Lexmark customer service phone number
phone number for Lexmark customer service
Lexmark PRINTER support phone number
Lexmark PRINTER support phone number
phone number for Lexmark  PRINTER
Lexmark PRINTER phone number in usa
Lexmark PRINTER contact phone number in usa
Lexmark PRINTER contact phone number
Lexmark PRINTER help desk phone number in usa
Lexmark PRINTER tech support  phone number free in usa
Lexmark PRINTER support phone number
Lexmark PRINTER phone num855ber support for technical issue in usa
phone number for Lexmark  PRINTER technical support
Lexmark PRINTER customer service telephone number
Lexmark PRINTER toll free customer care number

--

Re: Is TDPL an accurate description of the D language today?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/27/16 1:38 PM, Mark wrote:

I've been going through Andrei's excellent book and I noticed that the
latest printing is from 2010. Since D is still a very young language I
can imagine it changing quite a bit within six years. So I wonder if
there are any major inconsistincies between the current state of the
language and its description in TDPL. Is there a list somewhere with all
the changes made in the langauge since the book was published?

Thanks a lot.


Most things that are "wrong" in the book should be in the errata: 
http://erdani.com/tdpl/errata/


There are also some things that are not wrong in the book, but have not 
been implemented.


I think the most glaring difference is that "clear" has been renamed to 
"destroy".


-Steve

Is TDPL an accurate description of the D language today?

[Mark via Digitalmars-d-learn]

I've been going through Andrei's excellent book and I noticed 
that the latest printing is from 2010. Since D is still a very 
young language I can imagine it changing quite a bit within six 
years. So I wonder if there are any major inconsistincies between 
the current state of the language and its description in TDPL. Is 
there a list somewhere with all the changes made in the langauge 
since the book was published?


Thanks a lot.

Re: What's up with the assert enhancements proposed years ago?

[Atila Neves via Digitalmars-d]

On Saturday, 24 September 2016 at 14:08:30 UTC, Nick Sabalausky 
wrote:

On 09/24/2016 04:03 AM, Martin Nowak wrote:

[...]


Yea, incidentally, I just started using unit-threaded for the 
first time this week, and so far, for the most part, I really 
quite like it a lot. But those comparator functions give me bad 
flashbacks of old-school Java.


Hmm, I wonder if Atila would be amenable to a more 
assertPred-like function in unit-threaded. Maybe a 
`should!"=="(leftSide, rightSide)` would fit in well. Or better 
yet, also adding in something like that that trick used in 
Andre's really nice recently proposed "dump" function (or 
whatever the name of it was), where it also prints out the 
actual argument provided in addition to the argument's value.


See my answer to Martin. "!" next to "==" just looks wrong.

Atila

Re: Linking D code into existing C programs

[Atila Neves via Digitalmars-d]

On Monday, 26 September 2016 at 23:32:05 UTC, Walter Bright wrote:
Linking C libraries and object code into D programs has always 
worked easily in D. The other way around, not so well.


[...]


I think it should work as well as it does in C++, if possible. 
The equivalent to the example above links fine for foo.cpp. It's 
only if you use the standard library or throw exceptions that you 
need to link with g++ instead.


Atila

Re: What's up with the assert enhancements proposed years ago?

[Atila Neves via Digitalmars-d]

On Saturday, 24 September 2016 at 08:03:15 UTC, Martin Nowak 
wrote:
On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky 
wrote:
were rejected because it was deemed both easy enough and 
preferable to get these features by modifying DMD to add 
behind-the-scenes AST magic to "assert".


So...umm...yea...whatever happened to that beefed-up "assert" 
feature?


assertPred!"=="(a, b);
assertPred!"!"(a);
assertPred!(std.range.equal)(a, b);


assertPred!"==" looks like it asserts not equal, which is the 1st 
problem with this, assertPred!"!=" looks even worse. I considered 
going down this route but... ugh.




Seems to do most of what DIP83 does w/ expensive feature 
design, and compiler implementation work.
Also http://code.dlang.org/packages/unit-threaded comes with a 
couple of test comparators, though it follows ruby rspec's bad 
idea of giving every comparator a name (which has to be learnt 
and documented).


I didn't want to give every comparator a name, this was the least 
bad option from my point of view. I'd rather `assert` be magical. 
Or, be able to have AST macros to get around the limitations of 
how operator overloading works in D. Don't get me wrong, the 
reason why it works the way it does is awesome in general, but 
limiting in this case in particular. I ended up implementing this:


foo.should == bar

But unfortunately it only works for equality. This is also 
possible:


foo.should.not == bar

But I can't do the same with any of the other operators AFAICR so 
I went with consistency even though the equality check is the 
most common.



Atila

Re: Module Clarification

[Jonathan Marler via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 13:48:39 UTC, Steven 
Schveighoffer wrote:

On 9/22/16 4:16 PM, Jonathan Marler wrote:
On Thursday, 22 September 2016 at 20:09:41 UTC, Steven 
Schveighoffer wrote:


Before package.d support, you could not do any importing of 
packages.
You could only import modules. package.d was how the compiler 
allowed

importing packages.

I don't know that there is a fundamental difference between
foo/package.d and foo.d, but this is just the solution that 
was
chosen. Is it a mistake? I don't think so, it's just a 
preference.


Prior to this, it was common to put "package" imports into an 
"all.d"

file:

foo/all.d // import fooPart1.d fooPart2.d
foo/fooPart1.d



Ok, do you know why is this not allowed?


I'm sure if you search the forums, you can find discussions of 
this. Walter probably had a reason. I'm not sure if the reason 
is valid anymore now that package.d is supported.


-Steve


foo.d
foo/bar.d

I would think the reason for not supporting this is you wouldn't 
want something to be a "module" and a "package" at the same time, 
but introduction of the "package.d" semantics has broken that 
rule.


From what I can see, it seems like the concept of "packages" 
doesn't have any useful meaning anymore.  Before adding 
"package.d" support, a "package" was a directory/node you could 
find modules underneath, but now that it can also be a module 
itself, saying something is a "package" doesn't really have any 
meaning. Take the following 2 cases:


Case 1: foo.d
Case 2: foo/package.d

In case 1, foo is a "module", and in case 2, foo is a "package".  
The problem is that foo can behave EXACTLY THE SAME in both 
cases.  foo could contain typical module code, or publicly import 
other modules like a typical "package.d" file, in both cases.  
Saying that foo is a "package" doesn't tell you anything about 
how "foo" behaves.  The "package" concept seems pretty 
meaningless now.

Re: Required DMD changes for Mir and few thoughts about D future

[Andrei Alexandrescu via Digitalmars-d]

On 9/27/16 12:36 PM, Ilya Yaroshenko wrote:

On Tuesday, 27 September 2016 at 10:20:09 UTC, Andrei Alexandrescu wrote:

On 9/27/16 10:50 AM, Ilya Yaroshenko wrote:

On Tuesday, 27 September 2016 at 07:01:08 UTC, Jacob Carlborg wrote:

On 2016-09-26 21:49, bachmeier wrote:


[...]


He mentions several front end issues, those apply to LDC as well.


No, LDC for example does not have the issue
https://issues.dlang.org/show_bug.cgi?id=16488 and others too.


Can we make sure all issues that Mir has with dmd and gdc be present
in bugzilla and tagged with "Mir"? Thanks! -- Andrei


Will fill them tomorrow --Ilya


Awes, thx. -- Andrei

Re: Required DMD changes for Mir and few thoughts about D future

[Andrei Alexandrescu via Digitalmars-d]

On 9/27/16 12:48 PM, Ilya Yaroshenko wrote:

On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat wrote:

On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei Alexandrescu wrote:

I'm not going to argue this much further. Essentially Mir is touted
as a highly generic and portable library. Having it only work on one
language implementation works against that statement, the credibility
of Mir, and the credibility of D as an universal platform for
creating fast code.


Isn't it just a matter of adding "version(LDC)" around the more
optimized blocks?
Having it work in DMD, however slower, is good enough.


50 times slower for modern CPUs.


Just to reiterate my point: I'd say a 30% penalty would be still within 
batting range of the best out there and would be my lower bound for 
declaring dmd/Mir a success. -- Andrei

[Issue 14532] switch block allows creating uninitialized variables

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #6 from Mathias Lang  ---
*** Issue 16549 has been marked as a duplicate of this issue. ***

--

[Issue 16549] Switch statement can skip initialization

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

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

--- Comment #4 from Mathias Lang  ---
I'll mark as duplicate. It was fixed by https://github.com/dlang/dmd/pull/5869

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

--

Re: SDLang-D v0.10.0 - Big convenience improvements

[Nick Sabalausky via Digitalmars-d-announce]

On 09/27/2016 04:55 AM, Chris wrote:


I was actually thinking of using SDL for pseudo code non-programmers
could write, e.g. to create rule files that a program could execute. It
could work nicely with `if` and `else` tags + attributes.


A simple programming language that's SDLang-compliant would definitely 
be interesting!

Re: Required DMD changes for Mir and few thoughts about D future

[Andrei Alexandrescu via Digitalmars-d]

On 9/27/16 1:33 PM, Johan Engelen wrote:

I thought so too but if the algorithm is 50x slower, it probably means
you can't develop that algorithm any more (I wouldn't). I think the
common use-case for Mir is a calculation that takes seconds, so 50x
turns a test into a run of several minutes, defeating the compilation
speed advantage of DMD. The way I see it, faster development with
Mir+DMD is not possible.


Yes, 50x is not going to pass. In my experience, generally (not for 
numerics code) dmd generated code is somewhat in between 5% faster and 
40% slower. I'd say if we get it within the same range for Ilya's 
library we can call it a successful port.



It is easy to want something, but someone else has to do it and live
with it too. It's up to the Mir devs (**volunteers!**) to choose which
compilers they support. As you can see from the PR that removed DMD
support, the extra burden is substantial.
https://github.com/libmir/mir/pull/347


We need to do what it takes to make dmd work with Mir properly.


An extra subjective comment from recent experience: I think LDC has been
very responsive to Mir's needs, thinking _with_ Mir development instead
of fighting it and debating things to death. Imagine you are developing
Mir, want to get something done, and then read the discussion starting here
https://forum.dlang.org/post/brieiuuuslpzfeiox...@forum.dlang.org
The LDC PR with the requested functionality was submitted less than two
weeks after
(pull was stalled because we don't control our own frontend).


That's far from the worst we've had, but I agree that generally the 
endless debates are often gridlocking our progress.



Andrei

Re: Required DMD changes for Mir and few thoughts about D future

[Johan Engelen via Digitalmars-d]

On Tuesday, 27 September 2016 at 13:36:50 UTC, Guillaume Piolat 
wrote:


If it has runtime dispatch, it will work everywhere.


I'm sorry but, like others, clearly you have not understood the 
issue.

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

[Dsciple via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 14:39:10 UTC, Dsciple wrote:
On Tuesday, 27 September 2016 at 14:02:25 UTC, Marc Schütz 
wrote:

On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote:
As said, this works fine when tested in isolation, and the 
compiler only complains when using BindAddress as a member of 
ConfigParams.

Any idea what the problem may be?
Or is there maybe a ready to use, high-level library for 
parsing parameters from command-line arguments and config 
files of some kind?


I assume your ConfigParams variable is global or static? Can 
you show how you initialize it, and how it's declared?


You're probably using it in a way that requires it to be 
evaluated at compile time. That's the case for initializers of 
global/static variables, as well as default values of struct 
members.


Yes I think so.
I use static default values for all members of ConfigParams and 
I instantiate ConfigParams in my unit tests, so I assume that 
the variable would be global there.

The code looks like:

unittest {

  string[] args = [
"binaryFileName",
"--bindAddresses=0.1.2.3;4.5.6.7",
"--bindHTTPPort=80",
"--bindHTTPSPort=443",
"--configFile=testfiles/test.conf.sdl",
"--verbosityLevel=detailed",
  ];

  ConfigParams configParams;  // default values for parameters
  configParams.readFromAll(args); // values read from 
command-line arguents


  // assertion checks here
}

What do you suggest? Should I move all default initializations 
to a constructor?

Thank you for your response.


I forgot to show declaration. Here it is:

struct ConfigParams {

  import ConfigParamsCLAMixin: ConfigParamsCLA;
  import ConfigParamsSDLMixin: ConfigParamsSDL;
  import ConfigParamsAllMixin: ConfigParamsAll;
  import BindAddress: BindAddress, BindAddressException;
  import BindAddresses: BindAddresses, BindAddressesException;
  import BindPort: BindPort, BindPortException;
  import PosixPath: PosixPath, PosixPathException;
  import VerbosityLevel: VerbosityLevel, VerbosityLevelException;

  // Define configuration parameters' static default fields
  static immutable BindAddresses defaultBindAddresses = 
BindAddresses([

BindAddress("192.168.2.10")
  ]);
  static immutable BindPort defaultBindHTTPPort = BindPort(8080);
  static immutable BindPort defaultBindHTTPSPort = BindPort(4430);
  static immutable PosixPath defaultConfigFile =
PosixPath("/etc/ras/ras.conf.sdl");
  static immutable VerbosityLevel defaultVerbosityLevel =
VerbosityLevel("quiet");

  // Define configuration parameters fields with default values
  BindAddresses bindAddresses = defaultBindAddresses;
  BindPort bindHTTPPort = defaultBindHTTPPort;
  BindPort bindHTTPSPort = defaultBindHTTPSPort;
  PosixPath configFile = defaultConfigFile;
  VerbosityLevel verbosityLevel = defaultVerbosityLevel;

}

I don't understand why the unit tests of all individual members 
of ConfigParams (BindAddresses, BindAddress and so on) would work 
in isolation using the same kind of initialization, whereas some 
of them would fail as members of ConfigParams.
I suspect this may also be a problem with settings in dub.json 
for ConfigParams:


{
  ...
  "sourcePaths": [
"sources"
  ],
  "importPaths": [
"sources"
  ],
  "configurations": [
{
  "name": "library",
  "targetName": "ConfigParams",
  "targetType": "library"
}
  ],
  "dependencies": {
"bind-address": {
  "version": "*",
  "path": "./libraries/BindAddress"
},
"bind-addresses": {
  "version": "*",
  "path": "./libraries/BindAddresses"
},
"bind-port": {
  "version": "*",
  "path": "./libraries/BindPort"
},
"posix-name": {
  "version": "*",
  "path": "./libraries/PosixName"
},
"posix-path": {
  "version": "*",
  "path": "./libraries/PosixPath"
},
"verbosity-level": {
  "version": "*",
  "path": "./libraries/VerbosityLevel"
}
  }

if I include bind-address as a dependency (as above), dub refuses 
to run with:


Sub package bind-address: doesn't exist.

although the package is there and used by bind-addresses and 
confi params too...

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

[Dsciple via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 14:02:25 UTC, Marc Schütz wrote:

On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote:
As said, this works fine when tested in isolation, and the 
compiler only complains when using BindAddress as a member of 
ConfigParams.

Any idea what the problem may be?
Or is there maybe a ready to use, high-level library for 
parsing parameters from command-line arguments and config 
files of some kind?


I assume your ConfigParams variable is global or static? Can 
you show how you initialize it, and how it's declared?


You're probably using it in a way that requires it to be 
evaluated at compile time. That's the case for initializers of 
global/static variables, as well as default values of struct 
members.


Yes I think so.
I use static default values for all members of ConfigParams and I 
instantiate ConfigParams in my unit tests, so I assume that the 
variable would be global there.

The code looks like:

unittest {

  string[] args = [
"binaryFileName",
"--bindAddresses=0.1.2.3;4.5.6.7",
"--bindHTTPPort=80",
"--bindHTTPSPort=443",
"--configFile=testfiles/test.conf.sdl",
"--verbosityLevel=detailed",
  ];

  ConfigParams configParams;  // default values for parameters
  configParams.readFromAll(args); // values read from 
command-line arguents


  // assertion checks here
}

What do you suggest? Should I move all default initializations to 
a constructor?

Thank you for your response.

[Issue 16549] Switch statement can skip initialization

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
(In reply to Mathias Lang from comment #2)
> Compiling with master will give you a deprecation message:
> 
> lol.d(8): Deprecation: 'switch' skips declaration of variable lol.bar.foo at
> lol.d(10)

Ah, yes. Is there a commit to refer to so we can close this. Or is this a
duplicate?

--

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote:
As said, this works fine when tested in isolation, and the 
compiler only complains when using BindAddress as a member of 
ConfigParams.

Any idea what the problem may be?
Or is there maybe a ready to use, high-level library for 
parsing parameters from command-line arguments and config files 
of some kind?


I assume your ConfigParams variable is global or static? Can you 
show how you initialize it, and how it's declared?


You're probably using it in a way that requires it to be 
evaluated at compile time. That's the case for initializers of 
global/static variables, as well as default values of struct 
members.

Re: How to debug (potential) GC bugs?

[Kapps via Digitalmars-d-learn]

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp 
wrote:

Hello!
I am working together with others on the D-based 
appstream-generator[1] project, which is generating software 
metadata for "software centers" and other package-manager 
functionality on Linux distributions, and is used by default on 
Debian, Ubuntu and Arch Linux.


For Ubuntu, some modifications on the code were needed, and 
apparently for them the code is currently crashing in the GC 
collection thread: http://paste.debian.net/840490/


The project is running a lot of stuff in parallel and is using 
the GC (if the extraction is a few seconds slower due to the GC 
being active, it doesn't matter much).


We also link against a lot of 3rd-party libraries and use a big 
amount of existing C code in the project.


So, I would like to know the following things:

1) Is there any caveat when linking to C libraries and using 
the GC in a project? So far, it seems to be working well, but 
there have been a few cases where I was suspicious about the GC 
actually doing something to malloc'ed stuff or C structs 
present in the bindings.


2) How can one debug issues like the one mentioned above 
properly? Since it seems to happen in the GC and doesn't give 
me information on where to start searching for the issue, I am 
a bit lost.


3) The tool seems to leak memory somewhere and OOMs pretty 
quickly on some machines. All the stuff using C code frees 
resources properly though, and using Valgrind on the project is 
a pain due to large amounts of data being mmapped. I worked 
around this a while back, but then the GC interfered with 
Valgrind, making information less useful. Is there any 
information on how to find memory leaks, or e.g. large structs 
the GC cannot free because something is still having a needless 
reference on it?


Unfortunately I can't reproduce the crash from 2) myself, it 
only seems to happen at Ubuntu (but Ubuntu is using some 
different codepaths too).


Any insights would be highly appreciated!
Cheers,
   Matthias

[1[: https://github.com/ximion/appstream-generator


First, make sure any C threads calling D code use 
Thread.attachThis (thread_attachThis maybe?). Otherwise the GC 
will not suspend those threads during a collection which will 
cause crashes. I'd guess this is your issue.


Second, tell the GC of non-GC memory that has pointers to GC 
memory by using GC.addRange / GC.addRoot as needed. Make sure to 
remove them once the non-GC memory is deallocated as well, 
otherwise you'll get memory leaks. The GC collector is also 
conservative, not precise, so false positives are possible. If 
you're using 64 bit programs, this shouldn't be much of an issue 
though.


Finally, make sure you're not doing any GC allocations in dtors.

Re: Proper way to work around `Invalid memory operation`?

[Kapps via Digitalmars-d-learn]

On Sunday, 25 September 2016 at 16:07:12 UTC, Matthias Klumpp 
wrote:

Hello!

I have a class similar to this one:
```
class Dummy
{

private:

string tmpDir;

public:

this (string fname)
{
tmpDir = buildPath ("/tmp", fname.baseName);
std.file.mkdirRecurse (tmpDir);
}

~this ()
{
close ();
}

void close ()
{
if (std.file.exists (tmpDir))
std.file.rmdirRecurse (tmpDir);
}
}
```

When the GC calls the classes destructor, I get a
`core.exception.InvalidMemoryOperationError@/<...>/ldc/runtime/druntime/src/core/exception.d(693):
 Invalid memory operation`

Looks like rmdirRecurse tries to allocate with the GC, and the 
GC doesn't like that.
Is there any good way to get the temporary directory deletet 
automatically when the object is freed?
At time, I work around this bug by calling close() manually at 
the appropriate time, but this feel like a rather poor solution.


Cheers,
Matthias


As seen, you can't make GC allocations in dtors. And you should 
never rely on the GC calling your dtor to close things like file 
handles anyways. Consider making Dummy a struct and maybe using 
std.typecons(?).RefCounted with it.

Re: Module Clarification

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/22/16 4:16 PM, Jonathan Marler wrote:

On Thursday, 22 September 2016 at 20:09:41 UTC, Steven Schveighoffer wrote:


Before package.d support, you could not do any importing of packages.
You could only import modules. package.d was how the compiler allowed
importing packages.

I don't know that there is a fundamental difference between
foo/package.d and foo.d, but this is just the solution that was
chosen. Is it a mistake? I don't think so, it's just a preference.

Prior to this, it was common to put "package" imports into an "all.d"
file:

foo/all.d // import fooPart1.d fooPart2.d
foo/fooPart1.d



Ok, do you know why is this not allowed?


I'm sure if you search the forums, you can find discussions of this. 
Walter probably had a reason. I'm not sure if the reason is valid 
anymore now that package.d is supported.


-Steve

DMD: Finding symbol value references to enable more move optimizations in parameter passings

[Nordlöw via Digitalmars-d]

I'm currently trying to understand if it's possible to add more 
move-optimizations in parameter passing for those parameters 
whole symbols aren't used after the call or for `const` or 
`immutable` parameters to `@safe pure` (strictly pure) functions. 
This similar to function call optimizations possible in Rust but 
less restrictive because the symbol is allowed to be used after 
the call aswell.


Could somebody please highlight suitable places in DMD that 
checks if the value of a specific symbol is read or written to, 
typically inside a given `Scope` instance?


My guess is `doCopyOrMove` in `expression.d` is good contender, 
right?


Is this the place where I should scan for further references to 
expression if it's an Lvalue?


If there currently is no such code that does this, does anybody 
have any advice on how to write this?


Further, AFAICT, parameters passed as `const` or `immutable` to 
`@safe pure` functions can also be passed with a move.


This traversal is a key-feature that could also provide better 
diagnostics for unused symbols.


I also realize the risk of introducing quadratic complexity in 
`doCopyOrMove` but this can be avoided by memoizing the result of 
the symbol scan upon the first call to `doCopyOrMove` for the 
Lvalue case.


I've tried posting this the DMD group but it enters an infinite 
post loop. I have registered my email and name on the mailing 
list aswell.

Re: Required DMD changes for Mir and few thoughts about D future

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 27 September 2016 at 11:33:54 UTC, Johan Engelen 
wrote:
An extra subjective comment from recent experience: I think LDC 
has been very responsive to Mir's needs, thinking _with_ Mir 
development instead of fighting it and debating things to 
death. Imagine you are developing Mir, want to get something 
done, and then read the discussion starting here

https://forum.dlang.org/post/brieiuuuslpzfeiox...@forum.dlang.org
The LDC PR with the requested functionality was submitted less 
than two weeks after

(pull was stalled because we don't control our own frontend).


I've read the thread. I think Walter was right and correctly 
advised you the whole thread. One thing Mir users will do is 
copying executables from machine to machines. If it has runtime 
dispatch, it will work everywhere.

Re: DIP 1002 (TryElseExpression) added to the queue

[Steven Schveighoffer via Digitalmars-d]

On 9/27/16 6:55 AM, John Colvin wrote:


What's annoying is that we already have finally,  which can be
reproduced with other language features:

{
/*finally*/ scope (exit) {}
try {
do_something();
} catch (Exception e) {}
}


Hm... I always thought scope(exit) is lowered to:

try
{
}
finally
{
   // scope exit code here
}

Which one is the building block? ;)


but we don't (yet) have catch else, which is harder to immitate. Options
are:
A) the else clause is nothrow (in which case it can just go last inside
the try)
or
B) store a flag and have to use immitation finally:

{
/*finally*/ scope (exit) {}
bool exceptionThrown = false;
try {
doSomething();
} catch (Exception e) {
exceptionThrown = true;
}
/*else*/ if (!exceptionThrown) {}
}


I tried a few things, including scope(success), but it doesn't seem 
doable without an extra piece of data.


Essentially, the else clause allows you to split your try block into 
catch-protected code, and non-catch-protected code.


Seems like a worthwhile addition, if easily implemented.

-Steve

Re: Linking D code into existing C programs

[Steven Schveighoffer via Digitalmars-d]

On 9/27/16 4:12 AM, Walter Bright wrote:

On 9/27/2016 12:03 AM, Jacob Carlborg wrote:

You're not linking druntime.


That's one issue. The other one is druntime needs to be initialized, and
calling a random D function won't do that.



Does it? your function seems to not require any druntime features.

I would say -betterC is the way to fix this, as conservatively not 
emitting druntime requirements is probably a lot more involved than a 
directive from the build that no druntime is required.


-Steve

Re: How to debug (potential) GC bugs?

[Guillaume Piolat via Digitalmars-d-learn]

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp 
wrote:

Hello!
I am working together with others on the D-based 
appstream-generator[1] project, which is generating software 
metadata for "software centers" and other package-manager 
functionality on Linux distributions, and is used by default on 
Debian, Ubuntu and Arch Linux.


For Ubuntu, some modifications on the code were needed, and 
apparently for them the code is currently crashing in the GC 
collection thread: http://paste.debian.net/840490/


The project is running a lot of stuff in parallel and is using 
the GC (if the extraction is a few seconds slower due to the GC 
being active, it doesn't matter much).


We also link against a lot of 3rd-party libraries and use a big 
amount of existing C code in the project.


So, I would like to know the following things:




1) Is there any caveat when linking to C libraries and using 
the GC in a project? So far, it seems to be working well, but 
there have been a few cases where I was suspicious about the GC 
actually doing something to malloc'ed stuff or C structs 
present in the bindings.


There is no way the GC scans memory allocated with malloc (unless 
you tell it to) or used in the bindings.
A caveat is that if you are called from C (not your case), you 
must initialize the runtime, and attach/detach threads.


The GC could well stop threads that are currently in the C code 
if they were registered to the runtime.



2) How can one debug issues like the one mentioned above 
properly? Since it seems to happen in the GC and doesn't give 
me information on where to start searching for the issue, I am 
a bit lost.


There can be multiple reasons.
  - The GC is collecting some object that is unreachable from its 
POV; when you are actually using it.
  - The GC is calling destructors, that should not be called by 
the GC. Performing illegal operations. usually this is solved by 
using deterministic destruction instead and never relying on a 
destructor called by the GC.
  - The GC tries to stop threads that don't exist anymore or are 
not interruptible


My advice is to have a fuly deterministic tree of objects, like a 
C++ program, and Google for "GC-proof resource class" in case you 
are using classes.

Re: Argumnentation against external function operator overloading is unconvincing

[Steven Schveighoffer via Digitalmars-d]

On 9/25/16 9:48 AM, Jonathan M Davis via Digitalmars-d wrote:

On Sunday, September 25, 2016 13:10:42 ZombineDev via Digitalmars-d wrote:

D's built-in dynamic arrays are hidden from you and you only get
to interact with them by referring to their elements by using
slices.


That's a common misconception propagated by Steven's otherwise excellent
article. As far as the official language spec goes, T[] _is_ the dynamic
array. What backs it is irrelevant as far as that goes. It's just that if
it's backed by the GC, then when you append to it, the GC might not have to
allocate a new memory buffer for the array. All of the operations on a
dynamic array work the same regardless of what backs it, and focusing on the
memory buffer being the array risks causing you problems when you have to
deal with dynamic arrays backed by something else.


D can call an animal that quacks, has a flat bill, and feathers a 
sparrow all it wants, but it sure doesn't act like one ;)


-Steve

Re: Is there any way to have [] overloads use compile-time indexes as is currently done for Tuples?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 09:21:04 UTC, pineapple wrote:
I'd really like to define my own types that accept indexes for 
opIndex and opSlice as template arguments. Is there any way to 
do this? If not, this seems like an obvious thing to add to the 
language - what's been holding it back?


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

Re: Required DMD changes for Mir and few thoughts about D future

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:48:40 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat 
wrote:
On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei 
Alexandrescu wrote:
I'm not going to argue this much further. Essentially Mir is 
touted as a highly generic and portable library. Having it 
only work on one language implementation works against that 
statement, the credibility of Mir, and the credibility of D 
as an universal platform for creating fast code.


Isn't it just a matter of adding "version(LDC)" around the 
more optimized blocks?

Having it work in DMD, however slower, is good enough.


50 times slower for modern CPUs.


version (DMD)
{
pragma(message, "It seems you are building with DMD instead 
of LDC. Be aware that some functions will go up to 50x slower");

}

=> no misrepresentation of Mir performance
=> the user testing Mir keeps testing instead of having it not 
working

Re: dont understand this

[Steven Schveighoffer via Digitalmars-d]

On 9/25/16 1:48 AM, collerblade wrote:

threadFunc contains a reference to MyClass in the form of the 'this'
pointer and so the GC sees this and never deallocates the MyClass
instance to begin with.


Yes i am a ware about that fact, but when i set "running" to static, the
solution WORKS. That is what the question is.


There is a misunderstanding here. It works because a static variable is 
*NOT* shared between threads.


i.e., make running static, then remove the set to false in the 
destructor, and you still will have the thread exit.


You cannot make a thread function that uses a delegate of a thread, 
which contains a pointer to that thread, and then expect the GC to kill 
the thread.


I know what you are trying to do, but I don't think you can do it with 
D's Thread objects. What you want to do is use a reference counter, and 
run the thread as long as the reference count is greater than 1. Then 
store your state in that object.


You can probably learn how to do this by reading the code for 
std.typecons.RefCounted.


-Steve

Re: JSON decode?

[Andre Pany via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 10:45:45 UTC, Andre Pany wrote:

Hi,

from a rest call I get a JSON with a strange format:

{"DEPLOY_ATTRIBUTES":"{\n  \"dependency-type\": 
\"soft\"\n}","MTA_METADATA":"{\n  \"id\":...


The sub objects are enclosed with quotes and there are a lot of 
line break characters.

Also the quotes are escaped.
I try to translate a Python script which has no issues to 
handle this JSON correctly,

but I do not understand why.

Python seems to handle this with decode('utf-8')? Is there some 
functionality in Phobos to handle this format correctly?


Kind regards
André


OK, I found the solution. There is no magic in python. For these 
kinds of attributes the python code checks whether it is a 
string, and then tries to parse again as JSON, wired!


Kind regards
André

Re: Easy sockets - don't exist yet?

[JN via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 11:16:00 UTC, Russel Winder 
wrote:
On Tue, 2016-09-27 at 10:16 +, JN via Digitalmars-d-learn 
wrote:
On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder 
wrote:
> 
> Why not just create a binding to 0MQ and get much, much more 
> than asked for?
> 

http://code.dlang.org/packages/zmqd 
http://code.dlang.org/packages/zeromq 
http://code.dlang.org/packages/dzmq


or use existing ones :)


Even better, except it would be good if there was one. Maybe 
the authors of these three can get together and make a single 
binding to avoid dispersion.


Not really, because some of these are just pure C bindings, while 
some offer D wrappers for the ZeroMQ interface. Both are good to 
have, depending on the needs.

Re: Required DMD changes for Mir and few thoughts about D future

[Johan Engelen via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat 
wrote:
On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei 
Alexandrescu wrote:
I'm not going to argue this much further. Essentially Mir is 
touted as a highly generic and portable library. Having it 
only work on one language implementation works against that 
statement, the credibility of Mir, and the credibility of D as 
an universal platform for creating fast code.


Isn't it just a matter of adding "version(LDC)" around the more 
optimized blocks?

Having it work in DMD, however slower, is good enough.


(copying from the previous thread:)

I thought so too but if the algorithm is 50x slower, it probably 
means you can't develop that algorithm any more (I wouldn't). I 
think the common use-case for Mir is a calculation that takes 
seconds, so 50x turns a test into a run of several minutes, 
defeating the compilation speed advantage of DMD. The way I see 
it, faster development with Mir+DMD is not possible.


It is easy to want something, but someone else has to do it and 
live with it too. It's up to the Mir devs (**volunteers!**) to 
choose which compilers they support. As you can see from the PR 
that removed DMD support, the extra burden is substantial.

https://github.com/libmir/mir/pull/347

An extra subjective comment from recent experience: I think LDC 
has been very responsive to Mir's needs, thinking _with_ Mir 
development instead of fighting it and debating things to death. 
Imagine you are developing Mir, want to get something done, and 
then read the discussion starting here

https://forum.dlang.org/post/brieiuuuslpzfeiox...@forum.dlang.org
The LDC PR with the requested functionality was submitted less 
than two weeks after

(pull was stalled because we don't control our own frontend).

Re: Required DMD changes for Mir and few thoughts about D future

[Walter Bright via Digitalmars-d]

On 9/27/2016 3:36 AM, Ilya Yaroshenko wrote:

Will fill them tomorrow --Ilya


Thank you. Looking forward to it.

Re: Required DMD changes for Mir and few thoughts about D future

[Walter Bright via Digitalmars-d]

On 9/27/2016 3:48 AM, Ilya Yaroshenko wrote:

50 times slower for modern CPUs.


I understand, and that's a drastic speed difference. But removing support for 
dmd can have the effect of balkanizing the D community. That's happened in the 
past, and it was terrible for all of us.


I have looked at:

  https://github.com/libmir/mir/pull/347/files

I propose as a first step we can work towards eliminating the conditional 
compilation based on which compiler is running. Then we can look for low hanging 
fruit on the codegen to reduce the performance gap.

Re: Easy sockets - don't exist yet?

[Russel Winder via Digitalmars-d-learn]

On Tue, 2016-09-27 at 10:16 +, JN via Digitalmars-d-learn wrote:
> On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder 
> wrote:
> > 
> > Why not just create a binding to 0MQ and get much, much more 
> > than asked for?
> > 
> 
> http://code.dlang.org/packages/zmqd
> http://code.dlang.org/packages/zeromq
> http://code.dlang.org/packages/dzmq
> 
> or use existing ones :)

Even better, except it would be good if there was one. Maybe the
authors of these three can get together and make a single binding to
avoid dispersion.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +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: DIP 1002 (TryElseExpression) added to the queue

[John Colvin via Digitalmars-d]

On Tuesday, 27 September 2016 at 09:30:10 UTC, Dicebot wrote:

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

PR: https://github.com/dlang/DIPs/pull/43

Abstract:

In Python, the try/catch/finally syntax is augmented with an 
additional clause, termed else. It is a fantastically useful 
addition to the conventional syntax. It works like this:


```
try:
do_something()
except Exception as e:
pass # Runs when an error inheriting from Exception was 
raised

else:
pass # Runs when no error was raised
finally:
pass # Runs unconditionally, evaluates last
```


What's annoying is that we already have finally,  which can be 
reproduced with other language features:


{
/*finally*/ scope (exit) {}
try {
do_something();
} catch (Exception e) {}
}

but we don't (yet) have catch else, which is harder to immitate. 
Options are:
A) the else clause is nothrow (in which case it can just go last 
inside the try)

or
B) store a flag and have to use immitation finally:

{
/*finally*/ scope (exit) {}
bool exceptionThrown = false;
try {
doSomething();
} catch (Exception e) {
exceptionThrown = true;
}
/*else*/ if (!exceptionThrown) {}
}

[Issue 16489] [backend][optimizaton][registers] DMD is 10-20 times slower for GLAS

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||SIMD

--

Re: Required DMD changes for Mir and few thoughts about D future

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat 
wrote:
On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei 
Alexandrescu wrote:
I'm not going to argue this much further. Essentially Mir is 
touted as a highly generic and portable library. Having it 
only work on one language implementation works against that 
statement, the credibility of Mir, and the credibility of D as 
an universal platform for creating fast code.


Isn't it just a matter of adding "version(LDC)" around the more 
optimized blocks?

Having it work in DMD, however slower, is good enough.


50 times slower for modern CPUs.

Re: Linking D code into existing C programs

[Johan Engelen via Digitalmars-d]

On Monday, 26 September 2016 at 23:32:05 UTC, Walter Bright wrote:
Linking C libraries and object code into D programs has always 
worked easily in D. The other way around, not so well.


[snip]

How much of an issue is this with D? Is it something we need to 
address?


We've been toying with this in setting up LDC's build such that 
it works on different platforms. Wait, "toying" implies "fun". It 
was anything but.
At first, we used the D compiler to do the final linking, but it 
resulted in troubles when special linker flags are needed.
We've now moved to using the system linker separately to do the 
linking.

https://github.com/ldc-developers/ldc/pull/1594

For this, we use `-v` to figure out what the system linker is and 
what linker flags are passed by the D compiler (link with phobos, 
druntime, etc.). But it needs "parsing" of `-v` output, quite 
annoying.
See 
https://github.com/ldc-developers/ldc/blob/master/cmake/Modules/ExtractDMDSystemLinker.cmake


The idea to add a cmdline flag `-ldflags` that would just output 
the linking flags, did not get a response.

https://forum.dlang.org/post/gqaujnbgbpauirbez...@forum.dlang.org
I think it will save people a lot of time and frustration. 
(possible improvements can be made such that the output of 
`-ldflags` also includes extra link flags when special compiler 
flags are passed, such as `-fprofile-instr-generate`.)


-Johan

JSON decode?

[Andre Pany via Digitalmars-d-learn]

Hi,

from a rest call I get a JSON with a strange format:

{"DEPLOY_ATTRIBUTES":"{\n  \"dependency-type\": 
\"soft\"\n}","MTA_METADATA":"{\n  \"id\":...


The sub objects are enclosed with quotes and there are a lot of 
line break characters.

Also the quotes are escaped.
I try to translate a Python script which has no issues to handle 
this JSON correctly,

but I do not understand why.

Python seems to handle this with decode('utf-8')? Is there some 
functionality in Phobos to handle this format correctly?


Kind regards
André

[Issue 16550] Generic SIMD shuffle for Mir

[via Digitalmars-d-bugs]

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

--- Comment #2 from Илья Ярошенко  ---
__vector(float[8]) a; // re0 im0 re1 im1 re2 im2 re3 im3
__vector(float[8]) b; // re4 im4 re5 im5 re6 im6 re7 im7

// Packing
__vector(float[8]) re = extractRe(a, b); // re0 re1 re2 re3 re4 re5 re6 re7
__vector(float[8]) im = extractIm(a, b); // im0 im1 im2 im3 im4 im5 im6 im7

// Unpacking
__vector(float[8]) c = mix0(re, im); //re0 im0 re1 im1 re2 im2 re3 im3
__vector(float[8]) d = mix1(re, im); //re4 im4 re5 im5 re6 im6 re7 im7


assert(c == a);
assert(d == b);

--

Re: Required DMD changes for Mir and few thoughts about D future

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei 
Alexandrescu wrote:
I'm not going to argue this much further. Essentially Mir is 
touted as a highly generic and portable library. Having it only 
work on one language implementation works against that 
statement, the credibility of Mir, and the credibility of D as 
an universal platform for creating fast code.


Isn't it just a matter of adding "version(LDC)" around the more 
optimized blocks?

Having it work in DMD, however slower, is good enough.

Re: Required DMD changes for Mir and few thoughts about D future

[Walter Bright via Digitalmars-d]

On 9/27/2016 3:20 AM, Andrei Alexandrescu wrote:

Can we make sure all issues that Mir has with dmd and gdc be present in bugzilla
and tagged with "Mir"? Thanks! -- Andrei


The ones I've seen so far have all been SIMD issues, and I've been tagging them 
that way.

Re: Required DMD changes for Mir and few thoughts about D future

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:20:09 UTC, Andrei 
Alexandrescu wrote:

On 9/27/16 10:50 AM, Ilya Yaroshenko wrote:
On Tuesday, 27 September 2016 at 07:01:08 UTC, Jacob Carlborg 
wrote:

On 2016-09-26 21:49, bachmeier wrote:


[...]


He mentions several front end issues, those apply to LDC as 
well.


No, LDC for example does not have the issue
https://issues.dlang.org/show_bug.cgi?id=16488 and others too.


Can we make sure all issues that Mir has with dmd and gdc be 
present in bugzilla and tagged with "Mir"? Thanks! -- Andrei


Will fill them tomorrow --Ilya

Re: Required DMD changes for Mir and few thoughts about D future

[Walter Bright via Digitalmars-d]

On 9/27/2016 2:21 AM, Ilya Yaroshenko wrote:

Bug report for (5) https://issues.dlang.org/show_bug.cgi?id=16550 :


Thank you. Please see my comment on it. Also, please tag all SIMD Bugzilla 
issues with the SIMD keyword (I already did it for 16550).

[Issue 16550] Generic SIMD shuffle for Mir

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||SIMD

--

[Issue 16550] Generic SIMD shuffle for Mir

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Could you please add some example code that should compile and what it should
do?

--

Re: Required DMD changes for Mir and few thoughts about D future

[Guillaume Piolat via Digitalmars-d]

On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko 
wrote:


1. Lightweight `nothrow @nogc` threads, implemented using 
`struct`s
2. Lightweight `nothrow @nogc` mutexes and barriers, 
implemented using `struct`s


FWIW I have some @nogc mutex and semaphore here:
https://github.com/AuburnSounds/dplug/blob/master/core/dplug/core/unchecked_sync.d

Ways to make the runtime more optional than it is would be great.

Re: Required DMD changes for Mir and few thoughts about D future

[Andrei Alexandrescu via Digitalmars-d]

On 9/27/16 10:50 AM, Ilya Yaroshenko wrote:

On Tuesday, 27 September 2016 at 07:01:08 UTC, Jacob Carlborg wrote:

On 2016-09-26 21:49, bachmeier wrote:


To me, it seems pointless to support Mir in DMD. The "functionality"
that it brings is speed. Nobody needing absolutely the fastest code is
not going to have any interest in DMD. From what I understand of Mir
(but correct me if I'm wrong) it is easy enough to replicate its
functionality by linking to existing linear algebra libraries. Others
can construct a compatible interface if that's something they want.

I think Ilya and everyone else working on Mir should push forward with
the LDC-based project. Anything else is a distraction.


He mentions several front end issues, those apply to LDC as well.


No, LDC for example does not have the issue
https://issues.dlang.org/show_bug.cgi?id=16488 and others too.


Can we make sure all issues that Mir has with dmd and gdc be present in 
bugzilla and tagged with "Mir"? Thanks! -- Andrei

Re: Easy sockets - don't exist yet?

[JN via Digitalmars-d-learn]

On Tuesday, 27 September 2016 at 09:23:35 UTC, Russel Winder 
wrote:
Why not just create a binding to 0MQ and get much, much more 
than asked for?




http://code.dlang.org/packages/zmqd
http://code.dlang.org/packages/zeromq
http://code.dlang.org/packages/dzmq

or use existing ones :)

Re: DIP 1002 (TryElseExpression) added to the queue

[pineapple via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:05:20 UTC, Idan Arye wrote:
BTW, if this feature is ever implemented in D, it's important 
that the else clause will continue the try clause's scope.


The catch and finally clauses do currently continue the scope, 
right? (If they don't, they probably should, too.)

Re: DIP 1002 (TryElseExpression) added to the queue

[pineapple via Digitalmars-d]

On Tuesday, 27 September 2016 at 09:48:42 UTC, Jonathan M Davis 
wrote:
And why not just put the code that would go in the else at the 
end of the try block? Just like with this proposed else, the 
code would only run if the preceding code didn't throw any 
exceptions. This just seems like an attempt to make D more like 
python rather than to add anything useful.


- Jonathan M Davis


This is a commonly-used tool that makes code more readable and 
cuts down on programmer error.


It's far more concise and digestible than the functional 
equivalent, which is _not_ to put the code at the end of the 
`try` block, it's to put it in the `finally` block - refer to the 
DIP's example for how that works.


This is the most important difference between using `else` and 
doing what you described: Exceptions thrown by the code in the 
`else` block are not caught by the `catch` statements intended to 
handle errors by the operation in the `try` block, but not to 
handle errors resulting from attempting to handle a success state.

Re: DIP 1002 (TryElseExpression) added to the queue

[Idan Arye via Digitalmars-d]

On Tuesday, 27 September 2016 at 09:48:42 UTC, Jonathan M Davis 
wrote:
On Tuesday, September 27, 2016 09:30:10 Dicebot via 
Digitalmars-d wrote:

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

PR: https://github.com/dlang/DIPs/pull/43

Abstract:

In Python, the try/catch/finally syntax is augmented with an 
additional clause, termed else. It is a fantastically useful 
addition to the conventional syntax. It works like this:


```
 try:
 do_something()
 except Exception as e:
 pass # Runs when an error inheriting from Exception 
was

raised
 else:
 pass # Runs when no error was raised
 finally:
 pass # Runs unconditionally, evaluates last
```


And why not just put the code that would go in the else at the 
end of the try block? Just like with this proposed else, the 
code would only run if the preceding code didn't throw any 
exceptions. This just seems like an attempt to make D more like 
python rather than to add anything useful.


- Jonathan M Davis


Exceptions thrown in the `else` clause are not caught in the 
catch/expect clauses. This gives you finer grained control:



try {
auto f1 = File("f1.txt");
} catch (ErrnoException) {
// f1.txt not found? no biggie...
} else {
// This won't happen if we can't open f1.txt

// If we can't open f2 we don't want to catch the 
exception:

auto f2 = File("f2.txt", "w");

// Do stuff with f1 and f2
}

// This will still happen even if we can't open f1.txt


BTW, if this feature is ever implemented in D, it's important 
that the else clause will continue the try clause's scope.

Re: DIP 1002 (TryElseExpression) added to the queue

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 27, 2016 09:30:10 Dicebot via Digitalmars-d wrote:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md
>
> PR: https://github.com/dlang/DIPs/pull/43
>
> Abstract:
>
> In Python, the try/catch/finally syntax is augmented with an
> additional clause, termed else. It is a fantastically useful
> addition to the conventional syntax. It works like this:
>
> ```
>  try:
>  do_something()
>  except Exception as e:
>  pass # Runs when an error inheriting from Exception was
> raised
>  else:
>  pass # Runs when no error was raised
>  finally:
>  pass # Runs unconditionally, evaluates last
> ```

And why not just put the code that would go in the else at the end of the
try block? Just like with this proposed else, the code would only run if the
preceding code didn't throw any exceptions. This just seems like an attempt
to make D more like python rather than to add anything useful.

- Jonathan M Davis

Re: Linking D code into existing C programs

[Dicebot via Digitalmars-d]

Don't think it can be made much better for object files but it 
should be relatively simple to enable creating "C-friendly" 
static D libraries that include all required runtime bits as part 
of the library.

DIP 1002 (TryElseExpression) added to the queue

[Dicebot via Digitalmars-d]

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

PR: https://github.com/dlang/DIPs/pull/43

Abstract:

In Python, the try/catch/finally syntax is augmented with an 
additional clause, termed else. It is a fantastically useful 
addition to the conventional syntax. It works like this:


```
try:
do_something()
except Exception as e:
pass # Runs when an error inheriting from Exception was 
raised

else:
pass # Runs when no error was raised
finally:
pass # Runs unconditionally, evaluates last
```

Re: Linking D code into existing C programs

[Jacob Carlborg via Digitalmars-d]

On 2016-09-27 11:18, Jacob Carlborg wrote:

On 2016-09-27 10:12, Walter Bright wrote:


That's one issue. The other one is druntime needs to be initialized, and
calling a random D function won't do that.


Long time ago I suggested doing that [1]. Not sure if that file is
currently compiled and linked into the runtime. But, IIRC, there was
complains when I suggested doing this because, as I was told, if you're
using a D library in a C application you most likely want to have more
control of the initialization of druntime.

[1] https://github.com/dlang/druntime/blob/master/src/rt/dylib_fixes.c



"doing that", I meant to say "automatically initialize druntime".

--
/Jacob Carlborg

Re: Required DMD changes for Mir and few thoughts about D future

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 27 September 2016 at 09:20:28 UTC, Jacob Carlborg 
wrote:

On 2016-09-27 10:50, Ilya Yaroshenko wrote:


No, LDC for example does not have the issue
https://issues.dlang.org/show_bug.cgi?id=16488 and others too.


Does LDC has: "Lightweight `nothrow @nogc` threads, implemented 
using `struct`s" ?


They are coming soon. LLVM has OpenCL and CUDA backend. OpenCL 
can be used both for CPU and GPU targets. So, yes, Mir will have 
[1, 2] lightweight `nothrow @nogc` threads with LDC.


1. https://github.com/libmir/dcompute
2. https://github.com/ldc-developers/ldc/pull/1786

Re: Required DMD changes for Mir and few thoughts about D future

[Jacob Carlborg via Digitalmars-d]

On 2016-09-27 10:53, Ilya Yaroshenko wrote:


They are (except Win32?), but we need to exclude DRuntime dependency.
Mir does not use Druntime and will not use it anyway because DRuntime is
not `nothrow @nogc`.


I tried this using ldc 1.1.0 beta 2 (Frontend, druntime and Phobos are 
at version 2.071.1) and DMD 2.071.1:


$ cat main.d
module main;

import std.stdio;

void main()
{
writeln("foo");
}

$ ./ldc2 -c main.d && dmd main.o
Undefined symbols for architecture x86_64:
  "__D3std3utf6toUTF8FNaNbNiNfNkJG4awZAa", referenced from:
  __D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNbNiNfwZv 
in main.o

  "__D3std5stdio12__ModuleInfoZ", referenced from:
  __D4main12__ModuleInfoZ in main.o
  "__D3std5stdio13trustedStdoutFNdNeZS3std5stdio4File", referenced from:
  __D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv in main.o
  "__D3std5stdio14fputc_unlockedFNbNiiPS4core4stdc5stdio7__sFILEZi", 
referenced from:


__D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ12trustedFPUTCFNbNiNeiPS4core4stdc5stdio7__sFILEZi 
in main.o


__D3std5stdio4File17LockingTextWriter10__T3putTaZ3putMFNfaZ12trustedFPUTCFNbNiNeiPS4core4stdc5stdio7__sFILEZi 
in main.o
  "__D3std5stdio15fputwc_unlockedFNbNiwPS4core4stdc5stdio7__sFILEZi", 
referenced from:


__D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ13trustedFPUTWCFNbNiNewPS4core4stdc5stdio7__sFILEZi 
in main.o


__D3std5stdio4File17LockingTextWriter10__T3putTaZ3putMFNfaZ13trustedFPUTWCFNbNiNewPS4core4stdc5stdio7__sFILEZi 
in main.o

  "__D3std5stdio4File17LockingTextWriter6__dtorMFNeZv", referenced from:
  __D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv in main.o

"__D3std5stdio4File17lockingTextWriterMFNfZS3std5stdio4File17LockingTextWriter", 
referenced from:

  __D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv in main.o
  "__D3std5stdio4File6__dtorMFNfZv", referenced from:
  __D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv in main.o

"__D3std9exception14ErrnoException6__ctorMFNeAyaAyamZC3std9exception14ErrnoException", 
referenced from:
  __D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv 
in main.o


__D3std9exception187__T12errnoEnforceTiVAyaa76_2f55736572732f6a61636f622f446f776e6c6f6164732f6c6463322d312e312e302d62657461322d6f73782d7838365f36342f62696e2f2e2e2f696d706f72742f7374642f737464696f2e64Vmi2640Z12errnoEnforceFNfiLAyaZi 
in main.o

  "__D3std9exception14ErrnoException6__initZ", referenced from:
  __D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv 
in main.o


__D3std9exception187__T12errnoEnforceTiVAyaa76_2f55736572732f6a61636f622f446f776e6c6f6164732f6c6463322d312e312e302d62657461322d6f73782d7838365f36342f62696e2f2e2e2f696d706f72742f7374642f737464696f2e64Vmi2640Z12errnoEnforceFNfiLAyaZi 
in main.o

  "__D3std9exception14ErrnoException6__vtblZ", referenced from:
  __D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv 
in main.o


__D3std9exception187__T12errnoEnforceTiVAyaa76_2f55736572732f6a61636f622f446f776e6c6f6164732f6c6463322d312e312e302d62657461322d6f73782d7838365f36342f62696e2f2e2e2f696d706f72742f7374642f737464696f2e64Vmi2640Z12errnoEnforceFNfiLAyaZi 
in main.o

  "__D3std9exception14ErrnoException7__ClassZ", referenced from:
  __D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv 
in main.o


__D3std9exception187__T12errnoEnforceTiVAyaa76_2f55736572732f6a61636f622f446f776e6c6f6164732f6c6463322d312e312e302d62657461322d6f73782d7838365f36342f62696e2f2e2e2f696d706f72742f7374642f737464696f2e64Vmi2640Z12errnoEnforceFNfiLAyaZi 
in main.o

  "__Dmodule_ref", referenced from:
  __D4main16__moduleinfoCtorZ in main.o
  "__d_eh_personality", referenced from:
  Dwarf Exception Unwind Info (__eh_frame) in main.o
  "__d_eh_resume_unwind", referenced from:
  __D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv in main.o
  "__d_throw_exception", referenced from:
  __D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv 
in main.o


__D3std9exception187__T12errnoEnforceTiVAyaa76_2f55736572732f6a61636f622f446f776e6c6f6164732f6c6463322d312e312e302d62657461322d6f73782d7838365f36342f62696e2f2e2e2f696d706f72742f7374642f737464696f2e64Vmi2640Z12errnoEnforceFNfiLAyaZi 
in main.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

--- errorlevel 1

--
/Jacob Carlborg

[Issue 16551] New: Compile-time delegate parameters should allow "scope"

[via Digitalmars-d-bugs]

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

  Issue ID: 16551
   Summary: Compile-time delegate parameters should allow "scope"
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Currently, in order to pass scoped delegates and avoid GC, one must pass the
delegates as run-time parameters, with undesirable consequences.

It would be very helpful to allow them to be passed as scoped and in
compile-time.

alias Foo1 = void delegate() @nogc;
alias Foo2 = scope void delegate() @nogc; // <-- this "scope" seems to be
completely ignored!

// Syntax error, why? :(
// void foo(scope Foo1 x)() @nogc;

// This is allowed, but Foo2 is not truly "scope"
void foo(Foo2 x)() @nogc;

void main() @nogc {
int x;
foo!({x+=1;}); // Claims to allocate with the gc, it does not!
}

--

Re: Required DMD changes for Mir and few thoughts about D future

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 27 September 2016 at 03:49:18 UTC, Walter Bright 
wrote:

On 9/26/2016 11:43 AM, Ilya Yaroshenko wrote:
I think we need to make it a point to support Mir in dmd. -- 
Andrei


Required features for Level 3:
1. https://issues.dlang.org/show_bug.cgi?id=16489
2. https://issues.dlang.org/show_bug.cgi?id=16488
3. AVX & AVX2 floating point vector arithmetic
4. Generic unaligned load/store like (like LDC loadUnaligned 
and storeUnaligned)
5. Generic routine to pack and unpack real and imaginary 
parts. For usage

example, see
https://github.com/libmir/mir/blob/master/source/mir/glas/internal/copy.d#L699


Could you provide more detail on these, please?

For example, on the last link there is no documentation on what 
those templates do or what their parameters are. For example,


  template _mix0(V)
  {
import ldc.simd;
enum _pred(size_t a) = (a & 1) == 0 ? a / 2 : a / 2 + 
V.length;
alias _mix0 = shufflevector!(V, staticMap!(_pred, 
Iota!(V.length)));

  }

??

I'd like to see each of the points at least put into an 
Enhancement Request on bugzilla, where we can evaluate them in 
an organized fashion. (Like what you've done for (1) and (2).)


Bug report for (5) https://issues.dlang.org/show_bug.cgi?id=16550 
:



Vec1
re0 im0 re1 im1 re2 im2 re3 im3 // __vector(float[8])

Vec2
re4 im4 re5 im5 re6 im6 re7 im7 // __vector(float[8])

< unpack -- pack >

VecReal
re0 re1 re2 re3 re4 re5 re6 re7 // __vector(float[8])

VecIm
im0 im1 im2 im3 im4 im5 im6 im7 // __vector(float[8])

Re: Required DMD changes for Mir and few thoughts about D future

[Jacob Carlborg via Digitalmars-d]

On 2016-09-27 10:50, Ilya Yaroshenko wrote:


No, LDC for example does not have the issue
https://issues.dlang.org/show_bug.cgi?id=16488 and others too.


Does LDC has: "Lightweight `nothrow @nogc` threads, implemented using 
`struct`s" ?


--
/Jacob Carlborg

Is there any way to have [] overloads use compile-time indexes as is currently done for Tuples?

[pineapple via Digitalmars-d-learn]

I'd really like to define my own types that accept indexes for 
opIndex and opSlice as template arguments. Is there any way to do 
this? If not, this seems like an obvious thing to add to the 
language - what's been holding it back?

Re: Easy sockets - don't exist yet?

[Russel Winder via Digitalmars-d-learn]

Why not just create a binding to 0MQ and get much, much more than asked
for?

On Mon, 2016-09-26 at 23:40 +, Vincent via Digitalmars-d-learn
wrote:
> Hello, guys!
> 
> I was very surprised that module 'socketstream' was deprecated. 
> Usually if something become obsolete, there is some perfect 
> replacement! But my digging in Inet and forums gave nothing, but 
> "outdated" examples with 'SocketStream' class. So first question 
> is WHAT Phobos has to replace SocketStream?
> To avoid unnecessary mail bouncing, I write upfront what I expect 
> from normal Socket implementation (kind of interface) :
> 
> 1. Easy to use. No more stupid "UNIX sockets", "TCP types" and so 
> on. Just simple as this:
> 
> // Client side
> auto sock = new ClientSocket("google.com", 80);
> sock.WriteLine("GET / HTTP/1.0");
> sock.WriteLine("Host: google.com");
> sock.WriteLine();// empty line sent
> 
> // Server side:
> auto svc = new ServerSocket("Bound.To.This.IP", 1000);
> while ((auto ClientSock = svc.AcceptClient()) !is null) {
>  auto command = ClientSock.ReadLine();// this is important - 
> read by line, not idiotic "buffers of bytes"!
>   ClientSock.WriteLine(command ~ ` yourself!`);
>   ClientSock.Close();
> }
> 
> 2. Of course integration with std.stream could be nice, it gives 
> "for free" readLine and other methods.
> 3. Ability to 'get and forget': hardly all of us wanna deal with 
> "get portion, write portion to disk, blah". Simple 
> "sock.ReceiveFile(`http://porno/girl.avi`, 
> `c:\diploma_work.avi`)" could be enough.
> Some kind of "progress report" callback would be nice.
> 4. SSL/TLS out-of-the-box. In example above it should be same 
> easy as:
> 
> auto sock = new ClientSocket("google.com", 80, Proto.TLS);
> 
> 
> At the moment it's all I need, but hope you'll be happy too with 
> such interface. Sockets are SOOO important, that I cannot believe 
> we don't have so easy API now. Or if we have, please share!
> 
> Thanks everybody!
> 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +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: Linking D code into existing C programs

[Jacob Carlborg via Digitalmars-d]

On 2016-09-27 10:12, Walter Bright wrote:


That's one issue. The other one is druntime needs to be initialized, and
calling a random D function won't do that.


Long time ago I suggested doing that [1]. Not sure if that file is 
currently compiled and linked into the runtime. But, IIRC, there was 
complains when I suggested doing this because, as I was told, if you're 
using a D library in a C application you most likely want to have more 
control of the initialization of druntime.


[1] https://github.com/dlang/druntime/blob/master/src/rt/dylib_fixes.c

--
/Jacob Carlborg

[Issue 16550] New: Generic SIMD shuffle for Mir

[via Digitalmars-d-bugs]

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

  Issue ID: 16550
   Summary: Generic SIMD shuffle for Mir
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

Vec1
re0 im0 re1 im1 re2 im2 re3 im3 // __vector(float[8])

Vec2
re4 im4 re5 im5 re6 im6 re7 im7 // __vector(float[8])

< unpack -- pack >

VecReal
re0 re1 re2 re3 re4 re5 re6 re7 // __vector(float[8])

VecIm
im0 im1 im2 im3 im4 im5 im6 im7 // __vector(float[8])

--

Re: Linking D code into existing C programs

[Jacob Carlborg via Digitalmars-d]

On 2016-09-27 10:50, Claude wrote:


We've got to consider that when it is statically linked, and also
dynamically as well.

Also, if it's statically linked, will the linker just use parts of
druntime that are actually used by the D libtrary?

For instance, if the D library does not use exceptions, ideally it
should not link any related code in druntime (it's important, especially
in embedded software).


In will include module and type info. It might include some runtime 
functions for exceptions unless all functions are marked with "nothrow".


--
/Jacob Carlborg

[Issue 16489] [backend][optimizaton][registers] DMD is 10-20 times slower for GLAS

[via Digitalmars-d-bugs]

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

--- Comment #2 from Илья Ярошенко  ---
size_t length; // > 0
__vector(float[4])[2]* a; //aligned
float[6]* b;

__vector(float[4])[2][6] reg; // should be located in the registers 
// init reg = 0;

__vector(float[4])[2] ai = void;
__vector(float[4])[6] bi = void;


do {
   ai[0] = a[0][0]; // should be located in the registers 
   ai[1] = a[0][1]; // should be located in the registers 

   foreach(i; AliasSeq!(0, 1, 2, 3, 4, 5))
   {
  bi[i] = b[0][i]; // Issue 16488, // should be located in the registers 
  reg[i][0] += ai[0] * bi[i];
  reg[i][1] += ai[1] * bi[i];
   }

   a++;
   b++;
} while(--length);

--

Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

[Dsciple via Digitalmars-d-learn]

Hi there!

I wrote a small utility library to read configuration parameters 
from both command-line arguments (using std.getopt) and SDLang 
files (using sdlang-d package).
The main library defines a struct ConfigParams whose fields are 
themselves structs defined in sub-libraries (set as 
dependencies), each responsible for reading one kind of parameter 
(BindAddress, BindPort, etc) from both command-line and SDL 
files. Each sub-library has its own unit tests which run 
successfully in isolation.
Then, when putting everything together in the main struct 
CofigParams I get the compile-time error:


/usr/include/dlang/dmd/std/socket.d(1195,9): Error: static 
variable getaddrinfoPointer cannot be read at compile time

called from here: parseAddress(addressString, null)

while using std.socket.parseAddress to validate IPv4/IPv6 bind 
addresses.

I'm using dmd v2.071.2 and dub v1.0.0.
The relevant piece of code where this happens is the following:

struct BindAddress {

  import std.socket: parseAddress, SocketException;

  // Private members
  private string addressString = "0.0.0.0";

  // Construct from address string
  this(string addressString) {
try {
  auto address = parseAddress(addressString);
} catch(SocketException ex) {
  throw new BindAddressException("Invalid bind address " ~ 
addressString);

}
this.addressString = addressString;
  }

}

As said, this works fine when tested in isolation, and the 
compiler only complains when using BindAddress as a member of 
ConfigParams.

Any idea what the problem may be?
Or is there maybe a ready to use, high-level library for parsing 
parameters from command-line arguments and config files of some 
kind?

Re: SDLang-D v0.10.0 - Big convenience improvements

[Chris via Digitalmars-d-announce]

On Sunday, 25 September 2016 at 22:12:21 UTC, Nick Sabalausky 
wrote:

https://github.com/Abscissa/SDLang-D

New in v0.10.0:
Big convenience enhancements to DOM interface and an improved 
pull parser interface. Plus documentation improvements and a 
couple bugfixes.


Full changelog:
https://github.com/Abscissa/SDLang-D/blob/master/CHANGELOG.md

===

SDLang-D is a D library to read and write SDLang. Both a DOM 
and a Pull Parser are provided.


SDLang  is similar to XML/JSON/YAML, but 
much simpler and less verbose. It look like this:


-
// A few basic values
first "Joe"
last "Coder"
ip "127.0.0.1" port=80

// Supports child tags
folder "myFiles" color="yellow" protection=on {
folder "my documents" {
document "resume.pdf"
}
}
-
Language Guide: 
https://github.com/Abscissa/SDLang-D/wiki/Language-Guide


I was actually thinking of using SDL for pseudo code 
non-programmers could write, e.g. to create rule files that a 
program could execute. It could work nicely with `if` and `else` 
tags + attributes.

Re: Required DMD changes for Mir and few thoughts about D future

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 27 September 2016 at 08:53:36 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 27 September 2016 at 07:01:37 UTC, Jacob Carlborg 
wrote:

On 2016-09-27 02:52, Joakim wrote:
On Monday, 26 September 2016 at 20:11:19 UTC, Ilya Yaroshenko 
wrote:
Yes, the same true for Mir too. A precompiled library based 
on top of

Mir GLAS can be used with DMD.


Are you sure about this?  I thought there were ABI 
incompatibilities

between D compilers.


They're not ABI compatible.


They are (except Win32?), but we need to exclude DRuntime 
dependency. Mir does not use Druntime and will not use it 
anyway because DRuntime is not `nothrow @nogc`.


I mean extern(C) code