Re: DMD producing huge binaries

[default0 via Digitalmars-d]

On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:

On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all 
Voldermort returns
and calling it a day. I bet Liran's code will get a lot 
quicker to build and

smaller to boot.


Let's see how far we get with compression first.

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

Using 64 character random strings will make symbolic debugging 
unpleasant.


You could simply add a "trivial" version of the struct + 
enclosing function name (ie once, without repetitions) before or 
after the random character string. This way you would know which 
struct its referring to, its unique, and you still avoid 
generating a 5 Exabyte large symbol name just to 
compress/hash/whatever it.

[Issue 16049] New: core.sys.windows structs have wrong sizes and aligns

[via Digitalmars-d-bugs]

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

  Issue ID: 16049
   Summary: core.sys.windows structs have wrong sizes and aligns
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

core.sys.windows.* modules came with 2.070.
I'm verifying sizes of the structs by comparing with ones in Windows SDK
headers.

So, I found that many have wrong sizes and/or field alignments.
These problems would make runtime error.
Most of them are in Win64 environment.

I'll send a PR later.

--

Re: DMD producing huge binaries

[Patrick Schluter via Digitalmars-d]

On Thursday, 19 May 2016 at 22:46:02 UTC, Adam D. Ruppe wrote:

On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
Using 64 character random strings will make symbolic debugging 
unpleasant.


Using 6.4 megabyte strings already makes symbolic debugging 
unpleasant.


The one thing that worries me about random strings is that it 
needs to be the same across all builds, or you'll get random 
linking errors when doing package-at-a-time or whatever (dmd 
already has some problems like this!). But building a gigantic 
string then compressing or hashing it still sucks... what we 
need is a O(1) solution that is still unique and repeatable.


Good point. Using a SHA1 derived from the string instead of a 
GUID is imho better. It has the advantage of repeatability, is 
even shorter and not very expensive to generate.

[Issue 15959] core.sys.windows modules should be modified for x64

[via Digitalmars-d-bugs]

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

--- Comment #8 from j...@red.email.ne.jp ---
#1552 #1575 was merged, thanks.

But #1574 remains. ( which has the most fixes )

--

