Re: See you soon at dconf

[Dukc via Digitalmars-d]

On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote:

Hope this time there is dmd on the machine!


perhaps you could alternatively use online compilers like DPaste, 
assuming there's an internet connection.


Of course depending on what you're doing.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote:

On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote:

[...]

I intended for the debugging functionality to be exposed via a 
udp socket listening on localhost.
Such that a debug-ui does not have to deal with ipc 
difficulties.


Hm, rationale for UDP over TCP here? I would assume one 
wouldn't want debugging info to be delivered out of order (or 
not at all); I mean, I guess it would be ok for localhost only 
(though one is then depending on implementation specifics vs. 
protocol semantics), but *if* you use sockets, you will 
eventually get people who use that over the network (and then 
the fun begins). Using TCP would just remove any potential 
future headache from the equation.


I think any ordering should be done explicitly at the debugging 
protocol level.
for example when sending sourceline messages the order is given 
by the line number and ordering can be done by the application.
It's the same for breakpoint setting or for breakpoint trigger 
notification.

As for lost packages, we want to respond intelligently as well.
And maybe reduce the amount of data in the package, to make 
arrival of future packages more likely.

Re: Top level associative arrays

[ANtlord via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 16:34:15 UTC, H. S. Teoh wrote:
On Tue, May 02, 2017 at 02:37:20PM +, ANtlord via 
Digitalmars-d-learn wrote:

On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:
> 
> Note that when declared as "enum", all places it's 
> referenced, a new associative array will be allocated.


If it is allocated at all places I can move initialization to 
module ctor as says evilrat but how can I make an immutable 
associative array?


Just declare it immutable. The module ctor can still initialize 
it, because ctors are allowed to initialize immutables:


--
immutable string[string] dict;
static this() {
dict = [
"abc": "def",
"ghi": "lmn"
];
}
void main() {
import std.stdio;
writeln(dict["abc"]);
}
--


T


Thanks a lot!

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 2 May 2017 at 23:27:28 UTC, Marco Leise wrote:

Am Tue, 02 May 2017 20:53:50 +
schrieb Moritz Maxeiner :


On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
>
> I see what you're doing there, but your last point is 
> wishful thinking. Dynamically linked binaries can share 
> megabytes of code. Even Phobos - although heavily templated 
> - has proven to be very amenable to sharing. For example, a 
> "Hello world!" program using `writeln()` has these sizes 
> when compiled with `dmd -O -release -inline`:

>
>  static Phobos2 : 806968 bytes
> dynamic Phobos2 :  18552 bytes
>
> That's about 770 KiB to share or 97.7% of its total size! 
> Awesome!


Is all of that active code, or is some of that (statically 
knowable) never getting executed (as in could've been removed 
at compile/link time)?


I guess David gave you the answer. So it's just 95.4% of its
total size. :p


Under the assumption that ldc2 produces no dead code in the 
output; is that a reasonable assumption (I'm not sure)?



By the way, is the fully dynamic linking version possible with
ldc2 now as well ?


I did have a modified ebuild to try that out a while back and it 
seemed to work fine in my limited testing scope. Since I quite 
often change installed d compilers and don't want my programs 
(like tilix) to stop working (or have old d compiler versions 
being kept installed *just* because some programs were built with 
them), I generally link against phobos statically, anyway, so I 
my tests weren't exhaustive. The cmake flag to to use in the 
ebuild would be BUILD_SHARED [1].


[1] 
https://github.com/ldc-developers/ldc/blob/v1.2.0/CMakeLists.txt#L522

Re: D and SCons

[Dmitry Olshansky via Digitalmars-d]

On 5/3/17 12:39 AM, H. S. Teoh via Digitalmars-d wrote:

On Wed, May 03, 2017 at 12:05:48AM +0200, Dmitry Olshansky via Digitalmars-d 
wrote:

On 5/2/17 2:20 PM, Russel Winder via Digitalmars-d wrote:

Hi,

Prompted by Bill Deegan (*), I have started a SCons wiki page on D
support. Even if you do not actually use SCons for D code, if you
are interested in D you are interested in this page as it is another
marketing vector for D.



I've come to like SCons for my C++ projects. Way more so than say
CMake.  It would be awesome to have full-fledged support for D there
esp. in mixed C++ with D setup.

[...]

I've been using SCons for many years now for both C/C++ and D projects,
and have been a happy camper.

However, I have to confess that I found Russel's D tooling (the last
time I tried it anyway, which was a while back) not quite up to what I'd
like it to do.


Could you elaborate on the limitations?


As a result, in my recent projects I've resorted simply
to:

env = Environment(DMD = '/path/to/dmd', DMDFLAGS = [ ... ])
env.Command('myprogram', Split("""
myprogram.d
module1.d
module2.d
"""),
"$DMD $DMDFLAGS -of$TARGET $SOURCES"
)ugh



Been doing just that as well. Find it less then ideal though.

---
Dmitry Olshansky

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Marco Leise via Digitalmars-d]

Am Tue, 02 May 2017 20:53:50 +
schrieb Moritz Maxeiner :

> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
> >
> > I see what you're doing there, but your last point is wishful 
> > thinking. Dynamically linked binaries can share megabytes of 
> > code. Even Phobos - although heavily templated - has proven to 
> > be very amenable to sharing. For example, a "Hello world!" 
> > program using `writeln()` has these sizes when compiled with 
> > `dmd -O -release -inline`:
> >
> >  static Phobos2 : 806968 bytes
> > dynamic Phobos2 :  18552 bytes
> >
> > That's about 770 KiB to share or 97.7% of its total size! 
> > Awesome!  
> 
> Is all of that active code, or is some of that (statically 
> knowable) never getting executed (as in could've been removed at 
> compile/link time)?

I guess David gave you the answer. So it's just 95.4% of its
total size. :p
By the way, is the fully dynamic linking version possible with
ldc2 now as well ?

-- 
Marco

Re: [OT] Algorithm question

[MysticZach via Digitalmars-d]

On Tuesday, 2 May 2017 at 21:00:36 UTC, Timon Gehr wrote:

On 02.05.2017 22:42, MysticZach wrote:

On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:
   for (;;) {
  if (P(a[i]))
 return i;
  ++count;
  if (count == length)
 return -1;
  i += hop;
  if (i < length)
 continue;
  if (i < skipLength)
 i += hop;


(I guess this should be 'while'.)


skipLength is determined modulo hop, thus it can't be more than 
one hop away.



Counterexample: [1,1,1,0,0]

Your algorithm returns 0 with probability 7/20, 1 with 
probability 6/20 and 2 with probability 7/20.


Note that there is a simple reason why your algorithm cannot 
work for this case: it picks one of 20 numbers at random. The 
resulting probability mass cannot be evenly distributed among 
the three elements, because 20 is not divisible by 3.


That's true. Two points, though: If the range of error is within 
1/(n*(n-1)), with array length n, it may be close enough for a 
given real world use case. 2. n is known to be large, which makes 
1/(n*(n-1)) even smaller. You'd probably have to trade accuracy 
for performance. I wonder how much less performant a truly 
accurate algorithm would be. Also, whether there's a way to make 
an algorithm of this style completely accurate.

Re: D and SCons

[H. S. Teoh via Digitalmars-d]

On Wed, May 03, 2017 at 12:05:48AM +0200, Dmitry Olshansky via Digitalmars-d 
wrote:
> On 5/2/17 2:20 PM, Russel Winder via Digitalmars-d wrote:
> > Hi,
> > 
> > Prompted by Bill Deegan (*), I have started a SCons wiki page on D
> > support. Even if you do not actually use SCons for D code, if you
> > are interested in D you are interested in this page as it is another
> > marketing vector for D.
> > 
> 
> I've come to like SCons for my C++ projects. Way more so than say
> CMake.  It would be awesome to have full-fledged support for D there
> esp. in mixed C++ with D setup.
[...]

I've been using SCons for many years now for both C/C++ and D projects,
and have been a happy camper.

However, I have to confess that I found Russel's D tooling (the last
time I tried it anyway, which was a while back) not quite up to what I'd
like it to do. As a result, in my recent projects I've resorted simply
to:

env = Environment(DMD = '/path/to/dmd', DMDFLAGS = [ ... ])
env.Command('myprogram', Split("""
myprogram.d
module1.d
module2.d
"""),
"$DMD $DMDFLAGS -of$TARGET $SOURCES"
)

I realize this hamfisted approach doesn't work well in larger projects
or mixed D/C/C++ projects because it doesn't integrate with SCons'
built-in C/C++ support, but in practice I've found that trying to
integrate D builds with the C/C++ separate compilation model ends up
causing more headaches than necessary, so I just opted for the lazy way
out.


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win 
are idiots.

Re: Porting Java code to D that uses << and >>> operators

[Faux Amis via Digitalmars-d-learn]

On 2017-05-02 18:55, TheGag96 wrote:

On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote:

From that link:

"Note that dmd currently does not comply with left to right evaluation 
of function arguments and AssignExpression".


This is something I've never understood. Why doesn't DMD implement the 
behavior their own language reference specifies? It seems like a very 
nice guarantee to have...


https://github.com/dlang/dmd/pull/4035

Re: CTFE Status 2

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote:

[...]

I intended for the debugging functionality to be exposed via a 
udp socket listening on localhost.
Such that a debug-ui does not have to deal with ipc 
difficulties.


Hm, rationale for UDP over TCP here? I would assume one wouldn't 
want debugging info to be delivered out of order (or not at all); 
I mean, I guess it would be ok for localhost only (though one is 
then depending on implementation specifics vs. protocol 
semantics), but *if* you use sockets, you will eventually get 
people who use that over the network (and then the fun begins). 
Using TCP would just remove any potential future headache from 
the equation.

Re: D and SCons

[Dmitry Olshansky via Digitalmars-d]

On 5/2/17 2:20 PM, Russel Winder via Digitalmars-d wrote:

Hi,

Prompted by Bill Deegan (*), I have started a SCons wiki page on D
support. Even if you do not actually use SCons for D code, if you are
interested in D you are interested in this page as it is another
marketing vector for D.



I've come to like SCons for my C++ projects. Way more so than say CMake.
It would be awesome to have full-fledged support for D there esp. in 
mixed C++ with D setup.



Two things:

1. Can people check what is there, and that it has veracity, or at
least verisimilitude.


Not sure what you mean but did a quick look on the text. The compiler 
section and "Some general thoughts" feels a bit copy-pasty. I would also 
replace "to create the system" with "to create the compiler" or some such.


2. Add new good SCons and D related stuff that puts D (and SCons
obviously) in a good light.

3. Think of how to add some icons and images to the text to make the
page look less a dry academic treatise.


Could use some from:
http://dlang.org/download.html



OK, off-by-one error. No error in the URL though. Please go here:

https://bitbucket.org/scons/scons/wiki/D%20Language%20Support


(*) The de facto leader of the SCons Project just now, and the person
putting in time to make sure all the D-related stuff I am putting into
SCons goes in in good order.



---
Dmitry Olshansky

Re: [OT] Algorithm question

[Timon Gehr via Digitalmars-d]

On 02.05.2017 22:42, MysticZach wrote:

On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:

1. Test a random element in the array. If it satisfies P, return it.
2. Choose a hopper interval, h, that is relatively prime to the number
of elements in the array, n. You could do this by randomly selecting
from a pre-made list of primes of various orders of magnitude larger
than n, with h = the prime % n.
3. Hop along the array, testing each element as you go. Increment a
counter. If you reach the end of the array, cycle back to the
beginning starting with the remainder of h that you didn't use. I
think that h being relatively prime means it will thereby hit every
element in the array.
4. Return the first hit. If the counter reaches n, return failure.


Taking this a step further, it occurred to me that you could use *any*
hopping interval from 1 to array.length, if the length of the array were
prime. So artificially extend the array and just skip a jump when you
land in the extended area. And since you'd skip lots of jumps if the
extension were any bigger that the hopping interval, reduce its length
to modulo the hopping interval.