[Issue 15607] [ICE] CTFE internal error: bad compare on accessing default-initialized static immutable array of array

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #7 from Walter Bright  ---
(In reply to Mathias Lang from comment #5)
> This segv all the same:
> 
> ```
> private static immutable char[2][ubyte.max + 1] code_base = [ "??" ];
> ```
> 
> and so does:
> 
> ```
> private static immutable char[2][ubyte.max + 1] code_base = [ [ '?', '?' ] ];
> ``

Neither of these seg fault when I put them in a file and compile them.

--

Re: How to share an appender!string?

[Era Scarecrow via Digitalmars-d-learn]

On Friday, 20 May 2016 at 02:04:56 UTC, captaindet wrote:

i am most curious about your solution.

why does printAll() has a synchronized block? in case you would 
call it before thread_joinAll() i.e. before all threads are 
terminated?


then again, why is there a synchronized block necessary in 
printAll() at all? it is only reading out data, not writing.


 If a local copy/slice/range is made for foreach (which I think 
it is) then synchronized isn't needed. If reallocation worked 
differently then it could be quite annoying when the memory is 
reallocated and you were using it; But since it isn't, I just 
threw it in for completion sake.



(i am still learning the subtleties of multithreading.)


 I tried to learn using C/C++ mutexes and semaphores and got 
hopelessly lost; Never tried to really get into it. Found a whole 
new meaning to the process while just recently re-reading the D2 
book.


 Regardless, let's learn this stuff together :)

 Still if you have any more complex commands then what you're 
doing here, you might wrap it into a class; It appears 
synchronized can work on classes (even Object) and not require a 
separate mutex for it to compile, so... I'm not sure what that 
means, or if it's even safe.

Re: mago-mi: GDB/MI compatible frontend for Mago debugger

[Vadim Lopatin via Digitalmars-d-announce]

On Friday, 20 May 2016 at 03:15:46 UTC, E.S. Quinn wrote:
Unfortunately in this particular case, CDT's debugging is 
pretty fancy and is going to need most if not all of the MI.


I also don't know which MI commands need to be supported to 
have it work with DDT. The thing is I didn't write the GDB 
debugger integration for DDT, I just reused the one from CDT. 
So I'm not that familiar with those internals.


BTW, the MI integration is fairly language agnostic, so in 
theory your debugger could be used by CDT to debug C/C++ 
programs too, no? At least those generated by DMC. Maybe 
Visual Studio ones too?


I'm experimenting with the build of mago-mi that comes with the 
current ~master for dlangide, and it seems to throw an 
unrecognized parameter error when on the --log-level=TRACE 
parameter.


And it seems that the version string it returns upsets eclipse, 
as it throws the following error:


 Could not determine GDB version using command: 
D:\WinHome\\AppData\Roaming\dub\packages\dlangide-master\bin\mago-mi.exe --version

 Unexpected output format:

 mago-mi debugger v0.1


Though, from my experience using it in Linux, eclipse-CDT's 
debugger seems pretty full-featured; it will likely require 
large swaths of mi functionality to be fully useful.


Need to show version like lldb-mi does - writes gnu gdb version, 
then says that really it's not a GDB


Let me check problem with --log-level

Re: Possible bug in std.path?

[Walter Bright via Digitalmars-d]

On 5/19/2016 6:35 PM, Hugo wrote:

I assumed the
function would deal with the trailing backslash.


And it can. It just never received a trailing backslash because that was removed 
by the Windows argument processing.

Re: mago-mi: GDB/MI compatible frontend for Mago debugger

[E.S. Quinn via Digitalmars-d-announce]

Unfortunately in this particular case, CDT's debugging is pretty 
fancy and is going to need most if not all of the MI.


On Thursday, 19 May 2016 at 13:29:14 UTC, Bruno Medeiros wrote:

On 19/05/2016 08:41, Vadim Lopatin wrote:
On Wednesday, 18 May 2016 at 18:02:12 UTC, Bruno Medeiros 
wrote:
While DDT technically work oks with GDB (the GDB from 
mingw-w64 that
is), you are right, there isn't a compiler on Windows that 
supplies

debug info in the way GDB understands. See
https://wiki.dlang.org/Debuggers.

DMD produces debug info COFF or OMF format, which GDB doesn't 
know
anything about (nor ever will). LDC should in theory work 
with DWARF
info, but this is broken somehow. Not because of LLVM though, 
since
for example Rust on Windows works. As for GDC, it doesn't 
even supply
binaries for Windows (that target Windows) -  it is not a 
supported

platform.

BTW, Eclipse/DDT should in theory work with mago-mi as well, 
at least
if the protocol is implemented correctly. Have you tried it? 
I dunno

how complete your MI implementation is.


So it looks like mago-mi might be helpful for DDT on Windows.
mago-mi supports subset of GDB/MI commands enough for 
DlangIDE, but it

can be easy extended.

Currenlty supported commands can be shown using help command 
(use
--interpreter=mi2 when running mago-mi, otherwise it will 
print non-MI

commands). Also commands are listed in readme file
https://github.com/buggins/mago/blob/master/MagoMI/mago-mi/README.md

I didn't try DDT with mago-mi, and so I'm not sure which 
commands must

be supported by debugger to get it working with DDT.

To get list of commands DDT tries to use you can either add
--log-file=magomi.log --log-level=TRACE to mago-mi command 
line or use

debug build of mago-mi.
It will all STDIN data to log file, and report errors for 
unsupported

commands.



I also don't know which MI commands need to be supported to 
have it work with DDT. The thing is I didn't write the GDB 
debugger integration for DDT, I just reused the one from CDT. 
So I'm not that familiar with those internals.


BTW, the MI integration is fairly language agnostic, so in 
theory your debugger could be used by CDT to debug C/C++ 
programs too, no? At least those generated by DMC. Maybe Visual 
Studio ones too?


I'm experimenting with the build of mago-mi that comes with the 
current ~master for dlangide, and it seems to throw an 
unrecognized parameter error when on the --log-level=TRACE 
parameter.


And it seems that the version string it returns upsets eclipse, 
as it throws the following error:


 Could not determine GDB version using command: 
D:\WinHome\\AppData\Roaming\dub\packages\dlangide-master\bin\mago-mi.exe --version

 Unexpected output format:

 mago-mi debugger v0.1


Though, from my experience using it in Linux, eclipse-CDT's 
debugger seems pretty full-featured; it will likely require large 
swaths of mi functionality to be fully useful.

Re: Implement async/await using Fiber

[Yuxuan Shui via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 23:42:03 UTC, Ali Çehreli wrote:

On 05/19/2016 12:57 PM, Yuxuan Shui wrote:

[...]


You can use a delegate that takes a ref parameter:

import std.stdio;
import core.thread;

void fiberFunc(ref string y) {
y = "produced_by_fiberFunc";
Fiber.yield();
}

void main() {
string data;
auto f = new Fiber(() => fiberFunc(data));
f.call();
writefln("Writing in main: %s", data);
}

Prints:

Writing in main: produced_by_fiberFunc

Also see std.concurrency.Generator. Both methods appear here:

  http://ddili.org/ders/d.en/fibers.html

Ali


Hmm... This could work. But I'm not satisfied with this solution. 
What if I have multiple yield sites in the fiber, and each have 
different return types?


Maybe I should use a Variant?

Re: How to share an appender!string?

[captaindet via Digitalmars-d-learn]

On 2016-05-20 07:49, Era Scarecrow wrote:

  Experimented and quickly got what looks like good clean results. Took
your code, ripped out what I didn't want and added in what I did. Simple!

  https://dpaste.dzfl.pl/6952fdf463b66


i am most curious about your solution.

why does printAll() has a synchronized block? in case you would call it 
before thread_joinAll() i.e. before all threads are terminated?


then again, why is there a synchronized block necessary in printAll() at 
all? it is only reading out data, not writing.


(i am still learning the subtleties of multithreading.)

/det

Re: Possible bug in std.path?

[Hugo via Digitalmars-d]

On Thursday, 19 May 2016 at 22:44:06 UTC, Walter Bright wrote:

On 5/19/2016 3:41 PM, Adam D. Ruppe wrote:
So indeed, the OP stumbled upon a weird case of Windows 
command line, but it is

really just this one weird case.


It's not at all weird. It's just garden variety double quoted 
string behavior. Linux has its own quoting scheme on the 
command line, too.


I must confess I was a bit misled then by this portion of the 
unittest:


assert (buildNormalizedPath(`c:\foo\.\bar/..\\baz\`) == 
`c:\foo\baz`);


Since I saw somewhere D could use different quoting styles, I 
assumed the function would deal with the trailing backslash.

Re: Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/18/2016 4:30 AM, Ethan Watson wrote:

I appreciate that it sounds like I'm starting to stretch to hold to my point,
but I imagine we'd also be able to control such things with the compiler - or at
least know what flags it uses so that we can ensure consistent behaviour between
compilation and runtime.


All compilers I know of use "round to nearest" for constant folding, and that is 
not adjustable.

Re: Use Requests to send data to webpage - how?

[Seb via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 19:28:46 UTC, TheDGuy wrote:

Hi,
i was sucessfull in installing requests and getting data from a 
webpage like this:


Request rq = Request();
Response rs = rq.exec!"GET"("http://somewebpage.org/SQL.php;, 
["action":"getTemp"]);


But i am not able to send data to the webpage like this:

Request rq = Request();
Response rs = rq.exec!"GET"("http://somewebpage.org;, 
[parameter:data]);


If i just type this:

http://somewebpage.org/?parameter=data

in my browser the webpage reacts as intended but with the 
Requests "GET" nothing happens. Do you know what i do wrong?


Open an issue at the repo of the package you installed. Looks 
like it's an error.

Re: DMD producing huge binaries

[poliklosio via Digitalmars-d]

On Thursday, 19 May 2016 at 23:56:46 UTC, poliklosio wrote:

(...)
Clearly the reason for building such a gigantic string was some 
sort of repetition. Detect the repetition on-the-fly to avoid 
processing all of it. This way the generated name is already 
compressed.


It seems like dynamic programming can be useful.

Re: DMD producing huge binaries

[poliklosio via Digitalmars-d]

On Thursday, 19 May 2016 at 22:46:02 UTC, Adam D. Ruppe wrote:

On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
Using 64 character random strings will make symbolic debugging 
unpleasant.


Using 6.4 megabyte strings already makes symbolic debugging 
unpleasant.


The one thing that worries me about random strings is that it 
needs to be the same across all builds, or you'll get random 
linking errors when doing package-at-a-time or whatever (dmd 
already has some problems like this!). But building a gigantic 
string then compressing or hashing it still sucks... what we 
need is a O(1) solution that is still unique and repeatable.


Clearly the reason for building such a gigantic string was some 
sort of repetition. Detect the repetition on-the-fly to avoid 
processing all of it. This way the generated name is already 
compressed.

Re: Implement async/await using Fiber

[Ali Çehreli via Digitalmars-d-learn]

On 05/19/2016 04:42 PM, Ali Çehreli wrote:

> You can use a delegate that takes a ref parameter:

Correction: You can use a delegate that calls a function that takes a 
ref parameter.


Ali

Re: DMD producing huge binaries

[Walter Bright via Digitalmars-d]

On 5/19/2016 4:36 PM, jmh530 wrote:

Queue me going to the language reference to look up static structs and reading

"A struct can be prevented from being nested by using the static attribute, but
then of course it will not be able to access variables from its enclosing 
scope."

Not a fan of that description...


You can always submit a PR for a better one.

Re: Implement async/await using Fiber

[Ali Çehreli via Digitalmars-d-learn]

On 05/19/2016 12:57 PM, Yuxuan Shui wrote:

I find this difficult because I can't passing data via
Fiber.yield/Fiber.call pair. e.g. I want something like:

void fiberFunc() {
//Add some file descriptor to main loop
string y = Fiber.yield();
writeln(y);
}

auto f = new Fiber();
f.call();
mainloop {
if (fd_readable)
   f.call(fd.rawRead());
}

I can probably using a derived fiber class and pass the result via class
members, but that seems clumsy and not very general. Any ideas?



You can use a delegate that takes a ref parameter:

import std.stdio;
import core.thread;

void fiberFunc(ref string y) {
y = "produced_by_fiberFunc";
Fiber.yield();
}

void main() {
string data;
auto f = new Fiber(() => fiberFunc(data));
f.call();
writefln("Writing in main: %s", data);
}

Prints:

Writing in main: produced_by_fiberFunc

Also see std.concurrency.Generator. Both methods appear here:

  http://ddili.org/ders/d.en/fibers.html

Ali

Re: DMD producing huge binaries

[jmh530 via Digitalmars-d]

On Thursday, 19 May 2016 at 22:17:37 UTC, Walter Bright wrote:


Consider using a 'static struct'. A non-static struct will 
include a hidden member that points to the stack frame of 
foo(), i.e. "produces smaller code".


Queue me going to the language reference to look up static 
structs and reading


"A struct can be prevented from being nested by using the static 
attribute, but then of course it will not be able to access 
variables from its enclosing scope."


Not a fan of that description...

Re: mutable keyword

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, May 19, 2016 20:44:54 ciechowoj via Digitalmars-d-learn wrote:
> Is there D equivalent of C++'s mutable keyword? Like the one that
> allows to modify a field of struct from constant method. Or some
> alternative solution?

No. D's const and immutable provide no backdoors. Rather, they provide
strong guarantees. So, if a variable is const, then it cannot be mutated
(even internally) except via a mutable reference to the same data. This has
the upside that you can rely on a const object not mutating on you unless
you're also messing around with mutable referencs to the same data, but it
has the downside that you can't do things like caching or lazy
initialization, and you can't have portions of a const object be treated as
mutable. You can cast away const, but it's undefined behavior if you mutate
afterwards (and could result in subtle bugs depending on what optimizations
the compiler does). So, it's not going to provide a backdoor around const's
strong guarantees about mutation.

The result is that if you need something like C++'s mutable, you can't use
D's const. You're stuck using mutable values and are forced to avoid const.

Now, if your functions aren't pure, you can put state outside of the object
itself and have a const member function access and mutate that external
state, but that's not exactly great for encapsulation, and then you can't
use that function in pure code. But it's the closest thing to a backdoor
from const that exists in D, because const is set up so that it's actually
const and not just const until the implementation decides to mutate it
anyway. Whether that's better or worse than C++'s const depends on what
you're trying to do, but the reality of the matter is that D's const is
ultimately very different from C++'s const because of how restrictive it is.
You get better guarantees but can't use it anywhere near as much precisely
because of the restrictions that are required to provide those guarantees.

- Jonathan M Davis

Re: mutable keyword

[Era Scarecrow via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 20:44:54 UTC, ciechowoj wrote:
Is there D equivalent of C++'s mutable keyword? Like the one 
that allows to modify a field of struct from constant method. 
Or some alternative solution?


 A little personal experience. I wrote a tool that had certain 
flags that did things turned on by default, and turning them off 
using other flags. This seemed the best choice at the time, but 
upon later reflection it's hard to remember details you'd not 
think about unless you wanted them active. Think about a simple 
action like 'get home', which you also have to 'turn sink off, 
don't change bedding, don't shave, don't walk dog' because 
otherwise you have to do all those when all you planned when 
getting home was taking a shower and going to bed. Remembering to 
add all the flags/changes/options for the utility quickly was 
becoming a pain, to which I reverted my options to only be on 
when called/intended them rather than thinking them on by default 
was the best option.


 As for mutable. It's mutable unless you specify otherwise, and 
the whole object as a whole can be immutable/const; Don't 
complicate the rules so "it's const (except when it's not)" 
logic, either make it intentionally const/immutable or don't.

Re: My ACCU 2016 keynote video available online

[Jens Müller via Digitalmars-d-announce]

On Thursday, 19 May 2016 at 22:04:56 UTC, Andrei Alexandrescu 
wrote:

On 05/19/2016 05:36 PM, Jens Müller wrote:
I removed the code to optimize for large gaps. Because it is 
only
confusing. I may generate some benchmark data with larger gaps 
later to

see whether it is worthwhile for such data.


For skipping large gaps quickly, check galloping search (google 
for it, we also have it in phobos). -- Andrei


Sure. I've already seen this. It's nice. But you have to include 
it in the sparse dot product (or list intersection) algorithm 
somehow. Then you require random access and galloping is only 
beneficial if the gaps are large. As a library writer this is a 
difficult position because this turns easily into over 
engineering. Optimally one just exposes the primitives and the 
user plugs them together. Ideally without having to many knobs 
per algorithm.


Jens

Re: My ACCU 2016 keynote video available online

[Jens Müller via Digitalmars-d-announce]

On Thursday, 19 May 2016 at 22:02:53 UTC, Andrei Alexandrescu 
wrote:

On 05/19/2016 05:36 PM, Jens Müller wrote:

I'm not seeing it. Let me explain.
Consider the input a = [1] and b = [2, 3] (I only write the 
indices).
The smallest back index is 1, i.e., a.back is the chosen 
sentinel.


Nonono, you stamp the largest index over the smaller index. So 
you overwrite a = [3] and you leave b = [2, 3] as it is.


Now you know that you're multiplying two correct sparse vectors 
in which _definitely_ the last elements have equal indexes. So 
the inner loop is:


if (a[i].idx < b[j].idx) {
  i++; // no check needed
} else if (a[i].idx > b[j].idx) {
  j++; // no check needed
} else {
  // check needed
  r += a[i].val * b[j].val;
  if (i == imax || j == jmax) break;
  ++i;
  ++j;
}

At the end you need a fixup to make sure you account for the 
last index that you overwrote (which of course you need to save 
first).


Makes sense?


What if you stomped over an index in a that has as an equal index 
in b (it could be anywhere in b). After the loop finishes you 
restore the index in a. But how do you address the values for the 
stomped over index if needed?

For instance test it on
a = [2]
b = [2,3]
Note the 2 in b could be anywhere.

I think you can check for
if (a[i].idx == sentinelIdx) break;
instead of
if (i == imax || j == jmax) break;

Jens

Re: DMD producing huge binaries

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
Using 64 character random strings will make symbolic debugging 
unpleasant.


Using 6.4 megabyte strings already makes symbolic debugging 
unpleasant.


The one thing that worries me about random strings is that it 
needs to be the same across all builds, or you'll get random 
linking errors when doing package-at-a-time or whatever (dmd 
already has some problems like this!). But building a gigantic 
string then compressing or hashing it still sucks... what we need 
is a O(1) solution that is still unique and repeatable.

Re: Possible bug in std.path?

[Walter Bright via Digitalmars-d]

On 5/19/2016 3:41 PM, Adam D. Ruppe wrote:

So indeed, the OP stumbled upon a weird case of Windows command line, but it is
really just this one weird case.


It's not at all weird. It's just garden variety double quoted string behavior. 
Linux has its own quoting scheme on the command line, too.

Re: Possible bug in std.path?

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 19 May 2016 at 22:13:36 UTC, Walter Bright wrote:

Windows command line processing has special handling for " and 
\. The \ is used to escape the next character, which here is a 
". You can see the resulting argument is [my test"]. Note the 
quote.


Not exactly... it treats \" as a special case, not \ in general.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx

Quote:

CommandLineToArgvW has a special interpretation of backslash 
characters when they are followed by a quotation mark character 
("), as follows:


2n backslashes followed by a quotation mark produce n 
backslashes followed by a quotation mark.
(2n) + 1 backslashes followed by a quotation mark again 
produce n backslashes followed by a quotation mark.
n backslashes not followed by a quotation mark simply produce 
n backslashes.




So indeed, the OP stumbled upon a weird case of Windows command 
line, but it is really just this one weird case.

Re: DMD producing huge binaries

[Walter Bright via Digitalmars-d]

On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:

I very much advocate slapping a 64-long random string for all Voldermort returns
and calling it a day. I bet Liran's code will get a lot quicker to build and
smaller to boot.


Let's see how far we get with compression first.

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

Using 64 character random strings will make symbolic debugging unpleasant.

Re: DMD producing huge binaries

[Walter Bright via Digitalmars-d]

On 5/19/2016 8:39 AM, Steven Schveighoffer wrote:

template(T) foo if (someConstraints)
{
struct Result
{
   T t;
}

auto foo(T t)
{
   return Result(t);
}
}


This solution works awesomely, actually. It even produces smaller code than
moving the struct completely outside.

I'm going to use this mechanism in iopipe to get my voldemorts back :)



Consider using a 'static struct'. A non-static struct will include a hidden 
member that points to the stack frame of foo(), i.e. "produces smaller code".

Re: D's Auto Decoding and You

[John Carter via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote:

http://jackstouffer.com/blog/d_auto_decoding_and_you.html


There are lots of places where invalid Unicode is either 
commonplace or legal, e.g. Linux file names, and therefore 
auto decoding cannot be used. It turns out in the wild that 
pure Unicode is not universal - there's lots of dirty Unicode 
that should remain unmolested because it's user data, and auto 
decoding does not play well with that mentality.


As a slightly tangential aside.

https://lwn.net/Articles/686392/

There exists a proposal for a linux kernel module to render the 
creation of such names impossible.


I for one will install it on all my systems as soon as I can.

However, until then, my day job requires me to find, scan and 
analyze and work with whatever crud, the herd of cats I work 
with, throws into the repo.


And no, sadly I can't just rewrite everything because they (or 
some tool they use) doesn't understand UTF8.

Re: Possible bug in std.path?

[Walter Bright via Digitalmars-d]

On 5/18/2016 8:49 PM, Hugo wrote:

mytest "my dir\"

I should get "OK", but instead I get:
Error: 'my test"' is not a valid directory path.


Windows command line processing has special handling for " and \. The \ is used 
to escape the next character, which here is a ". You can see the resulting 
argument is [my test"]. Note the quote.




If the trailing backslash is removed it works as intended, but IMHO
buildNormalizedPath should have worked.


buildNormalizedPath is passed [my test"]. It cannot possibly do as you suggest.



In any case, notice the double quote in the output. To me this suggests the
backslash is acting not as a path terminator but as an escape sequence.


This is happening because of how standard Windows programs deal with " and
\ on the command line.

Re: My ACCU 2016 keynote video available online

[Andrei Alexandrescu via Digitalmars-d-announce]

On 05/19/2016 05:36 PM, Jens Müller wrote:

I removed the code to optimize for large gaps. Because it is only
confusing. I may generate some benchmark data with larger gaps later to
see whether it is worthwhile for such data.


For skipping large gaps quickly, check galloping search (google for it, 
we also have it in phobos). -- Andrei

Re: My ACCU 2016 keynote video available online

[Andrei Alexandrescu via Digitalmars-d-announce]

On 05/19/2016 05:36 PM, Jens Müller wrote:

I'm not seeing it. Let me explain.
Consider the input a = [1] and b = [2, 3] (I only write the indices).
The smallest back index is 1, i.e., a.back is the chosen sentinel.


Nonono, you stamp the largest index over the smaller index. So you 
overwrite a = [3] and you leave b = [2, 3] as it is.


Now you know that you're multiplying two correct sparse vectors in which 
_definitely_ the last elements have equal indexes. So the inner loop is:


if (a[i].idx < b[j].idx) {
  i++; // no check needed
} else if (a[i].idx > b[j].idx) {
  j++; // no check needed
} else {
  // check needed
  r += a[i].val * b[j].val;
  if (i == imax || j == jmax) break;
  ++i;
  ++j;
}

At the end you need a fixup to make sure you account for the last index 
that you overwrote (which of course you need to save first).


Makes sense?


Andrei

Re: My ACCU 2016 keynote video available online

[Jens Müller via Digitalmars-d-announce]

On Thursday, 19 May 2016 at 12:04:31 UTC, Andrei Alexandrescu 
wrote:

On 5/19/16 4:12 AM, Jens Müller wrote:

---
if (a.length == 0 || b.length == 0)
return 0;
const amax = a.length - 1, bmax = b.length - 1;
size_t i,j = 0;
double sum = 0;
for (;;)
{
if (a[i].index < b[j].index) {
if (i++ == amax) break;
}
else if (a[i].index > b[j].index) {
bumpJ: if (j++ == bmax) break;
}
else
{
assert(a[i].index == b[j].index);
sum += a[i].value * b[j].value;
if (i++ == amax) break;
goto bumpJ;
}
}
return sum;
---

Then if you add the sentinel you only need the bounds tests in 
the third case.


I'm not seeing it. Let me explain.
Consider the input a = [1] and b = [2, 3] (I only write the 
indices). The smallest back index is 1, i.e., a.back is the 
chosen sentinel. Now I assume that we set b.back to a.back 
restoring it after the loop. Now in the case a[i].index < 
b[j].index I have to check whether a[i].index == a.back.index to 
break because otherwise i is incremented (since a[i].index = 1 
and b[j].index = 2, for i = 0 and j = 0 respectively). In the 
last case I only check a[i].index == a.back.index, since this 
implies b[j].index == a.back.index.
So in sum I have two bounds tests. But I think this is not what 
you are thinking of.

This does not look right.
Here are the plots for the implementations.
https://www.scribd.com/doc/313204510/Running-Time
https://www.scribd.com/doc/313204526/Speedup

dot1 is my baseline, which is indeed worse than your baseline 
(dot2). But only on gdc. I choose dot2 as the baseline for 
computing the speedup. dot3 is the sentinel version.


I removed the code to optimize for large gaps. Because it is only 
confusing. I may generate some benchmark data with larger gaps 
later to see whether it is worthwhile for such data.

It looks much more regular now (ldc is still strange).

Jens

Re: mutable keyword

[QAston via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 20:44:54 UTC, ciechowoj wrote:
Is there D equivalent of C++'s mutable keyword? Like the one 
that allows to modify a field of struct from constant method. 
Or some alternative solution?


There isn't an equivalent of mutable keyword because D const 
differs from C++ const. D const has stronger guarantees (nothing 
reachable from const object will be mutable) so you'll use it 
less often compared to C++.


There's a talk on usage of const in D and I think its author also 
wrote on the subject:

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

mutable keyword

[ciechowoj via Digitalmars-d-learn]

Is there D equivalent of C++'s mutable keyword? Like the one that 
allows to modify a field of struct from constant method. Or some 
alternative solution?

Re: Always false float comparisons

[Timon Gehr via Digitalmars-d]

On 19.05.2016 09:09, Walter Bright wrote:

On 5/18/2016 10:10 AM, Timon Gehr wrote:

double kahan(double[] arr){
double sum = 0.0;
double c = 0.0;
foreach(x;arr){
double y=x-c;

 double y = roundToDouble(x - c);


Those two lines producing different results is unexpected, because you 
are explicitly saying that y is a double, and the first line also does 
implicit rounding (probably -- on all compilers and targets that will be 
relevant in the near future -- to double). It's obviously bad language 
design on multiple levels.



double t=sum+y;

 double t = roundToDouble(sum + y);

c = (t-sum)-y;
sum=t;
}
return sum;
}


Those are the only two points in the program that depend on rounding.


If you say so. I would like to see an example that demonstrates that the 
first roundToDouble is required.


Also, in case that the compiler chooses to internally use higher 
precision for all local variables in that program, the 'roundToDouble's 
you have inserted will reduce precision in comparison to the case where 
they are not inserted, reducing magical precision enhancement that would 
otherwise happen. (I.e., assuming that some of the ideas are valid and 
it is in fact desirable to have variable precision enhancement depending 
on target, if I find a precision bug I can fix by adding roundToDouble, 
this introduces a potential regression on other targets. And as none of 
it was guaranteed to work in the first place, the resulting mess is all 
my fault.)



If you're implementing Kahan,


And if you are not? (I find the standard assumption that counterexamples 
to wrong statements are one-off special cases tiresome. This is not 
usually the case, even if you cannot construct other examples right away.)



you'd know that,


I would, but what often happens in practice is that people don't. For 
example because they wouldn't expect roundToDouble to be required 
anywhere in code that only uses doubles. They are right.



so there shouldn't be anything difficult about it.
...


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

Creating useful programs in D shouldn't require knowing (or thinking 
about) an excess amount of D-specific implicit arcane details of the 
language semantics. Being easy to pick up and use is a major selling 
point for D.


I'm not convinced there is nothing difficult about it. It's certainly a 
generator of incidental complexity. Also, error prone is not the same as 
difficult. Almost everybody makes some mistakes occasionally.



There's no reason to make the rest of the program suffer inaccuracies.


Indeed there isn't. I'm not suggesting to allow using a precision lower 
than the one specified.


If you are talking about programs that "benefit" from automatic 
extension of precision: do you think their authors are aware that e.g. 
their 32 bit release builds with gdc/ldc are producing wrong results?

template instantiation

[vit via Digitalmars-d-learn]

///Hello, i'm trying to implement d compiler and i've problems 
with some template corner cases.



class Type{}

class Foo(T : const T){
alias X = T;
}

alias Bar(T : Foo!Ts, Ts...) = Ts[0];

pragma(msg, "Foo1: ", Foo!(immutable Type).X);//Foo1: Type
pragma(msg, "Foo2: ", Foo!(Type).X);  //Foo2: Type

pragma(msg, "Bar: ", Bar!(Foo!(Type)));   //Bar: 
immutable(Type)


Last pragma attempted to extract template parameters from 
'Foo!(Type)' but since Foo!(immutable Type) == Foo!(Type) and 
Foo!(immutable Type) was instantiated first, it extracted wrong 
type.
If we change order of 1. and 2. pragma, result of 3. pragma will 
be Type and not immutable(Type).

Is this a bug?

Re: Always false float comparisons

[Timon Gehr via Digitalmars-d]

On 18.05.2016 19:10, Timon Gehr wrote:

implementation-defined behaviour


Maybe that wasn't the right term (it's worse than that; I think the 
documentation of the implementation is not even required to tell you 
precisely what it does).

Implement async/await using Fiber

[Yuxuan Shui via Digitalmars-d-learn]

I find this difficult because I can't passing data via 
Fiber.yield/Fiber.call pair. e.g. I want something like:


void fiberFunc() {
   //Add some file descriptor to main loop
   string y = Fiber.yield();
   writeln(y);
}

auto f = new Fiber();
f.call();
mainloop {
   if (fd_readable)
  f.call(fd.rawRead());
}

I can probably using a derived fiber class and pass the result 
via class members, but that seems clumsy and not very general. 
Any ideas?

Re: How to share an appender!string?

[Era Scarecrow via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 19:31:26 UTC, Era Scarecrow wrote:
An alternate to writing a custom appender is simply to make the 
assignment atomic. Haven't tried this but if you did 'shared 
string[] lines;'


 I'll experiment with this and get back with you. 
Multi-threading isn't my strong suit either.


 Experimented and quickly got what looks like good clean results. 
Took your code, ripped out what I didn't want and added in what I 
did. Simple!


 https://dpaste.dzfl.pl/6952fdf463b66

Re: Possible bug in std.path?

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 19 May 2016 at 15:25:02 UTC, Kagamin wrote:
On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer 
wrote:
Then complain to Microsoft :) This is Microsoft's command 
shell sending that parameter to your program.


This is how CommandLineToArgvW behaves, which is called by 
druntime to parse the command line. For example, xcopy parses 
the command line correctly, e.g. this works as expected:

xcopy file "..\"


As far as I know, CommandLineToArgvW is *the* correct way to 
parse command-line arguments on Windows. If you do not use it, 
then your program will not work correctly when invoked by other 
programs which assume you use it, and this includes most programs 
which use libraries that accept program arguments as an array 
(which is the correct abstraction for program arguments anyway).


The fact that some standard Windows utilities do not obey this 
convention is more likely a historical artifact from DOS days.

Re: How to share an appender!string?

[Era Scarecrow via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 13:33:50 UTC, Thorsten Sommer wrote:
Issue analysis: My main issue was that the main() does not 
waited for the new thread (I used spawn() before I opened this 
discussion). Thus, a simple thread_joinAll(); solved that.


Since each thread can run at different times having 
thread_joinAll() would be best at the end of a loop or before 
writing the output.


An alternate to writing a custom appender is simply to make the 
assignment atomic. Haven't tried this but if you did 'shared 
string[] lines;' then you could build the string and then append 
the string to the lines. You could also avoid adding newlines 
since they would be appended afterwards by a helper function.


void writeLintes(File output) {
  foreach(ln; lines) {
output.writeln(ln);
  }
}

 I actually wonder how much of it would have to be shared at that 
point, since strings are immutable then the returning/assigning 
strings are safe once set; The only thing that needs to be shared 
is the array that grows as the chances of reallocation.


 I'll experiment with this and get back with you. Multi-threading 
isn't my strong suit either.

Use Requests to send data to webpage - how?

[TheDGuy via Digitalmars-d-learn]

Hi,
i was sucessfull in installing requests and getting data from a 
webpage like this:


Request rq = Request();
Response rs = rq.exec!"GET"("http://somewebpage.org/SQL.php;, 
["action":"getTemp"]);


But i am not able to send data to the webpage like this:

Request rq = Request();
Response rs = rq.exec!"GET"("http://somewebpage.org;, 
[parameter:data]);


If i just type this:

http://somewebpage.org/?parameter=data

in my browser the webpage reacts as intended but with the 
Requests "GET" nothing happens. Do you know what i do wrong?

immutable shared not accepted as TypeCtor ?

[Basile B. via Digitalmars-d-learn]

void main()
{
alias T = immutable(shared(int));
static assert(is(T==immutable));
static assert(is(T==shared));
}

It probably doesn't make sense to have immutable shared data but 
the grammar indicates that there can be many of them without any 
explicit restriction.



Is it a bug ?

[Issue 15959] core.sys.windows modules should be modified for x64

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/fa93b0b2ac3214f020c7f96859c5dcfd61fbff9b
Merge pull request #1575 from qchikara/pr-size_t

More fix of issue 15959 (size_t)

--

Re: Always false float comparisons

[Timon Gehr via Digitalmars-d]

On 19.05.2016 08:04, Joakim wrote:

On Wednesday, 18 May 2016 at 17:10:25 UTC, Timon Gehr wrote:

It's not just slightly worse, it can cut the number of useful bits in
half or more! It is not unusual, I have actually run into those
problems in the past, and it can break an algorithm that is in Phobos
today!


I wouldn't call that broken.  Looking at the hex output by replacing %f
with %A in writefln, it appears the only differences in all those
results is the last byte in the significand.


Argh...

// ...

void main(){
//double[] data=[1e16,1,-9e15];
import std.range;
double[] data=1e16~repeat(1.0,1).array~(-9e15);
import std.stdio;
writefln("%f",sum(data)); // baseline
writefln("%f",kahan(data)); // kahan
writefln("%f",kahanBroken(data)); // broken kahan
}


dmd -run kahanDemo.d
1000.00
1001.00
1000.00

dmd -m32 -O -run kahanDemo.d
1000.00
1000.00
1000.00


Better?

Obviously there is more structure in the data that I invent manually 
than in a real test case where it would go wrong. The problems carry 
over though.




As Don's talk pointed out,
all floating-point calculations will see loss of precision starting there.
...



This is implicitly assuming a development model where the programmer 
first writes down the computation as it would be correct in the real 
number system and then naively replaces every operation by the rounding 
equivalent and hopes for the best.


It is a useful rule if that is what you're doing. One might be doing 
something else. Consider the following paper for an example where the 
last bit in the significant actually carries useful information for many 
of the values used in the program.


http://www.jaist.ac.jp/~s1410018/papers/qd.pdf


In this case, not increasing precision gets the more accurate result,
but other examples could be constructed that _heavily_ favor increasing
precision.


Sure. In such cases, you should use higher precision. What is the 
problem? This is already supported (the compiler is not allowed to use 
lower precision than requested).



In fact, almost any real-world, non-toy calculation would
favor it.

In any case, nobody should depend on the precision out that far being
accurate or "reliable."



IEEE floating point has well-defined behaviour and there is absolutely 
nothing wrong with code that delivers more accurate results just because 
it is actually aware of the actual semantics of the operations being 
carried out.

Re: Speed up `dub`.

[ciechowoj via Digitalmars-d-learn]

On Sunday, 15 May 2016 at 01:48:41 UTC, cy wrote:


dub build --nodeps

It's amazing.



I tried it, doesn't seem to do anything, maybe something is 
broken.

Re: Using -O with DMD seems to produce non-random values.

[ag0aep6g via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 17:07:27 UTC, Michael wrote:

On Thursday, 19 May 2016 at 15:49:17 UTC, ag0aep6g wrote:

[...]

[1] https://issues.dlang.org/show_bug.cgi?id=16027


Yeah that's what I was thinking but I don't know much about the 
optimisation process so I wanted to mention it anyway.


And now I see that you linked there yourself in the OP. No idea 
how I missed that.

Re: Speed up `dub`.

[ciechowoj via Digitalmars-d-learn]

On Sunday, 15 May 2016 at 06:49:00 UTC, Russel Winder wrote:
I am not sure about DStep build, but for the two projects I 
have (using
GtkD) build times using Dub were sufficiently long that I 
switched to
SCons and it is OK and allows for a reasonable development 
rhythm.


That SCons looks very nice but don't have time (and dub isn't 
that bad) to research it more/can't migrate to it. If I have more 
time I'll certainly try it out.

Re: D's Auto Decoding and You

[Taylor Hillegeist via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote:

http://jackstouffer.com/blog/d_auto_decoding_and_you.html

Based on the recent thread in General, I wrote this blog post 
that's designed to be part beginner tutorial, part objective 
record of the debate over it, and finally my opinions on the 
matter.


When I first learned about auto-decoding, I was kinda miffed 
that there wasn't anything in the docs or on the website that 
went into more detail. So I wrote this in order to introduce 
people who are getting into D to the concept, it's benefits, 
and downsides. When people are confused in Learn why 
typeof(s.front) == dchar then this can just be linked to them.


If you think there should be any more information included in 
the article, please let me know so I can add it.


I ran into an auto decoding problem earlier. Honestly I was 
upset, and I think I was rightly upset. The programming language 
moved my cheese without telling me. I tend to believe in the 
route of least surprise. if as a newbie I am doing something 
stupid and find out i was wrong, that is one thing. but if i 
continue to do something wrong and find out that the programming 
language thinks I am stupid that's another thing.


If people want auto coding behavior shouldn't they just use or 
convert to dchar?

Re: Possible bug in std.path?

[Kagamin via Digitalmars-d]

On Thursday, 19 May 2016 at 16:02:27 UTC, Steven Schveighoffer 
wrote:
The reason for this (as spelled out in the comments) is to get 
around the poor handling of utf8 by Windows.


One receives unicode arguments by declaring wmain function. 
AFAIK, mingw and msvc do it fine, not sure about dmc.

Re: Using -O with DMD seems to produce non-random values.

[Michael via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 15:49:17 UTC, ag0aep6g wrote:

On 05/19/2016 05:09 PM, Michael wrote:
Any idea what causes this to occur when optimising? I wanted 
to try and

speed up a simulation I'm running but it just produces too many
unexpected consequences.


I suspect that you're seeing issue 16027 [1], a bad bug in 
2.071.0. The upcoming 2.071.1 point release should have it 
fixed.



[1] https://issues.dlang.org/show_bug.cgi?id=16027


Yeah that's what I was thinking but I don't know much about the 
optimisation process so I wanted to mention it anyway.

Re: DMD producing huge binaries

[Andrei Alexandrescu via Digitalmars-d]

On 05/19/2016 11:56 AM, Georgi D wrote:

Making a local copy of chain and moving the structure outside of the
method solved the problem and reduced the code size.

The stripped size even reduced from the version that did not experience
the huge increase. Stripped: 7.4Mb -> 5.5MB


Thanks very much for helping with these measurements! -- Andrei

Re: D's Auto Decoding and You

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

On Thu, May 19, 2016 at 09:21:40AM -0400, Steven Schveighoffer via 
Digitalmars-d-announce wrote:
> On 5/17/16 8:36 PM, H. S. Teoh via Digitalmars-d-announce wrote:
> > On Tue, May 17, 2016 at 08:19:48PM +, Vladimir Panteleev via 
> > Digitalmars-d-announce wrote:
> > > On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote:
> > > > However, it's perfectly legal for a front function not to be
> > > > tagged @property.
> > > 
> > > BTW, where is this coming from? Is it simply an emergent property
> > > of the existing implementations of isInputRange and ElementType,
> > > or is it actually by design?
> > 
> > This is very bad. The range API does not mandate that .front must be
> > a function. I often write ranges where .front is an actual struct
> > variable that gets updated by .popFront.  Now you're saying that my
> > range won't work with some code, because they call .front() (which
> > is a compile error when .front is a variable, not a function)?
> 
> My goodness no!
> 
> People, please, my point is simply that is(typeof(someRange.front) ==
> ElementType!(typeof(someRange))) DOESN'T ALWAYS WORK.

OK, so the point is, use ElementType!(typeof(range)) instead of
typeof(range.front)? That works for me. Sorry for the noise. :-P


[...]
> > In the old days (i.e., 1-2 years ago), isForwardRange!R will return
> > false if .save is not marked @property. I thought isInputRange!R did
> > the same for .front, or am I imagining things?  Did somebody change
> > this recently?
> 
> You are imagining that someInputRange.front ever required that. In
> fact, it would have had to go out of its way to do so (because
> isInputRange puts no requirements on the *type* of front, except that
> it returns a non-void value).
> 
> But you are right that save did require @property at one time. Not (In
> my opinion) because it meant to, but because it happened to check the
> type of r.save against a type (namely, that .save returns its own
> type).

Ah, so that's where it came from. Now I remember that there were bugs
caused by .save returning something other than the original range type,
which broke certain algorithms. That's probably where the whole .save
requiring @property thing came from.


> At the same time, I fixed all the isXXXRange traits so @property is
> not required anywhere. In particular, isRandomAccessRange required
> r.front to be @property, even when isInputRange didn't (again, IMO
> unintentionally). Here is the PR:
> https://github.com/dlang/phobos/pull/3276
[...]

Thanks for the info!


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but when my 
big brothers say it it means "no"! -- PJ jr.

Re: Possible bug in std.path?

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 12:02 PM, Steven Schveighoffer wrote:

On 5/19/16 11:25 AM, Kagamin wrote:

On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer wrote:

Then complain to Microsoft :) This is Microsoft's command shell
sending that parameter to your program.


This is how CommandLineToArgvW behaves, which is called by druntime to
parse the command line. For example, xcopy parses the command line
correctly, e.g. this works as expected:
xcopy file "..\"


Thanks for correcting, this is a difference from posix that I forgot about.

The reason for this (as spelled out in the comments) is to get around
the poor handling of utf8 by Windows.

I think if you write a C program in Windows, your argv/argc will contain
.."

You'd have to do the same acrobatics D does to get the original, so I
don't think this is a problem that we need to solve. Use those low-level
functions if you wish.


For reference to OP, here is the code that accesses original command 
line, which you can model for your desired behavior:


https://github.com/dlang/druntime/blob/master/src/rt/dmain2.d#L356

-Steve

Re: Always false float comparisons

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 19 May 2016 at 11:33:38 UTC, Joakim wrote:

Computer scientists are no good if they don't know any science.


Even the computer scientists that does not know any science are 
infinitely better than those who refuse to read papers and debate 
on a rational level.


Blind D zealotry at its finest.

Re: DMD producing huge binaries

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 11:56 AM, Georgi D wrote:

On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer wrote:

On 5/17/16 6:04 PM, ZombineDev wrote:

I'm guessing that is highly related to this one:
https://issues.dlang.org/show_bug.cgi?id=15831


Yep. chain uses voldemort type, map does not.

Georgi: try copying chain implementation into your local file, but
instead of having a static internal struct, move it to a module-level
struct (you probably have to repeat the template parameters, but not
the constraints). See if it produces a similar slimming effect.



Yes,

Making a local copy of chain and moving the structure outside of the
method solved the problem and reduced the code size.


Thanks, that confirms the bug reports are for the same issue.



The stripped size even reduced from the version that did not experience
the huge increase. Stripped: 7.4Mb -> 5.5MB

Should we actually change the implementation in phobos to be like this?


I'd much prefer we fix the compiler to handle voldemort types in a more 
sane way rather than try and fix the code to deal with compiler 
deficiencies. However, if this isn't something that's easily done (or 
done within a decent time frame), we may look at that solution.



In the company I work in we are very sensitive to the code size so
anything that can be made for this in phobos will help with adoption.

I am still curious though why the code size increased so dramatically
with such a small change. Both versions return a result from chain and
actually the one that does not experience the increase is more complex
(includes the one that does).


Each call to a voldemort wrapping function (one that wraps one type into 
another "voldemort" type, or internal struct) increases the symbol size 
at a rate of 3^n. Non-voldemort types do not suffer from this, because 
the symbol size increases at just n.



In my actual code I have multiple calls to chain on top of the result of
this and the code size does not increase dramatically.

I am also concerned by the fact that ldc on mac just could not compile
the source which produced the big binary (entering an infinite loop).


I would expect the possibility that the issue is with the linker. In my 
toy experiments, the compiler works just fine and produces an object 
file. It's the linker having issues with parsing those humungous symbols.


-Steve

[Issue 16039] DMD produces huge binary when using a complex chain of lazy range algorithms

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #1 from Steven Schveighoffer  ---
Thanks. This is a duplicate of 15831

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

--

[Issue 15831] IFTI voldemort type exploding bloat

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||geor...@outlook.com

--- Comment #3 from Steven Schveighoffer  ---
*** Issue 16039 has been marked as a duplicate of this issue. ***

--

Re: Possible bug in std.path?

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 11:25 AM, Kagamin wrote:

On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer wrote:

Then complain to Microsoft :) This is Microsoft's command shell
sending that parameter to your program.


This is how CommandLineToArgvW behaves, which is called by druntime to
parse the command line. For example, xcopy parses the command line
correctly, e.g. this works as expected:
xcopy file "..\"


Thanks for correcting, this is a difference from posix that I forgot about.

The reason for this (as spelled out in the comments) is to get around 
the poor handling of utf8 by Windows.


I think if you write a C program in Windows, your argv/argc will contain .."

You'd have to do the same acrobatics D does to get the original, so I 
don't think this is a problem that we need to solve. Use those low-level 
functions if you wish.


-Steve

Re: DMD producing huge binaries

[Georgi D via Digitalmars-d]

On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer 
wrote:

On 5/17/16 6:04 PM, ZombineDev wrote:
On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu 
wrote:

On 05/17/2016 05:44 PM, Georgi D wrote:

Hi,

While working on a D project which heavily uses the lazy 
algorithms for
ranges I noticed a sudden huge increase in the compilation 
time and the

produced binary size.

[snip]

Thanks. That's definitely deserving of a bug report. -- Andrei


I'm guessing that is highly related to this one:
https://issues.dlang.org/show_bug.cgi?id=15831


Yep. chain uses voldemort type, map does not.

Georgi: try copying chain implementation into your local file, 
but instead of having a static internal struct, move it to a 
module-level struct (you probably have to repeat the template 
parameters, but not the constraints). See if it produces a 
similar slimming effect.


-Steve


Yes,

Making a local copy of chain and moving the structure outside of 
the method solved the problem and reduced the code size.


The stripped size even reduced from the version that did not 
experience the huge increase. Stripped: 7.4Mb -> 5.5MB


Should we actually change the implementation in phobos to be like 
this?


In the company I work in we are very sensitive to the code size 
so anything that can be made for this in phobos will help with 
adoption.


I am still curious though why the code size increased so 
dramatically with such a small change. Both versions return a 
result from chain and actually the one that does not experience 
the increase is more complex (includes the one that does).


In my actual code I have multiple calls to chain on top of the 
result of this and the code size does not increase dramatically.


I am also concerned by the fact that ldc on mac just could not 
compile the source which produced the big binary (entering an 
infinite loop).


Thanks

Re: Using -O with DMD seems to produce non-random values.

[ag0aep6g via Digitalmars-d-learn]

On 05/19/2016 05:09 PM, Michael wrote:

Any idea what causes this to occur when optimising? I wanted to try and
speed up a simulation I'm running but it just produces too many
unexpected consequences.


I suspect that you're seeing issue 16027 [1], a bad bug in 2.071.0. The 
upcoming 2.071.1 point release should have it fixed.



[1] https://issues.dlang.org/show_bug.cgi?id=16027

Re: Using -O with DMD seems to produce non-random values.

[Kagamin via Digitalmars-d-learn]

how this works?

double[] generateValues(ref Random rand, int l)
{
auto values = new double[](l);
foreach (ref val; values)
{
auto value = 1;
if (uniform(0, 2, rand))
{
value = value * -1;
}
val = value;
}

return values;
}

Re: static member and/or @property ?

[chmike via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 15:33:21 UTC, ag0aep6g wrote:

. . .
interface AThing
{
final string name() { return nameImpl(); }
string nameImpl();
}

class OneThing : AThing
{
static string name() { return "OneThing"; }
override string nameImpl() { return name(); }
}

class OtherThing : AThing
{
static string name() { return "OtherThing"; }
override string nameImpl() { return name(); }
}


This is what I was looking fer. Thank you very much.

The fact that I used the class name is just a coincidence for 
making the example clear.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:

Am Wed, 18 May 2016 18:57:48 +
schrieb ParticlePeter :


On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
> On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König 
> wrote:
> 
>> I think I will use glfw3 later. I don't know if the 
>> original problem of using multiple configurations (xcb, 
>> xlib, glfw3, ...) is possible with only dub's internal 
>> logic. I tried putting this in my "vulkantest" packages' 
>> dub.json

>>
>> "subConfigurations":
>> {
>>"erupted": "with-derelict-loader",
>>"erupted": "normal"
>> }
>>
>> just for testing, and dub told me
>>
>> Could not resolve configuration for package vulkantest
>>
>> So I thinnk multiple subconfigurations are not supported.
>
> The way to handle this is to make multiple configurations of 
> vulkantest, one for each of the configurations of erupted 
> you want to support. Then, when you build vulkantest, you 
> specify the configuration you want to build on the command 
> line (unless you're building the default).


This is a good point, the custom project platform 
configuration would then be forwarded to erupted. Only 
drawback would be that "with-derelict-loader" config is not 
available in combination with a platform config, but in the 
later case you would want to grab vkGetInstanceProcAddr anyway 
in platform specific means.


Manuel, I could just skim over xcb-d. As far as I can see it 
has the module xcb.xcb. Is this module sufficient to be 
imported in erupted.types.d? In this case I would not have to 
touch the erupt.py generator but instead just fix the 
erupted.dub file. As you can test it, how about a pull request?




@ Peter: Yes, importing xcb.xcb is all you need, no patches 
necessary. But I could patch erupteD's dub.json for an xcb 
configuration, and maybe put in the readme how to use a 
configuration, but probably not until sunday.


@Mike: Having multiple subconfigurations (xcb, xlib, glfw3, 
...) to pick for the user is the solution Peter was going for, 
as I understood him. The problem is when a user wants to 
support both xcb and xlib, or any mix of them. But this is 
probably just a pathetic use case not relevant in practice, I 
just stumbled over the question if that is possible when I 
wanted to add proper xcb, xlib, etc. support to erupteD.


As far as I understand Mike it is still possible. Suppose you 
build an engine based on (d-)vulkan/erupted, lets call it 
Turtle-Engine, you would also specify sub-configurations for xcb, 
xlib, win, ... and you could support any of (d-)vulkans/erupted 
sub-configs in your corresponding configs. When some dude (no 
sexual prejudice meant) wants to write a Turtle-App, which is 
based on your Turtle-Engine he decides how many of your configs 
representing platforms he would like to support. Now you see, as 
the language architect pointed out, its turtles all the way down.

Re: DMD producing huge binaries

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 10:43 AM, Steven Schveighoffer wrote:


Or even better:

template(T) foo if (someConstraints)
{
struct Result
{
   T t;
}

auto foo(T t)
{
   return Result(t);
}
}


This solution works awesomely, actually. It even produces smaller code 
than moving the struct completely outside.


I'm going to use this mechanism in iopipe to get my voldemorts back :)

-Steve

Re: static member and/or @property ?

[ag0aep6g via Digitalmars-d-learn]

On 05/19/2016 05:04 PM, chmike wrote:

interface AThing { ??? string name ??? }

class OneThing : AThing { ??? string name ??? "OneThing" ??? }

class OtherThing : AThing { ??? string name ??? "OtherThing" ??? }


void main()
{
// Accessing name as static information
writeln(OneThing.name ??? );

// Accessing name through polymorphism
AThing tbl;
tbl ~= new OneThing;
tbl ~= new OtherThing;
tbl ~= new OneThing;
foreach(a; tbl) writeln(a.name???);
}

The only viable solution I found so far is by using distinct member
names. In the interface we define name as a property, and in the class
we define the static member with another name. Is it possible to avoid
the different names ?


Here's what I could come up with. I wouldn't be surprised if there was a 
simpler way to do it.



interface AThing
{
final string name() { return nameImpl(); }
string nameImpl();
}

class OneThing : AThing
{
static string name() { return "OneThing"; }
override string nameImpl() { return name(); }
}

class OtherThing : AThing
{
static string name() { return "OtherThing"; }
override string nameImpl() { return name(); }
}

void main()
{
   import std.stdio;

   // Accessing name as static information
   writeln(OneThing.name);

   // Accessing name through polymorphism
   AThing[] tbl;
   tbl ~= new OneThing;
   tbl ~= new OtherThing;
   tbl ~= new OneThing;
   foreach(a; tbl) writeln(a.name);
}


Can use a mixin template to reduce the boilerplate:


interface AThing
{
final string name() { return nameImpl(); }
string nameImpl();

mixin template nameMixin()
{
static string name() { return typeof(this).stringof; }
override string nameImpl() { return name(); }
}
}

class OneThing : AThing { mixin AThing.nameMixin; }
class OtherThing : AThing { mixin AThing.nameMixin; }

Re: Using -O with DMD seems to produce non-random values.

[Michael via Digitalmars-d-learn]

Could it be that the code is optimised to the same as that in the 
original issue and so the current compiler still produces the 
incorrect result? Obviously the original issue has since been 
fixed but I won't be able to test this until the next version of 
DMD is released.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Thursday, 19 May 2016 at 00:09:42 UTC, Alex Parrill wrote:
Apparently GitHub didn't add my own repo to my list of watch 
repos, meaning no notifications for them...

I'll look over the pull request. Let's not split this project.


Depends on how far you want to catch up. Lets discuss this in the 
d-vulkan issues.

[Issue 16048] New: std.getopt: duplicated (short) options are not detected

[via Digitalmars-d-bugs]

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

  Issue ID: 16048
   Summary: std.getopt: duplicated (short) options are not
detected
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: andrej.mitrov...@gmail.com

If you have multiple config options such as:

-
getopt(args, "arg1|a", , "arg2|a", );
-

Getopt won't complain about this, and will parse all 'a' options into arg1.

--

Re: Possible bug in std.path?

[Kagamin via Digitalmars-d]

On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer 
wrote:
Then complain to Microsoft :) This is Microsoft's command shell 
sending that parameter to your program.


This is how CommandLineToArgvW behaves, which is called by 
druntime to parse the command line. For example, xcopy parses the 
command line correctly, e.g. this works as expected:

xcopy file "..\"

Re: static member and/or @property ?

[Edwin van Leeuwen via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 15:12:44 UTC, Edwin van Leeuwen wrote:

On Thursday, 19 May 2016 at 15:04:00 UTC, chmike wrote:
The only viable solution I found so far is by using distinct 
member names. In the interface we define name as a property, 
and in the class we define the static member with another 
name. Is it possible to avoid the different names ?


Can you use identifier!(typeof(this)) or something along those 
lines. I am not sure how it behaves with inheritance.


https://dlang.org/spec/traits.html#identifier


Sorry I meant __traits(identifier, typeof(this)).

Re: D mentioned and criticized

[Chris via Digitalmars-d]

On Thursday, 19 May 2016 at 13:53:46 UTC, Guillaume Piolat wrote:

On Wednesday, 18 May 2016 at 21:45:16 UTC, Abdulhaq wrote:
On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat 
wrote:
On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat 
wrote:
Nim is much more interesting as a D alternative, in the 
sense that it is a.


I give up, kept pressing ENTER while typing a message.


Please finish, I have to know what follows "a" :-)


Nim is much more interesting as a D alternative, in the sense 
that it is a more radical departure from C++. Be it in syntax, 
meta-programming, and experimental features. It certainly said 
no to variable-sized integers, while Loci stays with them.


It certainly is interesting. The fact that it compiles to C, C++ 
or Objective-C is also pretty handy.


What turns me off is obligatory indentation à la Python :(, and I 
don't know how the fact that it compiles to C affects the 
language as a whole.

Re: static member and/or @property ?

[Edwin van Leeuwen via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 15:04:00 UTC, chmike wrote:
The only viable solution I found so far is by using distinct 
member names. In the interface we define name as a property, 
and in the class we define the static member with another name. 
Is it possible to avoid the different names ?


Can you use identifier!(typeof(this)) or something along those 
lines. I am not sure how it behaves with inheritance.


https://dlang.org/spec/traits.html#identifier

Using -O with DMD seems to produce non-random values.

[Michael via Digitalmars-d-learn]

I'm not entirely sure what optimisations are made when supplying 
the -O flag to rdmd, but this may be related to an earlier issue 
I found for similar code here:

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

The code is:
void main()
{
auto seed = 128;
auto rand = Random(seed);
double[] values;

values = generateValues(rand, 10);

writeln(values);
}

double[] generateValues(ref Random rand, int l)
{
auto values = new double[](l);
foreach (ref val; values)
{
auto value = 1.0;
if (uniform(0, 2, rand))
{
value = value * -1;
}
val = value;
}

return values;
}

Which returns different values depending on whether -O is passed:

$rdmd testing_optimiser.d
[1, -1, -1, 1, -1, 1, 1, 1, -1, -1]
$rdmd -O testing_optimiser.d
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1]


Any idea what causes this to occur when optimising? I wanted to 
try and speed up a simulation I'm running but it just produces 
too many unexpected consequences.

Re: Benjamin Thaut's talk: D's Import and Export Business

[flamencofantasy via Digitalmars-d]

On Thursday, 19 May 2016 at 15:08:32 UTC, Ali Çehreli wrote:

On 05/19/2016 07:15 AM, flamencofantasy wrote:


What's the URL to watch the videos? Thanks.


Until the HD versions appear later (presumably on YouTube), all 
current videos are here:



https://www.sociomantic.com/blog/2016/05/follow-dconf-2016-in-real-time/#.Vz3WR5R4foe

You can find a particular day and talk in the scrollable list 
there.


Ali


Thank you.

Re: Benjamin Thaut's talk: D's Import and Export Business

[Ali Çehreli via Digitalmars-d]

On 05/19/2016 07:15 AM, flamencofantasy wrote:


What's the URL to watch the videos? Thanks.


Until the HD versions appear later (presumably on YouTube), all current 
videos are here:



https://www.sociomantic.com/blog/2016/05/follow-dconf-2016-in-real-time/#.Vz3WR5R4foe

You can find a particular day and talk in the scrollable list there.

Ali

Re: DMD producing huge binaries

[Andrei Alexandrescu via Digitalmars-d]

On 5/19/16 10:56 AM, Daniel Murphy wrote:

On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote:

On 05/19/2016 10:43 AM, Steven Schveighoffer wrote:

This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?


That's also a possibility, but likely a more complicated one. -- Andrei


We don't actually need to lower it, just mangle it as if it was lowered.


Noice! -- Andrei

Re: DMD producing huge binaries

[Daniel Murphy via Digitalmars-d]

On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote:

On 05/19/2016 10:43 AM, Steven Schveighoffer wrote:

This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?


That's also a possibility, but likely a more complicated one. -- Andrei


We don't actually need to lower it, just mangle it as if it was lowered.

static member and/or @property ?

[chmike via Digitalmars-d-learn]

Sorry for the confusing subject, I couldn't find a concise 
formulation of my question.


I have a set of classes derived from the same interface so that I 
can use polymorphism.


I would like to store the name of the class as a string so that 
it can be retrieved as a static member of the class or by using 
polymorphism.


Here is the problem expressed as an exercise where you are 
invited to replace the ??? with the appropriate text, if it is 
possible. My blind and naive attempts failed.


interface AThing { ??? string name ??? }

class OneThing : AThing { ??? string name ??? "OneThing" ??? }

class OtherThing : AThing { ??? string name ??? "OtherThing" ??? }


void main()
{
   // Accessing name as static information
   writeln(OneThing.name ??? );

   // Accessing name through polymorphism
   AThing tbl;
   tbl ~= new OneThing;
   tbl ~= new OtherThing;
   tbl ~= new OneThing;
   foreach(a; tbl) writeln(a.name???);
}

The only viable solution I found so far is by using distinct 
member names. In the interface we define name as a property, and 
in the class we define the static member with another name. Is it 
possible to avoid the different names ?

[Issue 16047] New: Range violation in setting multi-dimensional AA entries

[via Digitalmars-d-bugs]

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

  Issue ID: 16047
   Summary: Range violation in setting multi-dimensional AA
entries
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kroepli...@googlemail.com

The following code results in a range violation for the second assignment to
`aa`, while the first assignment to `aa` works as expected:

unittest
{
import std.datetime;

struct S
{
   string s;

   this(string s)
   {
   this.s = s;
   }
}

SysTime[string][string] aa;

aa["bar"]["bar"] = SysTime.init;
aa[S("baz").s]["baz"] = SysTime.init;  // Range violation
}

Any further reduction of the example eliminates the issue.

--

[Issue 16037] Closure allocation despite scope variable for ternary operator / CondExp

[via Digitalmars-d-bugs]

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

Leandro Lucarella  changed:

   What|Removed |Added

 CC||leandro.lucarella@sociomant
   ||ic.com

--

Re: D mentioned and criticized

[Abdulhaq via Digitalmars-d]

On Thursday, 19 May 2016 at 13:53:46 UTC, Guillaume Piolat wrote:

On Wednesday, 18 May 2016 at 21:45:16 UTC, Abdulhaq wrote:
On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat 
wrote:
On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat 
wrote:
Nim is much more interesting as a D alternative, in the 
sense that it is a.


I give up, kept pressing ENTER while typing a message.


Please finish, I have to know what follows "a" :-)


Nim is much more interesting as a D alternative, in the sense 
that it is a more radical departure from C++. Be it in syntax, 
meta-programming, and experimental features. It certainly said 
no to variable-sized integers, while Loci stays with them.


Thanks :-) - interesting.

Re: Possible bug in std.path?

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 9:49 AM, Hugo wrote:

On Thursday, 19 May 2016 at 05:06:44 UTC, Vladimir Panteleev wrote:

Here you can see the final string value of the program argument in
your program.

The correct invocation is: mytest "my dir\\"


What you suggest is non-standard in Windows, and would require
distributing the application with some form of comment saying you have
to use double backslashes, which is unprofessional. Software should
serve the user and not the other way round.


Then complain to Microsoft :) This is Microsoft's command shell sending 
that parameter to your program.



Notice I am not debating the escape character, but the inconsistency of
buildNormalizedPath, which IMHO should have worked and fixed the
trailing backslash.


buildNormalizedPath is being send the string `my dir"`, what is it 
supposed to do with that?


-Steve

Re: DMD producing huge binaries

[Steven Schveighoffer via Digitalmars-d]

On 5/19/16 9:45 AM, Andrei Alexandrescu wrote:

On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:

Yep. chain uses voldemort type, map does not.


We definitely need to fix Voldemort types. Walter and I bounced a few
ideas during DConf.

1. Do the cleartext/compress/hash troika everywhere (currently we do it
on Windows). That should help in several places.

2. For Voldemort types, simply generate a GUID-style random string of
e.g. 64 bytes. Currently the name of the type is composed out of its
full scope, with some exponentially-increasing repetition of substrings.
That would compress well, but it's just a lot of work to produce and
then compress the name. A random string is cheap to produce and adequate
for Voldemort types (you don't care for their name anyway...
Voldemort... get it?).

I very much advocate slapping a 64-long random string for all Voldermort
returns and calling it a day. I bet Liran's code will get a lot quicker
to build and smaller to boot.


This may be crazy, but I solved this problem by simply moving the struct 
outside the function. What about a lowering that does this for you?


Example:

auto foo(T)(T t) if (someConstraints)
{
   static struct Result
   {
  T t;
   }
   return Result(t);
}

Changes to:

private struct foo_Result(T) if (someConstraints)
{
   T t;
}

auto foo(T)(T t) if (someConstraints)
{
   alias Result = foo_Result!T // inserted by compiler
   return Result(t);
}

Or even better:

template(T) foo if (someConstraints)
{
   struct Result
   {
  T t;
   }

   auto foo(T t)
   {
  return Result(t);
   }
}

What this does is lower the number of times the template parameters (and 
function arguments) appears in the type name to 1. This gets rid of the 
exponential nature of the symbol name.


This doesn't work for voldemorts with closures, but maybe it can somehow 
be reconstructed so the context is included in the generated struct.


-Steve

Re: Always false float comparisons

[Joakim via Digitalmars-d]

On Thursday, 19 May 2016 at 12:00:33 UTC, Joseph Rushton Wakeling 
wrote:

On Thursday, 19 May 2016 at 11:33:38 UTC, Joakim wrote:
The example he refers to is laughable because it also checks 
for equality.


With good reason, because it's intended to illustrate the point 
that two calculations that _look_ identical in code, that 
intuitively should produce identical results, actually don't, 
because of under-the-hood precision differences.


And that's my point too, that floating point will always subvert 
your expectations, particularly such simplistic notions of 
equality, which is why you should always use approxEqual or it's 
analogues.

Re: Benjamin Thaut's talk: D's Import and Export Business

[flamencofantasy via Digitalmars-d]

On Thursday, 19 May 2016 at 14:00:54 UTC, Andre Pany wrote:

Hi,

after looking Benjamins talk I took some time to think about it.
Benjamin made some effort towards a sophisticated DLL suppport 
for D.


What I understand: He won't push his changes until "export" 
will become an attribute.
But without his changes there is no need to change the semantic 
of "export".

It seems like a deadlock.

I tried to find a solution to this problem. For the moment I 
ignore the export issue
and have a look at linux. I understand in linux everything is 
exported by default.
If it is decided, that this default behavior is changed in the 
long term,

there needs to be a way to switch batch to the old behavior.
Therefore a compiler switch "exportAll" will be necessary.

So why do not start with this compiler switch, which will also
export all symbols on windows.
If the changes of Benjamin are adapted to this switch we can 
already get the sophisticated
dll support and can later decide on the semantic change of 
export.


Does this make sense?

Kind regards
André


What's the URL to watch the videos? Thanks.

[Issue 16046] New: ScopedAllocator does not set prev, causing segfaults

[via Digitalmars-d-bugs]

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

  Issue ID: 16046
   Summary: ScopedAllocator does not set prev, causing segfaults
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: initrd...@gmail.com

This code causes a segfault:

ScopedAllocator!MmapAllocator alloc;
auto foo = alloc.make!int(1).enforce;
auto bar = alloc.make!int(2).enforce;
alloc.dispose(foo);
alloc.dispose(bar); // segfault here

This is likely because ScopedAllocator.allocate does not set the prev pointer
of the old root when prepending a new node, so prev will always be null.

--

Re: DMD producing huge binaries

[Andrei Alexandrescu via Digitalmars-d]

On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:

Yep. chain uses voldemort type, map does not.


We definitely need to fix Voldemort types. Walter and I bounced a few 
ideas during DConf.


1. Do the cleartext/compress/hash troika everywhere (currently we do it 
on Windows). That should help in several places.


2. For Voldemort types, simply generate a GUID-style random string of 
e.g. 64 bytes. Currently the name of the type is composed out of its 
full scope, with some exponentially-increasing repetition of substrings. 
That would compress well, but it's just a lot of work to produce and 
then compress the name. A random string is cheap to produce and adequate 
for Voldemort types (you don't care for their name anyway... 
Voldemort... get it?).


I very much advocate slapping a 64-long random string for all Voldermort 
returns and calling it a day. I bet Liran's code will get a lot quicker 
to build and smaller to boot.



Andrei

Benjamin Thaut's talk: D's Import and Export Business

[Andre Pany via Digitalmars-d]

Hi,

after looking Benjamins talk I took some time to think about it.
Benjamin made some effort towards a sophisticated DLL suppport 
for D.


What I understand: He won't push his changes until "export" will 
become an attribute.
But without his changes there is no need to change the semantic 
of "export".

It seems like a deadlock.

I tried to find a solution to this problem. For the moment I 
ignore the export issue
and have a look at linux. I understand in linux everything is 
exported by default.
If it is decided, that this default behavior is changed in the 
long term,

there needs to be a way to switch batch to the old behavior.
Therefore a compiler switch "exportAll" will be necessary.

So why do not start with this compiler switch, which will also
export all symbols on windows.
If the changes of Benjamin are adapted to this switch we can 
already get the sophisticated

dll support and can later decide on the semantic change of export.

Does this make sense?

Kind regards
André

Re: D mentioned and criticized

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 18 May 2016 at 21:45:16 UTC, Abdulhaq wrote:

On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat wrote:
On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat 
wrote:
Nim is much more interesting as a D alternative, in the sense 
that it is a.


I give up, kept pressing ENTER while typing a message.


Please finish, I have to know what follows "a" :-)


Nim is much more interesting as a D alternative, in the sense 
that it is a more radical departure from C++. Be it in syntax, 
meta-programming, and experimental features. It certainly said no 
to variable-sized integers, while Loci stays with them.

Re: Possible bug in std.path?

[Hugo via Digitalmars-d]

On Thursday, 19 May 2016 at 05:06:44 UTC, Vladimir Panteleev 
wrote:
Here you can see the final string value of the program argument 
in your program.


The correct invocation is: mytest "my dir\\"


What you suggest is non-standard in Windows, and would require 
distributing the application with some form of comment saying you 
have to use double backslashes, which is unprofessional. Software 
should serve the user and not the other way round.


Notice I am not debating the escape character, but the 
inconsistency of buildNormalizedPath, which IMHO should have 
worked and fixed the trailing backslash.



In the future, consider posting to the learn group.


I did not post there because I thought this was not necessarily a 
newbie question. My apologies.

Re: How to share an appender!string?

[Thorsten Sommer via Digitalmars-d-learn]

Dear all,

I am done :) Thanks @Kagamin, @Rene and @rikki for the help.

Short answers:
@Rene: You are right, I missed the starting of that task i.e. 
thread. Used before spawn() where the thread runs directly. But 
spawn() crashes dpaste.pl...


@rikki: Yes, I known what you mentioned ;) I just constructed a 
very simple and short test code on dpaste.pl and not the full 
implementation of your proposal. Just the basic idea, which is 
great. Within my final solution, I still use your advice and 
reject appender but use just a simple data type instead.