// returns a random index of array satisfying P(x), -1 if not found
int randomlySatisfy(A[] array) {
   auto length = array.length;
   if (!length)
  return -1;
   auto i = uniform(0, length);
   auto hop = uniform(1, length);

   // greatest prime < 2^^31, for simplicity
   enum prime = 2147483477;
   assert (length <= prime);

   auto skipLength = ((prime - length) % hop) + length;
   auto count = 0;

   for (;;) {
  if (P(a[i]))
 return i;
  ++count;
  if (count == length)
 return -1;
  i += hop;
  if (i < length)
 continue;
  if (i < skipLength)
 i += hop;


(I guess this should be 'while'.)


  i -= skipLength;
   }
   return -1;
}

This solution is stupidly simple and I haven't tested it. But I believe
it's truly random, since the hopping interval is arbitrary. Who knows,
it might work.



Counterexample: [1,1,1,0,0]

Your algorithm returns 0 with probability 7/20, 1 with probability 6/20 
and 2 with probability 7/20.


Note that there is a simple reason why your algorithm cannot work for 
this case: it picks one of 20 numbers at random. The resulting 
probability mass cannot be evenly distributed among the three elements, 
because 20 is not divisible by 3.

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:


I see what you're doing there, but your last point is wishful 
thinking. Dynamically linked binaries can share megabytes of 
code. Even Phobos - although heavily templated - has proven to 
be very amenable to sharing. For example, a "Hello world!" 
program using `writeln()` has these sizes when compiled with 
`dmd -O -release -inline`:


 static Phobos2 : 806968 bytes
dynamic Phobos2 :  18552 bytes

That's about 770 KiB to share or 97.7% of its total size! 
Awesome!


Is all of that active code, or is some of that (statically 
knowable) never getting executed (as in could've been removed at 
compile/link time)?

Re: Porting Java code to D that uses << and >>> operators

[Faux Amis via Digitalmars-d-learn]

On 2017-05-02 09:42, Jacob Carlborg wrote:

On 2017-05-02 01:27, Faux Amis wrote:


To me, this [2] suggests otherwise ;)
Or am I missing something?

[2] https://dlang.org/spec/expression.html#order-of-evaluation


 From that link:

"Note that dmd currently does not comply with left to right evaluation 
of function arguments and AssignExpression".




Yeah, I am blind. Do all the compilers have this problem?

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[David Nadlinger via Digitalmars-d]

On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:

 static Phobos2 : 806968 bytes
dynamic Phobos2 :  18552 bytes

That's about 770 KiB to share or 97.7% of its total size! 
Awesome!


By the way, using LDC: 402736 bytes for the static build (Linux 
x86_64). ;)


 — David

Re: [OT] Algorithm question

[MysticZach via Digitalmars-d]

On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:
1. Test a random element in the array. If it satisfies P, 
return it.
2. Choose a hopper interval, h, that is relatively prime to the 
number of elements in the array, n. You could do this by 
randomly selecting from a pre-made list of primes of various 
orders of magnitude larger than n, with h = the prime % n.
3. Hop along the array, testing each element as you go. 
Increment a counter. If you reach the end of the array, cycle 
back to the beginning starting with the remainder of h that you 
didn't use. I think that h being relatively prime means it will 
thereby hit every element in the array.
4. Return the first hit. If the counter reaches n, return 
failure.


Taking this a step further, it occurred to me that you could use 
*any* hopping interval from 1 to array.length, if the length of 
the array were prime. So artificially extend the array and just 
skip a jump when you land in the extended area. And since you'd 
skip lots of jumps if the extension were any bigger that the 
hopping interval, reduce its length to modulo the hopping 
interval.


// returns a random index of array satisfying P(x), -1 if not 
found

int randomlySatisfy(A[] array) {
   auto length = array.length;
   if (!length)
  return -1;
   auto i = uniform(0, length);
   auto hop = uniform(1, length);

   // greatest prime < 2^^31, for simplicity
   enum prime = 2147483477;
   assert (length <= prime);

   auto skipLength = ((prime - length) % hop) + length;
   auto count = 0;

   for (;;) {
  if (P(a[i]))
 return i;
  ++count;
  if (count == length)
 return -1;
  i += hop;
  if (i < length)
 continue;
  if (i < skipLength)
 i += hop;
  i -= skipLength;
   }
   return -1;
}

This solution is stupidly simple and I haven't tested it. But I 
believe it's truly random, since the hopping interval is 
arbitrary. Who knows, it might work.

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Marco Leise via Digitalmars-d]

Am Tue, 11 Apr 2017 15:03:36 +
schrieb qznc :

> On Tuesday, 11 April 2017 at 12:56:59 UTC, Jonathan M Davis wrote:
> > But if we just use dub - which _is_ the official packaging and 
> > build tool - then we avoid these issues. Ideally, the compiler 
> > and dub would be part of the distro, but libraries don't need 
> > to be. And it sounds like that's basically how the Go and Rust 
> > folks want to function as well. So, it would make sense for 
> > these languages to simply not have their libraries be included 
> > in distros. The build tools are plenty.  
> 
> This is not compatible with Debian. Debian requires to include 
> *everything*. You must be able to build every package without 
> network access only from source packages.
> 
> Essentially, somebody must fix this dub issue: 
> https://github.com/dlang/dub/issues/838

I created a similar issue 3 years ago:
https://github.com/dlang/dub/issues/342

A key point is how environment variables that everyone agreed
upon made "make" a flexible build tool, being able to use a
user specified compiler, installation directory, compiler
flags and more. This flexibility is relied on by Linux
packaging tools to produce binaries for a specific target.

Then there is the problem that at some point you rely on
non-Dlang libraries that only the system package manager can
provide and update. In the past this always ended in the
system package manager winning over the language tool as the
common program to update and clean the system.

Dicebot and bioinfornatics (Fedora) felt that dub was for
developers and wasn't tailored to system administration at
that time. p0nce, s-ludwig and markos (Debian) also gave input
and the net result was:

A Makefile generator for dub shall be written that exposes the
desired environment variables and can be used by existing
Linux package managers.

-- 
Marco

See you soon at dconf

[Stefan Koch via Digitalmars-d]

Hi, I am very happy to see you soon at dconf.

And I apologize in advance for my nearly slideless talk.

Hope this time there is dmd on the machine!

Cheers Stefan

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Marco Leise via Digitalmars-d]

Am Tue, 11 Apr 2017 07:40:12 -0700
schrieb Jonathan M Davis via Digitalmars-d
:

> It could always just be distributed as a static library. There arguably
> isn't much point in distributing it as a shared library anyway -
> particularly when it's not ABI compatible across versions. I actively avoid
> having phobos as a shared library on my systems, because it just causes
> versioning problems when programs are built against it. All of those
> problems go away with a static library. And so much of Phobos is templated
> anyway that there isn't even much to share.
> 
> - Jonathan M Davis

I see what you're doing there, but your last point is wishful
thinking. Dynamically linked binaries can share megabytes of
code. Even Phobos - although heavily templated - has proven to
be very amenable to sharing. For example, a "Hello world!"
program using `writeln()` has these sizes when compiled with
`dmd -O -release -inline`:

 static Phobos2 : 806968 bytes
dynamic Phobos2 :  18552 bytes

That's about 770 KiB to share or 97.7% of its total size!
Awesome!

Another package we have on Gentoo now is the tiling terminal
emulator Tilix, compiled with its default `dmd -O`:

 static Phobos2+GtkD : 14828272 bytes
dynamic Phobos2+GtkD :  6126464 bytes

So here we get ~8.3 megabytes in binary size reduction due to
sharing. (Though 6 MiB for a terminal is still a lot - are
we slim yet? :P )

Some forms of proprietary code and GPL code need clean
shared library interfaces, free from templates and attribute
inference. I mentioned this before: As far as feasible have
full attribute inference for non-exported functions and
reliance on only explicit attributes for exported functions,
so that code changes can't break the public API (due to
mangling changes).

When Dlang's ABI changes, release a major version and make a
public announcement so that everyone can schedule the system
update to a convenient time as is done with GCC C++ ABI
changes.

-- 
Marco

Re: problem with std.variant rounding

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 05/02/2017 04:02 AM, Suliman wrote:


I need co concatenate string with variant type (I am doing SQL query).

What is the best way to put it? It's seems that if I am doing simple
`replace`

string sql = "..."
sql.replace(`37.72308`, to!string(cargpspoint.lon)).replace(`55.47957`,
to!string(cargpspoint.lat))

I am loosing accuracy. Is there any better way?


Building SQL strings manually isn't really good practice these days, for 
both that and other reasons. It's better to use prepared statements, 
which will fix that issue for you and will also ensure your code is not 
susceptible to SQL-injection attacks:



// Raw SQL strings (old, ugly, unsafe way):
auto name = "Fred";
auto num = 1.23;
auto sql = text(
  "INSERT INTO `myTable` (`field1`, `field2`) VALUES ('",
  mysqlEscape(name), "', ", num, ")"
);
exec(conn, sql);


// Prepared statement (good, modern, safe way):
auto name = "Fred";
auto num = 1.23;
Prepared insertSomeFields = prepare(conn,
  "INSERT INTO `myTable` (`field1`, `field2`) VALUES (?, ?)"
);
insertSomeFields.setArgs(name, num);
insertSomeFields.exec();

Re: DIP 1004 Preliminary Review Round 1

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
100% in favor of the constructor behavior change in case no 
constructor is in the derived class.


I agree.

[Issue 17364] Difference between slicing a slice and a reference to a slice

[via Digitalmars-d-bugs]

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

--- Comment #2 from ki...@gmx.net ---
> For example you can't resolve length before loading the array.

Not sure what you mean by 'loading the array'. The base expression evaluates to
a slice, a pointer+length pair, in these 2 cases either to a variable directly
or a reference to it, i.e., in both cases an lvalue representing a slice in
memory. Length/pointer may then be loaded independently from the slice in
memory, but *when* the loads happen is clearly crucial and currently
inconistent.

--

Re: Member delegate/fp to another member in same object?

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

On Tuesday, 2 May 2017 at 17:08:11 UTC, Juanjo Alvarez wrote:

struct S {
  int someState;
  void some_foo() { return this. someState;}

  void delegate() foo;

  void enable() {
foo = _foo;
  }
}


That's actually illegal in D. It will compile, but has undefined 
behavior because the compiler is free to move the struct around 
without giving you a chance to update the delegate. You are 
liable for random crashes doing that.


You'd be better off using a function pointer instead of a 
delegate and making the user pass `this` to it explicitly, or 
making it a class rather than a struct, which the compiler will 
not move. (or a struct only ever used by pointer, a diy class 
basically)

Re: Member delegate/fp to another member in same object?

[Juanjo Alvarez via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 17:08:11 UTC, Juanjo Alvarez wrote:

Example:

struct S {
  int someState;
  void some_foo() { return this. someState;}

  void delegate() foo;

  void enable() {
foo = _foo;
  }
}

unittest {
  S s;
  s.someState = 1;
  enable();
  s.someState = 2;
  assert(foo == 2);
  // fails because the delegate keeps
  // the state of the object at the
  // assignment point
}


Forget it. I just noticed the simplified example that I just 
posted works (once the typo of the return value is corrected) but 
my more complex real code won't, will try to get a simple snippet 
where I can reproduce the problem.

Member delegate/fp to another member in same object?

[Juanjo Alvarez via Digitalmars-d-learn]

Hi!

I would like to have a "proxy" delegate, let's call it "foo" that 
could point to a method or another, let's call them "fast_foo" or 
"slow_foo" on the same object. This way depending on some 
conditions I could switch at runtime from one set of methods to 
others with a "switchFoo(" fast") method while the rest of the 
code inside the object would continue happily calling "foo".


The problem I have is that since the delegate keep the state of 
the object at the moment of the assignment I can't use it for 
this is pretty since the "fast/slow" methods need the value of 
the members of the enclosing object members at the point of 
usage,  I guess that I could pass the "this" pointer in the 
rebinding method but since the targets are also methods of the 
same object I wouldn't be surprised to find that there is an 
obvious/elegant  way to get access to "this" on the 
delegate-pointed method implementing.


Example:

struct S {
  int someState;
  void some_foo() { return this. someState;}

  void delegate() foo;

  void enable() {
foo = _foo;
  }
}

unittest {
  S s;
  s.someState = 1;
  enable();
  s.someState = 2;
  assert(foo == 2);
  // fails because the delegate keeps
  // the state of the object at the
  // assignment point
}

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Marco Leise via Digitalmars-d]