@Rene: Thanks for the great idea with the destructor and the 
thread-local data :) I adapted that for my solution. The order of 
the entries does not matter for my case.


@Kagamin: It do not know why it crashes, but where: It comes from 
the spawn() call.



Issue analysis: My main issue was that the main() does not waited 
for the new thread (I used spawn() before I opened this 
discussion). Thus, a simple thread_joinAll(); solved that.


For the archive -- my final solution with comments:
https://dpaste.dzfl.pl/3a34df24ed6c


Best regards,
Thorsten

Re: mago-mi: GDB/MI compatible frontend for Mago debugger

[Bruno Medeiros via Digitalmars-d-announce]

On 19/05/2016 08:41, Vadim Lopatin wrote:

On Wednesday, 18 May 2016 at 18:02:12 UTC, Bruno Medeiros wrote:

While DDT technically work oks with GDB (the GDB from mingw-w64 that
is), you are right, there isn't a compiler on Windows that supplies
debug info in the way GDB understands. See
https://wiki.dlang.org/Debuggers.

DMD produces debug info COFF or OMF format, which GDB doesn't know
anything about (nor ever will). LDC should in theory work with DWARF
info, but this is broken somehow. Not because of LLVM though, since
for example Rust on Windows works. As for GDC, it doesn't even supply
binaries for Windows (that target Windows) -  it is not a supported
platform.

BTW, Eclipse/DDT should in theory work with mago-mi as well, at least
if the protocol is implemented correctly. Have you tried it? I dunno
how complete your MI implementation is.


So it looks like mago-mi might be helpful for DDT on Windows.
mago-mi supports subset of GDB/MI commands enough for DlangIDE, but it
can be easy extended.

Currenlty supported commands can be shown using help command (use
--interpreter=mi2 when running mago-mi, otherwise it will print non-MI
commands). Also commands are listed in readme file
https://github.com/buggins/mago/blob/master/MagoMI/mago-mi/README.md

I didn't try DDT with mago-mi, and so I'm not sure which commands must
be supported by debugger to get it working with DDT.

To get list of commands DDT tries to use you can either add
--log-file=magomi.log --log-level=TRACE to mago-mi command line or use
debug build of mago-mi.
It will all STDIN data to log file, and report errors for unsupported
commands.



I also don't know which MI commands need to be supported to have it work 
with DDT. The thing is I didn't write the GDB debugger integration for 
DDT, I just reused the one from CDT. So I'm not that familiar with those 
internals.


BTW, the MI integration is fairly language agnostic, so in theory your 
debugger could be used by CDT to debug C/C++ programs too, no? At least 
those generated by DMC. Maybe Visual Studio ones too?


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: ErrorException thrown when errno is modified ?

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