Am Wed, 12 Apr 2017 07:42:42 +
schrieb Martin Nowak :

> Our point releases might also contain small ABI 
> incompatibilities, so they aren't really eligible as patch 
> version.

I've actually been hit by this in one point release on Gentoo,
where I used dynamic linking for Dlang as soon as it was
possible. Programs would suddenly complain about a mismatch
between the size of some compiler generated item after a point
release update of dmd. Just posting this to give the
discussion a bit more substance. :)

-- 
Marco

Re: Porting Java code to D that uses << and >>> operators

[TheGag96 via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote:

From that link:

"Note that dmd currently does not comply with left to right 
evaluation of function arguments and AssignExpression".


This is something I've never understood. Why doesn't DMD 
implement the behavior their own language reference specifies? It 
seems like a very nice guarantee to have...

Re: Top level associative arrays

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

On Tue, May 02, 2017 at 02:37:20PM +, ANtlord via Digitalmars-d-learn wrote:
> On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:
> > 
> > Note that when declared as "enum", all places it's referenced, a new
> > associative array will be allocated.
> 
> If it is allocated at all places I can move initialization to module
> ctor as says evilrat but how can I make an immutable associative
> array?

Just declare it immutable. The module ctor can still initialize it,
because ctors are allowed to initialize immutables:

--
immutable string[string] dict;
static this() {
dict = [
"abc": "def",
"ghi": "lmn"
];
}
void main() {
import std.stdio;
writeln(dict["abc"]);
}
--


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

[Issue 17359] C++ Interfacing: function with 'static' array parameter cannot be linked (x64)

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||C++

--

[Issue 17364] Difference between slicing a slice and a reference to a slice

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||spec

--- Comment #1 from anonymous4  ---
I'd say the array should be loaded before evaluation of slice arguments. For
example you can't resolve length before loading the array. So asserts should be
assert(r1 == [ 1 ]); assert(r2 == [ 1 ]);
How does it work with function pointers?

--

[Issue 17363] @safety hole due to $ caching in slice expressions

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||safe

--

Re: Top level associative arrays

[ANtlord via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 14:37:20 UTC, ANtlord wrote:

On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:


Note that when declared as "enum", all places it's referenced, 
a new associative array will be allocated.


If it is allocated at all places I can move initialization to 
module ctor as says evilrat but how can I make an immutable 
associative array?


I think it will be more suitable to create singleton of structure.

Re: Top level associative arrays

[ANtlord via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:


Note that when declared as "enum", all places it's referenced, 
a new associative array will be allocated.


If it is allocated at all places I can move initialization to 
module ctor as says evilrat but how can I make an immutable 
associative array?

Re: CTFE Status 2

[H. S. Teoh via Digitalmars-d]

On Tue, May 02, 2017 at 09:55:56AM +, Stefan Koch via Digitalmars-d wrote:
[...]
> I intended for the debugging functionality to be exposed via a udp
> socket listening on localhost.
> Such that a debug-ui does not have to deal with ipc difficulties.
> I am strictly against building a debugger into dmd.

Nice, that's a good approach.


T

-- 
Bomb technician: If I'm running, try to keep up.

Re: [OT] Algorithm question

[MysticZach via Digitalmars-d]

On Tuesday, 2 May 2017 at 11:27:17 UTC, Ivan Kazmenko wrote:

On Tuesday, 2 May 2017 at 10:35:46 UTC, Ivan Kazmenko wrote:

I hope some part of the idea is still salvageable.
For example, what if we put the intervals in a queue instead 
of a stack?


I tried to implement a similar approach, but instead of a queue 
or a stack, I used a random-access array of intervals.


Sadly, it is still far from uniform, since it does not take 
interval lengths into account, and I don't see how to do that 
without at least O(log n) time per interval insertion or 
deletion.


Implementation and empiric frequencies for n=5 elements in a 
permutation: http://ideone.com/3zSxLN


Ivan Kazmenko.


Well, I thought of another idea that may not be technically 
random, but which I imagine would get pretty close in real world 
use cases:


1. Test a random element in the array. If it satisfies P, return 
it.
2. Choose a hopper interval, h, that is relatively prime to the 
number of elements in the array, n. You could do this by randomly 
selecting from a pre-made list of primes of various orders of 
magnitude larger than n, with h = the prime % n.
3. Hop along the array, testing each element as you go. Increment 
a counter. If you reach the end of the array, cycle back to the 
beginning starting with the remainder of h that you didn't use. I 
think that h being relatively prime means it will thereby hit 
every element in the array.

4. Return the first hit. If the counter reaches n, return failure.

The way I see it, with a random start position, and a *mostly* 
random interval, the only way to defeat the randomness of the 
result would be if the elements that satisfy P were dispersed 
precisely according to the random interval specified for that 
particular evocation of the function — in which case the first in 
the dispersed set would be chosen more often. This would require 
a rare convergence depending on both n and h, and would not 
repeat from one call to the next.

Re: Definition of D

[Jacob Carlborg via Digitalmars-d]

On 2017-05-02 13:01, Russel Winder via Digitalmars-d wrote:

Is D defined by DMD it's reference implementation, or is there a formal
definition somewhere that is met by the reference implementation?


I would say that it's a mix of "The D programming Language", the 
specification on dlang.org and DMD.


--
/Jacob Carlborg

Re: Top level associative arrays

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-02 09:48, ANtlord wrote:

Hello! Is it possible to define associative array on top level of module?
I try to compile this code and I get message `Error: non-constant
expression ["s":"q", "ss":"qq"]`

import std.stdio;

auto dict = [
 "s": "q",
 "ss": "qq"
];
void main()
{
 writeln(val);
}

I solved it by replacement of word `auto` by `enum`. It is acceptable
for me. But I notice some inconsistency of logic. When I define simple
array I don't get same compile error and it doesn't lead to define this
array using enum. What is key difference between them in this case?

Thanks. Sorry if my English is not clear.


Note that when declared as "enum", all places it's referenced, a new 
associative array will be allocated.


--
/Jacob Carlborg

D and SCons

[Russel Winder via Digitalmars-d]

Hi,

Prompted by Bill Deegan (*), I have started a SCons wiki page on D
support. Even if you do not actually use SCons for D code, if you are
interested in D you are interested in this page as it is another
marketing vector for D.

Two things:

1. Can people check what is there, and that it has veracity, or at
least verisimilitude.

2. Add new good SCons and D related stuff that puts D (and SCons
obviously) in a good light.

3. Think of how to add some icons and images to the text to make the
page look less a dry academic treatise.

OK, off-by-one error. No error in the URL though. Please go here:

https://bitbucket.org/scons/scons/wiki/D%20Language%20Support


(*) The de facto leader of the SCons Project just now, and the person
putting in time to make sure all the D-related stuff I am putting into
SCons goes in in good order. 

-- 
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: I'm looking for job on D

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 2 May 2017 at 11:32:23 UTC, Sergey wrote:

Hi everyone!

Is there work where to use D? (remotely)

Thanks in advance!


https://dlang.org/orgs-using-d.html
https://wiki.dlang.org/Current_D_Use

But you will probably have more luck if you link to a bio and 
repository of your work.  Some people here have found work 
(remote and from an office) via the forums, but I think usually 
that's been people who are actively involved in community.

I'm looking for job on D

[Sergey via Digitalmars-d]

Hi everyone!

Is there work where to use D? (remotely)

Thanks in advance!

Re: Definition of D

[Basile B. via Digitalmars-d]

On Tuesday, 2 May 2017 at 11:01:04 UTC, Russel Winder wrote:

Is D defined by DMD it's reference implementation,


I'd say that this is the case, with

- The D programming Language: 
http://erdani.com/index.php/books/tdpl/


"The D Programming Language, dubbed TDPL by its readers, is the 
ultimate authoritative reference on D".


- The specifications (language reference), so this site. For 
example anyone who wants to write a D compiler should use it for 
the semantic.


But no "ISO D" afaik

Re: [OT] Algorithm question

[Ivan Kazmenko via Digitalmars-d]

On Tuesday, 2 May 2017 at 10:35:46 UTC, Ivan Kazmenko wrote:

I hope some part of the idea is still salvageable.
For example, what if we put the intervals in a queue instead of 
a stack?


I tried to implement a similar approach, but instead of a queue 
or a stack, I used a random-access array of intervals.


Sadly, it is still far from uniform, since it does not take 
interval lengths into account, and I don't see how to do that 
without at least O(log n) time per interval insertion or deletion.


Implementation and empiric frequencies for n=5 elements in a 
permutation: http://ideone.com/3zSxLN


Ivan Kazmenko.

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
100% in favor of the constructor behavior change in case no 
constructor is in the derived class.


I think we could even split this up into two separate proposals, 
because this part of the DIP is fairly non-controversial and 
could be approved much faster (and implementation-wise it should 
be fairly simple to support).

Definition of D

[Russel Winder via Digitalmars-d]

Is D defined by DMD it's reference implementation, or is there a formal
definition somewhere that is met by the reference implementation?

-- 
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: [OT] Algorithm question

[Ivan Kazmenko via Digitalmars-d]

On Monday, 1 May 2017 at 21:54:43 UTC, MysticZach wrote:

On Monday, 1 May 2017 at 16:56:58 UTC, MysticZach wrote:
The goal is to have the first hit be the one you return. The 
method: if a random pick doesn't satisfy, randomly choose the 
partition greater than or less than based on 
uniform(0..array.length-1), and do the same procedure on that 
partition, reusing the random index to avoid having to call 
uniform twice on each recursion (one to choose a partition and 
one to choose an index within that partition). If the 
probability of choosing a partition is precisely proportional 
to the number of elements in that partition, it seems to me 
that the result will be truly random, but I'm not sure.


Now I'm questioning this, because if the positive cases are 
unevenly distributed, i.e., [11000100], the last one has 
about 50% chance to get picked instead of a 1 in 7 chance with 
my method. I guess you'd need to build a whole new array like 
the others are saying.


A pity; it sounded nice!
But yeah, once we pick the right ~half, we have to completely 
traverse it before paying any attention to the left ~half.


I hope some part of the idea is still salvageable.
For example, what if we put the intervals in a queue instead of a 
stack?


Ivan Kazmenko.

Re: DIP 1004 Preliminary Review Round 1

[Basile B. via Digitalmars-d]

On Monday, 1 May 2017 at 16:08:36 UTC, Andrej Mitrovic wrote:

On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors. [...]
All review-related feedback on and discussion of the DIP 
should occur in this thread. [...]

Destroy!


An obvious omission in the syntax variations [1]

- alias this() = super.this();

or

- alias this = super.this;


I thought people would catch on that this is implied. :) The 
old-style or new-style alias syntax should both be allowed, in 
my opinion. The main issue is what to do about the parentheses, 
whether to include them or not.


Then i have nothing to say and you can count me as a supporter of 
this DIP. As a personal matter i don't even care about the 
problem that's to have the ability to select a restricted set 
among the __ctors of the base.


About protection attributes i think that the rules applied to OOP 
should be followed. Private __ctors can only be inherited in 
derived if derived is in the same module, otherwise not. 
Protected and public __ctors can always be inherited. Package 
__ctors can be inherited in the same package.


Note that i always wondered why in the first place constructors 
and destructors were not designed to be virtual functions, like 
in other languages...

Re: DIP 1004 Preliminary Review Round 1

[Dmitry Olshansky via Digitalmars-d]

On 5/2/17 11:03 AM, deadalnix wrote:

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors.

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

All review-related feedback on and discussion of the DIP should occur
in this thread. Due to DConf taking place during the review period,
the period will be extended by a week. The review period will end at
11:59 PM ET on May 22 (3:59 AM GMT May 23), or when I make a post
declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP
will be scheduled for another round. Otherwise, it will be queued for
the formal review and evaluation by the language authors.

Thanks in advance to all who participate.

Destroy!


100% in favor of the constructor behavior change in case no constructor
is in the derived class.

Not convinced by the alias this trick. It doesn't pays for itself, IMO.
It could be provided by a mixin or something and shouldn't be baked into
the language.


+1
Let's keep it simple.

---
Dmitry Olshansky

Re: Top level associative arrays

[evilrat via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 09:50:50 UTC, ANtlord wrote:

On Tuesday, 2 May 2017 at 08:24:09 UTC, evilrat wrote:


Making enum means that value should be available at compile 
time and AA's are fully dynamic. But if my memory serves me 
well, you can declare empty AA and delay initialization. So 
the closest solution is to move initialization of AA to shared 
module ctor(note that there is difference between shared and 
non-shared, refer to documentation) such as in this example:



static shared this() // <-- module ctors run before main()
{
 dict = [
   "s": "q",
   "ss": "qq"
 ];
}

string[string] dict;

void main()
{ ... dict is already initialized ... }


I know about D's enums and I know about module ctors but my 
question is about difference between array and associative 
array in case of definition in top level of module. Why DMD 
allows to define array and doesn't allow to define associative 
array.


Because it is perfectly fine. They are live in the module scope, 
which has its own life time, and from runtime or lifetime 
perspective there is no difference here. And since array can be 
fixed-sized it is valid to use as enum value. But there is one 
catch, in case of enum array it is best to avoid it in favor of 
immutable array* because every time you reference it it will 
allocate. But thats the difference between enum and not enum, not 
the array and map.
This is what I remember from the past, and it is possibly that no 
longer relevant anymore.


* not sure if it prevents allocation though, but in theory it 
should since it *should* go  in to program data section when 
compiling

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Monday, 1 May 2017 at 19:06:24 UTC, H. S. Teoh wrote:
On Mon, May 01, 2017 at 06:23:08PM +, Stefan Koch via 
Digitalmars-d wrote:

[...]


I'm not sure about providing a debugger UI inside the compiler 
itself... it's certainly possible, and could lead to 
interesting new ways of using a compiler, but I was thinking 
more along the lines of providing the necessary hooks so that 
you could attach an external debugger to the CTFE engine.


But if the debugger UI is simple enough, perhaps having it 
built into the compiler may not be a bad thing. It would also 
avoid potential trouble caused by some platforms not having 
debuggers capable of plugging into the compiler in that way.  
But still, I can see people demanding IDE integration for this 
eventually... :-O



T


I intended for the debugging functionality to be exposed via a 
udp socket listening on localhost.

Such that a debug-ui does not have to deal with ipc difficulties.
I am strictly against building a debugger into dmd.

Re: Top level associative arrays

[ANtlord via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 08:24:09 UTC, evilrat wrote:


Making enum means that value should be available at compile 
time and AA's are fully dynamic. But if my memory serves me 
well, you can declare empty AA and delay initialization. So the 
closest solution is to move initialization of AA to shared 
module ctor(note that there is difference between shared and 
non-shared, refer to documentation) such as in this example:



static shared this() // <-- module ctors run before main()
{
 dict = [
   "s": "q",
   "ss": "qq"
 ];
}

string[string] dict;

void main()
{ ... dict is already initialized ... }


I know about D's enums and I know about module ctors but my 
question is about difference between array and associative array 
in case of definition in top level of module. Why DMD allows to 
define array and doesn't allow to define associative array.

Re: DIP 1004 Preliminary Review Round 1

[deadalnix via Digitalmars-d]

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors.

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

All review-related feedback on and discussion of the DIP should 
occur in this thread. Due to DConf taking place during the 
review period, the period will be extended by a week. The 
review period will end at 11:59 PM ET on May 22 (3:59 AM GMT 
May 23), or when I make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it will 
be queued for the formal review and evaluation by the language 
authors.


Thanks in advance to all who participate.

Destroy!


100% in favor of the constructor behavior change in case no 
constructor is in the derived class.


Not convinced by the alias this trick. It doesn't pays for 
itself, IMO. It could be provided by a mixin or something and 
shouldn't be baked into the language.

Re: problem with std.variant rounding

[Suliman via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 08:02:23 UTC, Suliman wrote:
On Saturday, 29 April 2017 at 08:57:09 UTC, Petar Kirov 
[ZombineDev] wrote:

On Friday, 28 April 2017 at 18:08:38 UTC, H. S. Teoh wrote:
On Fri, Apr 28, 2017 at 04:42:28PM +, via 
Digitalmars-d-learn wrote: [...]

writefln(text("%.", i, "f"), x);

[...]

There's no need to use text() here:

writefln("%.*f", i, x);

does what you want.


T


Thanks, I missed the fact that * could be used for specifying 
the precision, in addition to the width.


I need co concatenate string with variant type (I am doing SQL 
query).


What is the best way to put it? It's seems that if I am doing 
simple `replace`


string sql = "..."
sql.replace(`37.72308`, 
to!string(cargpspoint.lon)).replace(`55.47957`, 
to!string(cargpspoint.lat))


I am loosing accuracy. Is there any better way?


I did:
sql_distance.replace(`37.72308`, format("%f",cargpspoint.lon))

It's seems that it's work ok. But is there any better way, or 
it's ok?

Re: Top level associative arrays

[evilrat via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote:
Hello! Is it possible to define associative array on top level 
of module?
I try to compile this code and I get message `Error: 
non-constant expression ["s":"q", "ss":"qq"]`


import std.stdio;

auto dict = [
"s": "q",
"ss": "qq"
];
void main()
{
writeln(val);
}

I solved it by replacement of word `auto` by `enum`. It is 
acceptable for me. But I notice some inconsistency of logic. 
When I define simple array I don't get same compile error and 
it doesn't lead to define this array using enum. What is key 
difference between them in this case?


Thanks. Sorry if my English is not clear.


Making enum means that value should be available at compile time 
and AA's are fully dynamic. But if my memory serves me well, you 
can declare empty AA and delay initialization. So the closest 
solution is to move initialization of AA to shared module 
ctor(note that there is difference between shared and non-shared, 
refer to documentation) such as in this example:



static shared this() // <-- module ctors run before main()
{
 dict = [
   "s": "q",
   "ss": "qq"
 ];
}

string[string] dict;

void main()
{ ... dict is already initialized ... }

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Atila Neves via Digitalmars-d]

On Monday, 1 May 2017 at 07:42:19 UTC, Sebastiaan Koppe wrote:

On Friday, 28 April 2017 at 22:18:54 UTC, Atila Neves wrote:
Done. I also added to the README that it has its own versions 
of the range constraints from Phobos that can be used with 
`@models`.


Atila


Example of an error message in the README would be great too.


Good point, done.

Atila

Re: problem with std.variant rounding

[Suliman via Digitalmars-d-learn]

On Saturday, 29 April 2017 at 08:57:09 UTC, Petar Kirov 
[ZombineDev] wrote:

On Friday, 28 April 2017 at 18:08:38 UTC, H. S. Teoh wrote:
On Fri, Apr 28, 2017 at 04:42:28PM +, via 
Digitalmars-d-learn wrote: [...]

writefln(text("%.", i, "f"), x);

[...]

There's no need to use text() here:

writefln("%.*f", i, x);

does what you want.


T


Thanks, I missed the fact that * could be used for specifying 
the precision, in addition to the width.


I need co concatenate string with variant type (I am doing SQL 
query).


What is the best way to put it? It's seems that if I am doing 
simple `replace`


string sql = "..."
sql.replace(`37.72308`, 
to!string(cargpspoint.lon)).replace(`55.47957`, 
to!string(cargpspoint.lat))


I am loosing accuracy. Is there any better way?

Re: Top level associative arrays

[ANtlord via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote:
Hello! Is it possible to define associative array on top level 
of module?
I try to compile this code and I get message `Error: 
non-constant expression ["s":"q", "ss":"qq"]`


import std.stdio;

auto dict = [
"s": "q",
"ss": "qq"
];
void main()
{
writeln(val);
}

I solved it by replacement of word `auto` by `enum`. It is 
acceptable for me. But I notice some inconsistency of logic. 
When I define simple array I don't get same compile error and 
it doesn't lead to define this array using enum. What is key 
difference between them in this case?


Thanks. Sorry if my English is not clear.


By the way I notice some strange compile error when I try to 
change associatove array defined using enum.


import std.stdio;

enum dict = [
"s": "q",
"ss": "qq"
];

void main()
{
dict["sss"] = "qqq";
}

Compilation of this code returns the error

& el:0x3237ab4 cnt=0 cs=0 &  TY* 0x3235794
 el:0x3235794 cnt=0 cs=0 call  TY* 0x3235744 0x32356f4
  el:0x3235744 cnt=0 cs=0 var  TYC func  _d_assocarrayliteralTX
  el:0x32356f4 cnt=0 cs=0 param  TYvoid 0x32356a4 0x3235654
   el:0x32356a4 cnt=0 cs=0 param  TYvoid 0x3234c44 0x3234d34
el:0x3234c44 cnt=0 cs=0 rpair  TYucent 0x3234ba4 0x3234bf4
 el:0x3234ba4 cnt=0 cs=0 relconst  TY*  0+& _TMP8
 el:0x3234bf4 cnt=0 cs=0 const  TYuns long long 2LL
el:0x3234d34 cnt=0 cs=0 rpair  TYucent 0x3234c94 0x3234ce4
 el:0x3234c94 cnt=0 cs=0 relconst  TY*  0+& _TMP5
 el:0x3234ce4 cnt=0 cs=0 const  TYuns long long 2LL
   el:0x3235654 cnt=0 cs=0 var  TY*  _D16TypeInfo_HAyaAya6__initZ
Internal error: backend/cgcs.c 352

But when I try to change simple array defined using enum

import std.stdio;

enum arr = [1, 2, 3];

void main()
{
arr ~= 4;
}

I get the clear error `Error: [1, 2, 3] is not an lvalue`

Re: Top level associative arrays

[ANtlord via Digitalmars-d-learn]

On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote:
Hello! Is it possible to define associative array on top level 
of module?
I try to compile this code and I get message `Error: 
non-constant expression ["s":"q", "ss":"qq"]`


import std.stdio;

auto dict = [
"s": "q",
"ss": "qq"
];
void main()
{
writeln(val);
}

I solved it by replacement of word `auto` by `enum`. It is 
acceptable for me. But I notice some inconsistency of logic. 
When I define simple array I don't get same compile error and 
it doesn't lead to define this array using enum. What is key 
difference between them in this case?


Thanks. Sorry if my English is not clear.


Sorry. There is should be `writeln(dict["s"]);` instead 
`writeln(val);`

Top level associative arrays

[ANtlord via Digitalmars-d-learn]

Hello! Is it possible to define associative array on top level of 
module?
I try to compile this code and I get message `Error: non-constant 
expression ["s":"q", "ss":"qq"]`


import std.stdio;

auto dict = [
"s": "q",
"ss": "qq"
];
void main()
{
writeln(val);
}

I solved it by replacement of word `auto` by `enum`. It is 
acceptable for me. But I notice some inconsistency of logic. When 
I define simple array I don't get same compile error and it 
doesn't lead to define this array using enum. What is key 
difference between them in this case?


Thanks. Sorry if my English is not clear.

Re: Porting Java code to D that uses << and >>> operators

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-02 01:27, Faux Amis wrote:


To me, this [2] suggests otherwise ;)
Or am I missing something?

[2] https://dlang.org/spec/expression.html#order-of-evaluation


From that link:

"Note that dmd currently does not comply with left to right evaluation 
of function arguments and AssignExpression".


--
/Jacob Carlborg

[Issue 13017] opEquals for null std.typecons.Nullable

[via Digitalmars-d-bugs]

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

Mario Kroeplin  changed:

   What|Removed |Added

 CC||qas...@gmail.com

--- Comment #9 from Mario Kroeplin  ---
*** Issue 10771 has been marked as a duplicate of this issue. ***

--

[Issue 10771] std.typecons.Nullable throws an exception on comparision of null values

[via Digitalmars-d-bugs]

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

Mario Kroeplin  changed:

   What|Removed |Added

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

--- Comment #6 from Mario Kroeplin  ---


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

--

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/01/2017 10:51 PM, Stanislav Blinov wrote:

On Monday, 1 May 2017 at 16:31:10 UTC, Nick Sabalausky (Abscissa) wrote:


If we had a type similar to TaggedAlgebraic...

Destroy?


It's too strict: you have to specify concrete types beforehand.


No, that's why my suggestion was:

"If we had a type similar to TaggedAlgebraic, but was an open variant 
rather than a closed algebraic (Ie, a type like Phobos's Variant, but 
forwarded member access without first requiring explicit conversion to 
the exact underlying type),"