On Thursday, 19 May 2016 at 13:05:19 UTC, chmike wrote:
Checking the std.exception documentation I see that 
ErrnoException may be thrown when errors setting errno may 
occur. Does this affect the posix calls ?


It just means the Phobos functions that use these functions (like 
std.file or std.socket) might throw the exception, not the C 
functions themselves.

Re: ErrorException thrown when errno is modified ?

[Alex Parrill via Digitalmars-d-learn]

On Thursday, 19 May 2016 at 13:05:19 UTC, chmike wrote:

Hello,

I'm planning to call some posix functions core.sys.posix that 
may set the errno value in case of error. e.g. read() or 
write().


Checking the std.exception documentation I see that 
ErrnoException may be thrown when errors setting errno may 
occur. Does this affect the posix calls ?


From what I saw in the code, it doesn't seam the case. Just 
making sure I'm correct.


ErrnoException is the exception thrown by errnoEnforce, which is 
a convenient function for checking system calls.


D links to the same Posix functions that C does; their behavior 
is exactly the same (ie they don't throw).

Re: ErrorException thrown when errno is modified ?

[ag0aep6g via Digitalmars-d-learn]

On 05/19/2016 03:05 PM, chmike wrote:

I'm planning to call some posix functions core.sys.posix that may set
the errno value in case of error. e.g. read() or write().

Checking the std.exception documentation I see that ErrnoException may
be thrown when errors setting errno may occur. Does this affect the
posix calls ?

 From what I saw in the code, it doesn't seam the case. Just making sure
I'm correct.


I think the description for ErrnoException is a bit misleading. I'm 
fairly certain that there is no code running that watches errno and 
throws an ErrnoException whenever it gets set. Rather, code that calls C 
functions which set errno can/should use ErrnoException and the 
errnoEnforce helper function to make a nice Exception from an errno value.

Re: D's Auto Decoding and You

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/17/16 8:36 PM, H. S. Teoh via Digitalmars-d-announce wrote:

On Tue, May 17, 2016 at 08:19:48PM +, Vladimir Panteleev via 
Digitalmars-d-announce wrote:

On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote:

However, it's perfectly legal for a front function not to be tagged
@property.


BTW, where is this coming from? Is it simply an emergent property of
the existing implementations of isInputRange and ElementType, or is it
actually by design?


This is very bad. The range API does not mandate that .front must be a
function. I often write ranges where .front is an actual struct variable
that gets updated by .popFront.  Now you're saying that my range won't
work with some code, because they call .front() (which is a compile
error when .front is a variable, not a function)?


My goodness no!

People, please, my point is simply that is(typeof(someRange.front) == 
ElementType!(typeof(someRange))) DOESN'T ALWAYS WORK.


Here is the (long standing) definition of isInputRange:

template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {}   // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
}

Not there is no check for is(typeof(r.front)) to be some certain thing.

So this is a valid range:

struct AllZeros
{
int front() { return 0; }
enum empty = false;
void popFront() {}
}

Yet, is(typeof(AllZeros.init.front) == int) will be false. This is the 
line of code from the article that I suggested to add the parens to. 
Because in that particular case, string.front is a function, not a 
field. The code in question is NOT GENERIC, it's just showing that 
string.front is not the same as string[0]. It's very specific to string.




In the old days (i.e., 1-2 years ago), isForwardRange!R will return
false if .save is not marked @property. I thought isInputRange!R did the
same for .front, or am I imagining things?  Did somebody change this
recently?


You are imagining that someInputRange.front ever required that. In fact, 
it would have had to go out of its way to do so (because isInputRange 
puts no requirements on the *type* of front, except that it returns a 
non-void value).


But you are right that save did require @property at one time. Not (In 
my opinion) because it meant to, but because it happened to check the 
type of r.save against a type (namely, that .save returns its own type).


At the same time, I fixed all the isXXXRange traits so @property is not 
required anywhere. In particular, isRandomAccessRange required r.front 
to be @property, even when isInputRange didn't (again, IMO 
unintentionally). Here is the PR: https://github.com/dlang/phobos/pull/3276


-Steve

[Issue 16045] New: Unable to loading global variables in inline assembly with -fPIC

[via Digitalmars-d-bugs]

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

  Issue ID: 16045
   Summary: Unable to loading global variables in inline assembly
with -fPIC
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

Consider the following source file `asm_pic.d`:

align(16) static immutable short[8] A = [ 1, 1, 1, 1, 3, 3, 3, 3 ];

void main()
{
asm
{ 
pmullw XMM0, A;
}
}

LDC 1.0.0-b1 thinks it's compatible with PIC code.

```bash
$ ldc2 asm_pic.d # ok
$ ldc2 -relocation-model=pic asm_pic.d # ok
```

DMD disallows to load the constant in PIC code.


$ dmd asm_pic.d  # ok
$ dmd -fPIC asm_pic.d  # fail
asm_pic.d(7): Error: cannot directly load global variable 'A' with PIC code

--