[Issue 16550] Generic SIMD shuffle for Mir

[via Digitalmars-d-bugs]

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

--- Comment #4 from Walter Bright  ---
I also cannot find any documentation on extractRe() and extractIm(). I googled
for "ldc extractre extractim" and there were no results.

--

[Issue 16550] Generic SIMD shuffle for Mir

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
The example does not compile with gdc.

--

A curated list of links related to D (github/awesome D)

[Picaud Vincent via Digitalmars-d-learn]

Maybe interesting (hoping it is not too redundant with the links 
here)


https://github.com/zhaopuming/awesome-d

Vincent

Re: D Lang installation on Windows, dependency on Visual Studio?

[Daniel Kozak via Digitalmars-d]

Dne 16.11.2016 v 04:17 rikki cattermole via Digitalmars-d napsal(a):

On 16/11/2016 3:41 AM, Daniel Kozak via Digitalmars-d wrote:

Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):


On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:

Are there plans to write a homebrew 64-bit linker for DMD?


There are already ld from mingw and lld from llvm team.


Why aren't they used and distributed in DMD for Windows by default?

If the tools mentioned above (LD and LLD) are available and usable on
Windows x64 instead of the ones provided in heavily bloated packages
by Microsoft, how come the DMD installer for Windows doesn't offer
them as an alternative (or better yet as the default)?


AFAIK ld on mingw can`t link against mscoff file format so it is not
very usable. LLD is quite new so I do not know how production ready is.
But I believe LLD will be the answer in future.



From what I've read about LLD (~ 6+ months ago) the Windows 
implementation was a complete rewrite from the Linux support.
It most definitely isn't production ready or we would have heard about 
it (after all e.g. OSX will want to shift over to it).

http://www.phoronix.com/scan.php?page=news_item=LLVM-LD-Linker-Default-Discuss
But I guess they are speaking about linux, freebsd and maybe OSX

[Issue 16558] [Mir] Generic unaligned load/store like (like LDC loadUnaligned and storeUnaligned)

[via Digitalmars-d-bugs]

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

--- Comment #9 from Walter Bright  ---
https://github.com/dlang/druntime/pull/1693

--

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

[xtreak via Digitalmars-d-announce]

On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu 
wrote:
Please join us at DConf 2017, the conference of the D 
programming language in Berlin, Germany, May 4-6 2017.


We're happy to announce that the D Language Foundation is 
cooperating again with Sociomantic to organize DConf 2017 in 
Berlin for the second time. Same location, same dates, but of 
course a whole new experience!


The D programming language has improved dramatically this year 
thanks to more focus brought up by the D Language Foundation, 
better participation from corporate users and worldwide 
volunteers, and the advent of world-class open-source libraries 
such as Sociomantic's Tsunami and Ilya Yaroshenko's GLAS. The D 
Language Foundation has accumulated a war chest and announced a 
scholarship that already enrolls four MSc students.


DConf is the main face-to-face event for everyone and 
everything related to the D language and environment. The 2017 
edition will be held in Europe for the second time, following 
last year's smashing success. Which, of course, we plan to 
smash again!


Call for Submissions

We are looking forward to your submission for a paper, talk, 
demo, panel, or research report (new!) for DConf 2017. The 
topics of choice are anything and everything related to the D 
language. For more details, check the conference page:


http://dconf.org/2017/index.html


Great news!

A couple of js, svg and png files are missing. I tried to raise 
an issue in dconf.org at Github but it seems issues are disabled. 
I tried force reload on Mac OSX Chrome but the issue persists. 
Hope someone can verify the issue. Seems it could not be reported 
at issues.dlang.org.


Hope dlang.org could also be updated with the news. Filed an 
issue at https://issues.dlang.org/show_bug.cgi?id=16693


Thanks!

[Issue 16693] New: Update DConf 2017 announcement on dlang.org

[via Digitalmars-d-bugs]

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

  Issue ID: 16693
   Summary: Update DConf 2017 announcement on dlang.org
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: tir.kar...@gmail.com

The current page contains an announcement related DConf 2016 closure. Since
DConf 2017 is announced it could be updated to spread the news.

--

Re: D Lang installation on Windows, dependency on Visual Studio?

[rikki cattermole via Digitalmars-d]

On 16/11/2016 4:58 PM, Jerry wrote:

On Tuesday, 15 November 2016 at 23:34:34 UTC, Jonathan M Davis wrote:

On Tuesday, November 15, 2016 16:20:53 AB via Digitalmars-d wrote:

On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
> It's not just the linker. You need the libs as well (static > and
dynamic ones), and not just the WinSDK ones, but the > MSVCRT ones too.

I was under the impression that DMD for Windows was (meant to be)
self-sufficient. I must have been misled by how it can build 32-bit
applications just fine without requiring the many gigabytes of WinSDK
and MSVCRT extras.


You _can_ build 32-bit applications with dmd without the Microsoft
toolchain just fine. dmc and optlink should be installed with the dmd
installer so that code can be compiled to 32-bit OMF and linked. You
just need the Microsoft toolchain if you're compiling for 64-bit
(which is only COFF) or if you want to compile to 32-bit COFF. It's
unnecessary if you simply want to compile and run 32-bit programs and
are willing to use OMF for the linker format. If dmd's installer is
actually requiring that you install Visual Studio to compile 32-bit
programs, then that's a problem. It didn't do that before, and it
shouldn't need to now.

- Jonathan M Davis


That's not a good enough reason to keep using it, compared to all the
reasons for it's removal. Optlink is old and bug ridden, switching to
Microsoft's linker solved a bunch of misc problems I was having with D
(unable to debug cause of constant crashing, mismanagement of resources
like std file handles, etc...). There is no 64-bit equivalent, so you
are using two different linkers, when you can simply unify it to have
one. It isn't compatible with the standard format of the host OS. Most
software uses 64-bit, some not even bothering with 32-bit applications.
Having Visual Studio is already pretty much a requirement, if you want
64-bit (which is probably most people). Adding Visual Studio build tools
in some way to the installer will ease the setup process for people that
want 64-bit.

I'm for removing it completely, if not, then at the very least don't
make it the default and add a switch instead.


And then we'll get complaints that they need another big download just 
to compile basic 32bit programs... This whole argument about making 
changes is rediculas.


Unless we get explicit permission from Microsoft to distribute the parts 
we needs, I think it is safe to say that Optlink stays, in fact  nothing 
will change.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Jerry via Digitalmars-d]

On Tuesday, 15 November 2016 at 23:34:34 UTC, Jonathan M Davis 
wrote:
On Tuesday, November 15, 2016 16:20:53 AB via Digitalmars-d 
wrote:

On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
> It's not just the linker. You need the libs as well (static 
> and dynamic ones), and not just the WinSDK ones, but the 
> MSVCRT ones too.


I was under the impression that DMD for Windows was (meant to 
be) self-sufficient. I must have been misled by how it can 
build 32-bit applications just fine without requiring the many 
gigabytes of WinSDK and MSVCRT extras.


You _can_ build 32-bit applications with dmd without the 
Microsoft toolchain just fine. dmc and optlink should be 
installed with the dmd installer so that code can be compiled 
to 32-bit OMF and linked. You just need the Microsoft toolchain 
if you're compiling for 64-bit (which is only COFF) or if you 
want to compile to 32-bit COFF. It's unnecessary if you simply 
want to compile and run 32-bit programs and are willing to use 
OMF for the linker format. If dmd's installer is actually 
requiring that you install Visual Studio to compile 32-bit 
programs, then that's a problem. It didn't do that before, and 
it shouldn't need to now.


- Jonathan M Davis


That's not a good enough reason to keep using it, compared to all 
the reasons for it's removal. Optlink is old and bug ridden, 
switching to Microsoft's linker solved a bunch of misc problems I 
was having with D (unable to debug cause of constant crashing, 
mismanagement of resources like std file handles, etc...). There 
is no 64-bit equivalent, so you are using two different linkers, 
when you can simply unify it to have one. It isn't compatible 
with the standard format of the host OS. Most software uses 
64-bit, some not even bothering with 32-bit applications. Having 
Visual Studio is already pretty much a requirement, if you want 
64-bit (which is probably most people). Adding Visual Studio 
build tools in some way to the installer will ease the setup 
process for people that want 64-bit.


I'm for removing it completely, if not, then at the very least 
don't make it the default and add a switch instead.

[Issue 16692] New: New debug experience: possible to execute pure functions during expression evaluation?

[via Digitalmars-d-bugs]

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

  Issue ID: 16692
   Summary: New debug experience: possible to execute pure
functions during expression evaluation?
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

Is it possible to execute 'pure' functions during expression evaluation?
Being able to hover over properties for instance would be SOOO helpful.

Debug engine would need to be able to evaluate any function arguments, and then
produce a function call using those evaluated arguments, result folds back into
expression evaluation...

--

[Issue 16691] New: New debug experience: hovering over a string function argument doesn't display the string

[via Digitalmars-d-bugs]

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

  Issue ID: 16691
   Summary: New debug experience: hovering over a string function
argument doesn't display the string
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

string f(string s)
{
  return s;
}


Put a breakpoint at "return s;", hover the mouse over 's', you'll see a pointer
appear which you need to expand to see the string.
It would be best if hovering over a string showed the string directly.

--

Re: D Lang installation on Windows, dependency on Visual Studio?

[rikki cattermole via Digitalmars-d]

On 16/11/2016 3:41 AM, Daniel Kozak via Digitalmars-d wrote:

Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):


On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:

Are there plans to write a homebrew 64-bit linker for DMD?


There are already ld from mingw and lld from llvm team.


Why aren't they used and distributed in DMD for Windows by default?

If the tools mentioned above (LD and LLD) are available and usable on
Windows x64 instead of the ones provided in heavily bloated packages
by Microsoft, how come the DMD installer for Windows doesn't offer
them as an alternative (or better yet as the default)?


AFAIK ld on mingw can`t link against mscoff file format so it is not
very usable. LLD is quite new so I do not know how production ready is.
But I believe LLD will be the answer in future.



From what I've read about LLD (~ 6+ months ago) the Windows 
implementation was a complete rewrite from the Linux support.
It most definitely isn't production ready or we would have heard about 
it (after all e.g. OSX will want to shift over to it).

Unable To Install Debian Package on Deepin Linux (Debian Jessie)

[azzuwan via Digitalmars-d-learn]

It seems that /usr/bin/dman is currently used by  deepin-manual. 
Is there anyway to get around this?


Link to the screenshot:
https://1drv.ms/i/s!AtF769jLRRhO61Of6g3ZIBl8uZAk

[Issue 16690] New: New debug experience: "Children could not be evaluated" popup with zero length slices (ie, null ptr)

[via Digitalmars-d-bugs]

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

  Issue ID: 16690
   Summary: New debug experience: "Children could not be
evaluated" popup with zero length slices (ie, null
ptr)
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

null slices show "Children could not be evaluated" when hovering.
It would be nice if the normal expansion worked, but it was empty instead (no
children listed). The error message leads you to think something is wrong; bad
pointer or something. (yes, null *is* a bad pointer, but if length == 0, any
pointer should be accepted without producing the error)
Same story for null strings obviously.

--

Re: PDF generation in D?

[Jot via Digitalmars-d]

On Tuesday, 15 November 2016 at 15:23:29 UTC, Adrian Matoga wrote:

On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote:
On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga 
wrote:
On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner 
Schadek wrote:
I used text files and LaTeX in the past, it works with 
everything


textfile -> process -> LaTeX -> pdf


This.

Another (a bit lower-level) option would be to produce a 
PostScript file and pass it to (e)ps2pdf.



Then that begs the question about how to generate ps in D and 
just kicks the can down the road.


PostScript is a programming language and PS files are plain 
text files with programs written in it, so formatted file 
output is your friend here.


"Lower-level" means that you need to take care of the layout of 
items on a page manually, using physical positions. It's quite 
straightforward for simple vector graphics, but not so much for 
multi-page text documents with figures and tables.


What's your point?

"PDF is largely based on PostScript but simplified to remove flow 
control features like these, while graphics commands such as 
lineto remain.


As a document format, PDF has several advantages over PostScript:

PDF contains tokenized and interpreted results of the 
PostScript source code, for direct correspondence between changes 
to items in the PDF page description and changes to the resulting 
page appearance.
PDF (from version 1.4) supports true graphic transparency; 
PostScript does not.
PostScript is an interpreted programming language with an 
implicit global state, so instructions accompanying the 
description of one page can affect the appearance of any 
following page. Therefore, all preceding pages in a PostScript 
document must be processed to determine the correct appearance of 
a given page, whereas each page in a PDF document is unaffected 
by the others. As a result, PDF viewers allow the user to quickly 
jump to the final pages of a long document, whereas a PostScript 
viewer needs to process all pages sequentially before being able 
to display the destination page (unless the optional PostScript 
Document Structuring Conventions have been carefully complied 
with).

"

Re: PDF generation in D?

[lobo via Digitalmars-d]

On Tuesday, 15 November 2016 at 15:23:29 UTC, Adrian Matoga wrote:

On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote:
On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga 
wrote:
On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner 
Schadek wrote:
I used text files and LaTeX in the past, it works with 
everything


textfile -> process -> LaTeX -> pdf


This.

Another (a bit lower-level) option would be to produce a 
PostScript file and pass it to (e)ps2pdf.



Then that begs the question about how to generate ps in D and 
just kicks the can down the road.


PostScript is a programming language and PS files are plain 
text files with programs written in it, so formatted file 
output is your friend here.


"Lower-level" means that you need to take care of the layout of 
items on a page manually, using physical positions. It's quite 
straightforward for simple vector graphics, but not so much for 
multi-page text documents with figures and tables.


Cairo can render to a postscript surface and PDF surface[1]. 
Maybe there is something in gtkd that suits your needs[2]?


[1] https://www.cairographics.org/manual/cairo-PDF-Surfaces.html
[2] http://gtkd.org/

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 22:50:49 UTC, deadalnix wrote:

On Tuesday, 15 November 2016 at 01:35:42 UTC, Stefan Koch wrote:
However there is a a bug inside the code that does 
bounds-checking for array assignment.
In rare cases it can trigger a out-bounds-error on newly 
created arrays.




This raise all kind of red flags to me. What are the design 
decision that lead to this ?


I am still figuring out when and why the bug is caused.
The Byte-code for slice allocation is rather complex.
Because it has to deal with resizing slices as well.
I suspect that somewhere the heapPtr is not bumped or the length 
is not set correctly.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, November 15, 2016 16:20:53 AB via Digitalmars-d wrote:
> On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
> > It's not just the linker. You need the libs as well (static and
> > dynamic ones), and not just the WinSDK ones, but the MSVCRT
> > ones too.
>
> I was under the impression that DMD for Windows was (meant to be)
> self-sufficient. I must have been misled by how it can build
> 32-bit applications just fine without requiring the many
> gigabytes of WinSDK and MSVCRT extras.

You _can_ build 32-bit applications with dmd without the Microsoft toolchain
just fine. dmc and optlink should be installed with the dmd installer so
that code can be compiled to 32-bit OMF and linked. You just need the
Microsoft toolchain if you're compiling for 64-bit (which is only COFF) or
if you want to compile to 32-bit COFF. It's unnecessary if you simply want
to compile and run 32-bit programs and are willing to use OMF for the linker
format. If dmd's installer is actually requiring that you install Visual
Studio to compile 32-bit programs, then that's a problem. It didn't do that
before, and it shouldn't need to now.

- Jonathan M Davis

Re: CTFE Status

[deadalnix via Digitalmars-d]

On Tuesday, 15 November 2016 at 01:35:42 UTC, Stefan Koch wrote:
However there is a a bug inside the code that does 
bounds-checking for array assignment.
In rare cases it can trigger a out-bounds-error on newly 
created arrays.




This raise all kind of red flags to me. What are the design 
decision that lead to this ?

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 15 November 2016 at 19:02:29 UTC, Bastiaan Veelo 
wrote:
Nice, Stefan. I always come back to this thread to see your 
progress. Thanks for making it easy to follow it.


I agree.

Re: send doesn't work

[Steven Schveighoffer via Digitalmars-d]

On 11/15/16 1:56 PM, unDEFER wrote:

On Tuesday, 15 November 2016 at 18:23:16 UTC, Steven Schveighoffer wrote:

1. I'm sure it's not "magic" but likely something you are missing.
2. Nobody here can help you without a working demonstration. i.e.,
this isn't a known issue, and others have used the concurrency
subsystem without such problems.

If you construct a small example that demonstrates the problem, that
is helpful for diagnosis (or better yet, may demonstrate to you why
it's not working in your full codebase).


So, the problem still here. Sometimes it is working with hello-messages,
but sometimes doesn't work.
I will try to make minimal application. But I don't know still what it
must do. Trying to minimize the main thread to starter of the second
thread shows that the problems goes away..
So it will really not easy, but I will try...
Thank you.


From experience, this smells like a race condition. I'd try removing 
features of your program until it starts working, then you may have your 
answer.


I'd suggest dustmite may help, but in the case of non-deterministic 
failure, it's more difficult to have it work.


-Steve

Re: an extremely naive question regarding synchronized...

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/15/16 3:05 PM, Kapps wrote:



Keep in mind, this is only slow for such a large amount of calls.
If you're calling this only a hundred times a second, then who cares if
it's slower. After all, with GDC we were looking at 1 billion calls in
21 seconds. That's 47,000 calls per *millisecond*.


This is the wrong way to look at it.

If you are calling it from one thread, then 100 times/second is no 
problem. If you have 100 threads calling it 100 times a second, you have 
killed any performance gained by using threads in the first place.


The reason lock-free singletons are so attractive is because of the 
allowance of multiple threads to use it at the same time without 
contention. It's why years of "slightly wrong" advice on singletons has 
been out there, and why this solution is so amazing in its simplicity.


-Steve

Re: an extremely naive question regarding synchronized...

[Kapps via Digitalmars-d-learn]

On Monday, 14 November 2016 at 17:43:37 UTC, WhatMeWorry wrote:


I was reading this fasciniating article:

https://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/

And to quote a section of it:
-
static MySingleton get() {
synchronized {
  if (instance_ is null) {
instance_ = new MySingleton;
  }
}
return instance_;
  }

Now, if Thread 1 calls get(), it has a chance to finish 
instantiating instance_ and storing a reference to it before 
Thread 2 checks whether instance_ is null.  There’s only one 
problem with this:  It comes at a huge performance cost 
(benchmarks forthcoming).  Entering a synchronized block is 
expensive.

-

Why is the synchronized block so expensive?  Isn't it just 
doing one conditional and a new command?  Again, to my naive 
way of thinking, this seems like a very small blocking window.


And the graph shows 1B get() calls.  I assume B stands for 
billion.  What use case would require so many gets?


Thanks.


Keep in mind, this is only slow for such a large amount of calls.
If you're calling this only a hundred times a second, then who 
cares if it's slower. After all, with GDC we were looking at 1 
billion calls in 21 seconds. That's 47,000 calls per 
*millisecond*.

Re: CTFE Status

[Bastiaan Veelo via Digitalmars-d]

On Tuesday, 15 November 2016 at 01:35:42 UTC, Stefan Koch wrote:
Two more bullet points cross the border from unsupported to 
supported.


Nice, Stefan. I always come back to this thread to see your 
progress. Thanks for making it easy to follow it.

Re: send doesn't work

[unDEFER via Digitalmars-d]

On Tuesday, 15 November 2016 at 18:23:16 UTC, Steven 
Schveighoffer wrote:
1. I'm sure it's not "magic" but likely something you are 
missing.
2. Nobody here can help you without a working demonstration. 
i.e., this isn't a known issue, and others have used the 
concurrency subsystem without such problems.


If you construct a small example that demonstrates the problem, 
that is helpful for diagnosis (or better yet, may demonstrate 
to you why it's not working in your full codebase).


-Steve


So, the problem still here. Sometimes it is working with 
hello-messages, but sometimes doesn't work.
I will try to make minimal application. But I don't know still 
what it must do. Trying to minimize the main thread to starter of 
the second thread shows that the problems goes away..

So it will really not easy, but I will try...
Thank you.

[Issue 4577] Third way to create a std.typecons.Tuple

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

Re: send doesn't work

[Steven Schveighoffer via Digitalmars-d]

On 11/15/16 1:13 PM, unDEFER wrote:

Now I'm sending "hello"-message from child thread in the loop every
iteration, and the last message again working.
What the magic??? The send-subsystem "becomes rotten" if don't use it???


1. I'm sure it's not "magic" but likely something you are missing.
2. Nobody here can help you without a working demonstration. i.e., this 
isn't a known issue, and others have used the concurrency subsystem 
without such problems.


If you construct a small example that demonstrates the problem, that is 
helpful for diagnosis (or better yet, may demonstrate to you why it's 
not working in your full codebase).


-Steve

Re: send doesn't work

[unDEFER via Digitalmars-d]

On Tuesday, 15 November 2016 at 18:11:38 UTC, Daniel Kozak wrote:

Yous should post this into Learn news group not in General. And 
it would be better if you provided full (not)working example.


If the problem will appears again I will try to make short not 
working example..



and I guess you have this

receiveTimeout( dur!"hnsecs"(1),
(Tid tid)
{//the message from child thread handler} );

in some while(true) loop?


Of course there is while(!gs.finish) :-)

Re: Intresa in Static Analysis for D ?

[Basile B. via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:57:44 UTC, Basile B. wrote:

On Tuesday, 15 November 2016 at 16:53:42 UTC, Stefan Koch wrote:

On Tuesday, 15 November 2016 at 16:50:47 UTC, Basile B. wrote:


p you dont get the point.
The point is when an IDE message leads you to this:
http://imgur.com/a/6zLHU


I really don't get it.
What is actionable about that metric ?


The Halstead complexity is able to detect the functions that 
need more unit test and more reviews.


Like shown here:

https://www.youtube.com/watch?v=_asYu0f38ks=False#t=6.543481

;)

Re: send doesn't work

[unDEFER via Digitalmars-d]

On Tuesday, 15 November 2016 at 18:12:32 UTC, Steven 
Schveighoffer wrote:
Without more complete code, it's difficult to say what is 
happening.


-Steve


Code is big. I of course can return to the question when the code 
will available on the git. But now it is not available.

Re: send doesn't work

[unDEFER via Digitalmars-d]

Now I'm sending "hello"-message from child thread in the loop 
every iteration, and the last message again working.
What the magic??? The send-subsystem "becomes rotten" if don't 
use it???

Re: send doesn't work

[Steven Schveighoffer via Digitalmars-d]

On 11/15/16 11:36 AM, unDEFER wrote:

Hello!
In my thread I'm sending the Tid of the thread to the parent to inform
it about finishing:
send(tid, thisTid);

The parent thread has the next code to receive it and handle:
receiveTimeout( dur!"hnsecs"(1),
(Tid tid)
{//the message from child thread handler} );

It is good works for my first child thread.
But, some times ago I have added the second child thread (no, no, the
first thread and the second thread works not simultaneously) and have
found that the receiving message doesn't work! The parent doesn't get
the message although the child sends it.
So in my code have appeared the next insertion in the start of thread:
/* Strange, but without sending message
   at start thread makes not working
   sending at end thread */
send(tid, "Hello");

Now I have added the third child thread. At the first it have worked
good, but now it again doesn't receive the message. And "send
hello"-hack doesn't help.
What to do? Why the sending of the message may doesn't work?


Without more complete code, it's difficult to say what is happening.

-Steve

Re: send doesn't work

[Daniel Kozak via Digitalmars-d]

Dne 15.11.2016 v 17:36 unDEFER via Digitalmars-d napsal(a):


Hello!
In my thread I'm sending the Tid of the thread to the parent to inform 
it about finishing:

send(tid, thisTid);

The parent thread has the next code to receive it and handle:
receiveTimeout( dur!"hnsecs"(1),
(Tid tid)
{//the message from child thread handler} );

It is good works for my first child thread.
But, some times ago I have added the second child thread (no, no, the 
first thread and the second thread works not simultaneously) and have 
found that the receiving message doesn't work! The parent doesn't get 
the message although the child sends it.

So in my code have appeared the next insertion in the start of thread:
/* Strange, but without sending message
   at start thread makes not working
   sending at end thread */
send(tid, "Hello");

Now I have added the third child thread. At the first it have worked 
good, but now it again doesn't receive the message. And "send 
hello"-hack doesn't help.

What to do? Why the sending of the message may doesn't work?
Yous should post this into Learn news group not in General. And it would 
be better if you provided full (not)working example.


and I guess you have this

receiveTimeout( dur!"hnsecs"(1),
(Tid tid)
{//the message from child thread handler} );

in some while(true) loop?

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 15 November 2016 at 17:31:04 UTC, Nick Sabalausky 
wrote:
I don't really use emacs, and (thought I admit I'm not 100% 
certain), I don't think much of what I use launches (or at 
least needs to launch) separate commands for each keypress 
(sounds like bad software engineering to me, but that's just my 
gut impression, maybe I'm wrong).


As the threshold of what performance is acceptable rises, so do 
the possibilities. Things that sounded like bad engineering years 
ago can be considered perfectly acceptable today (e.g. why go 
through the effort of integrating something by writing a library 
and inventing an API, if you can just spawn processes for every 
operation at negligible cost, and greatly lower development and 
maintenance effort). Granted, certainly not everything will 
benefit from I/O performance, but a lot of things do.


That does remind me though: Are hybrid drives still a thing? 
They sounded like a good idea (at least for laptops, where you 
can usually only have one internal drive),


Ah, I missed that you were talking in the context of a laptop. 
One thing to note is that as optical disk drives become less 
useful, dual-HDD laptops are more common. I've also seen some 
models (ThinkPads, IIRC?) with a small amount of on-board flash 
memory that can be used as a cache. Caching with two drives can 
also be done in software (bcache/lvmcache), though if you have 
two drives, IMO it's simpler to separate the data yourself.

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/15/2016 03:33 AM, Vladimir Panteleev wrote:

On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:

the ONLY time I ever have speed issues


"Speed issues" is one thing. Having most operations be INSTANT is
another. It MASSIVELY transforms your workflow; UIs where each key press
launches a command (e.g. magit, background builds...) become sensible
and usable "blindly", and can easily multiply productivity by an order
of magnitude.

If you don't have an SSD in your work machine (but can afford one), you
simply don't value your time.



I don't really use emacs, and (thought I admit I'm not 100% certain), I 
don't think much of what I use launches (or at least needs to launch) 
separate commands for each keypress (sounds like bad software 
engineering to me, but that's just my gut impression, maybe I'm wrong).


That does remind me though: Are hybrid drives still a thing? They 
sounded like a good idea (at least for laptops, where you can usually 
only have one internal drive), but I seem to remember hearing that they 
tended to have reliability problems. Has that been sorted out, or have 
the hybrids just gone away entirely?

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 15 November 2016 at 17:23:56 UTC, Nick Sabalausky 
wrote:

I mean "too small at reasonable prices".


If you keep your photos/movies/music/backups/installers/etc. on 
spinning rust (where they belong), and aren't living in poverty, 
it's not. A 250GB Samsung 850 EVO is under $100, which is less 
than most other PC components.

Re: GitHub now supports editing the target branch for PR

[Nick Sabalausky via Digitalmars-d]

On 11/15/2016 06:33 AM, Dicebot wrote:

On 11/12/2016 12:34 PM, Sönke Ludwig wrote:

Not sure if this is common knowledge already, but it was new for me. If
you click the edit button at the top of a pull request on GitHub, you
now get a drop down to change the base branch to which the request will
be pulled. Really handy for PRs that should be targeted at a stable
branch, but instead target master.


I think I have sent 3 or 4 support request to GitHub asking about it and
finally it arrives! :) Makes even bigger difference if one has to
maintain multiple version branches as opposed to plain stable/master.



This should be really nice to have for Deimos. Back when I had submitted 
something to Deimos, the way the whole project is set up, I found the 
whole process to be borderline unworkable - purely because GitHub 
provided no way to target any branch other than master.

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/15/2016 03:33 AM, Vladimir Panteleev wrote:

On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:

SSDs are still far too small.


Hmm...

http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/



I mean "too small at reasonable prices". A $10k SSD doesn't really count.

Re: interest in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:59:49 UTC, Dicebot wrote:

On 11/15/2016 06:46 PM, Stefan Koch wrote:

On Tuesday, 15 November 2016 at 16:39:22 UTC, Dicebot wrote:

[  ]
But I'd sincerely advise against any ad-hoc solution that is 
built

into DMD itself.


It seems I did not clearly state this.
I mean to provide the general plumbing that is needed for the 
dmd-fe,

to utilize it for static analysis.
I do not intend to cram all sorts of checking functionality 
inside the

compiler.


When doing so, try to forget that static analysis is the 
intended goal. It has to be naturally usable for any other 
purpose too, focusing on one specific application case is 
likely only harm design decisions.


It's a compiler frontend.
I cannot see any other purposes then code-analysis and 
code-transformation.
Regarding Transformations I wanted to write a good D 
transformation tool for years now.

Re: The return of std.algorithm.find

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/15/16 4:43 AM, RazvanN wrote:

The find function which receives an input haystack and a needle returns
the haystack advanced to the first occurrence of the needle. For normal
ranges this is fine, but for
sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This
is in terms with the general policy of the find function, but is weird.
Since we know the range is sorted, shouldn't the result be [1, 2, 4]?


A sorted range provides better mechanisms to find values as members of 
SortedRange. Don't use find(assumeSorted(...)), as it's still a linear 
search.


-Steve

Re: interest in Static Analysis for D ?

[Dicebot via Digitalmars-d]

On 11/15/2016 06:46 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 16:39:22 UTC, Dicebot wrote:
>> [  ]
>> But I'd sincerely advise against any ad-hoc solution that is built
>> into DMD itself.
> 
> It seems I did not clearly state this.
> I mean to provide the general plumbing that is needed for the dmd-fe,
> to utilize it for static analysis.
> I do not intend to cram all sorts of checking functionality inside the
> compiler.

When doing so, try to forget that static analysis is the intended goal.
It has to be naturally usable for any other purpose too, focusing on one
specific application case is likely only harm design decisions.



signature.asc
Description: OpenPGP digital signature

Re: Intresa in Static Analysis for D ?

[Basile B. via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:53:42 UTC, Stefan Koch wrote:

On Tuesday, 15 November 2016 at 16:50:47 UTC, Basile B. wrote:


p you dont get the point.
The point is when an IDE message leads you to this:
http://imgur.com/a/6zLHU


I really don't get it.
What is actionable about that metric ?


The Halstead complexity is able to detect the functions that need 
more unit test and more reviews.

Re: Intresa in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:50:47 UTC, Basile B. wrote:


p you dont get the point.
The point is when an IDE message leads you to this:
http://imgur.com/a/6zLHU


I really don't get it.
What is actionable about that metric ?

Re: Intresa in Static Analysis for D ?

[Basile B. via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:38:39 UTC, Stefan Koch wrote:

On Tuesday, 15 November 2016 at 16:28:30 UTC, Basile B. wrote:
On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch 
wrote:

Hi Guys,

I was wondering how much interest in static analysis exists 
in this community .

DMD already has rudimentary support for these kinds of things.


cyclic complexity
NPath complexity
Halstead complexity

3 nice fields of static analysis.

I'm currently working on Halstead 
(https://github.com/BBasile/Coedit/blob/master/dastworx/src/halstead.d)


The Halstead metric (1977) is often considered as ratio of the 
number of line code, while it's actually not at all. The 
Halstead is based on the operations and the operations 
arguments. You can have small functions using a lot of 
operands that will be bug prone. You can have huge functions 
with very few operands used and that are not bug prone. The 
Halstead metric can detect them. It can tell you: "take care 
of this function".


;]


I think you mixed up Pow and Xor.

You will probably want to change from a AA to a normal array 
and just assign a numeric index to each expression you care 
about :)


p you dont get the point.
The point is when an IDE message leads you to this:
http://imgur.com/a/6zLHU

Re: interest in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:39:22 UTC, Dicebot wrote:

[  ]
But I'd sincerely advise against any ad-hoc solution that is 
built into DMD itself.


It seems I did not clearly state this.
I mean to provide the general plumbing that is needed for the 
dmd-fe,

to utilize it for static analysis.
I do not intend to cram all sorts of checking functionality 
inside the compiler.


Though what I am planning will also make it easier to extend the 
optimizer inside dmd, and improve it's efficiency.

Re: D Lang installation on Windows, dependency on Visual Studio?

[kink via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:20:53 UTC, AB wrote:

On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
It's not just the linker. You need the libs as well (static 
and dynamic ones), and not just the WinSDK ones, but the 
MSVCRT ones too.


I was under the impression that DMD for Windows was (meant to 
be) self-sufficient. I must have been misled by how it can 
build 32-bit applications just fine without requiring the many 
gigabytes of WinSDK and MSVCRT extras.


Did you give the Build Tools even a try? I can't install it as 
it's not installable alongside VS (yes, I do have enough disk 
space for 3 parallel VS installations!). The system requirements 
on their site says it needs 200 MB.


Also, DMD ships with the most common Windows libs (no idea from 
which WinSDK though), and DMD for 32-bit Windows (the non-COFF, 
i.e., optlink flavour) uses the Digital Mars C runtime (for which 
there's obviously no 64-bit version).


The 32-bit non-COFF Windows DMD comes along as self-sufficient 
package for basic users. If you're one of them, fine, otherwise 
get a proper dev environment and acknowledge that it'll require 
some space on disk.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Rene Zwanenburg via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:20:53 UTC, AB wrote:
Hopefully, future releases of DMD will fix this inconsistency 
by requiring Visual Studio for 32-bit D programs as well.


You already do, if you compile with -m32mscoff.

Re: interest in Static Analysis for D ?

[Dicebot via Digitalmars-d]

On 11/15/2016 04:57 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I was wondering how much interest in static analysis exists in this
>> community .
>> DMD already has rudimentary support for these kinds of things.

I'd put it in a different perspective - we desperately need DMD FE (with
all semantic phases) available as fully-stand alone independent library.
For example, there is already DScanner
(https://github.com/Hackerpilot/Dscanner) for static analysis but amount
of things one can check with only lexer/parser is very limited in D.

Once we have such library, it opens up world of many useful tools -
separating all warnings into dedicated static analysis tool, providing
automatic project upgrade scripts which work reliably, visualize mixin
expansions and so on.

But I'd sincerely advise against any ad-hoc solution that is built into
DMD itself.



signature.asc
Description: OpenPGP digital signature

Re: Intresa in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:28:30 UTC, Basile B. wrote:

On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:

Hi Guys,

I was wondering how much interest in static analysis exists in 
this community .

DMD already has rudimentary support for these kinds of things.


cyclic complexity
NPath complexity
Halstead complexity

3 nice fields of static analysis.

I'm currently working on Halstead 
(https://github.com/BBasile/Coedit/blob/master/dastworx/src/halstead.d)


The Halstead metric (1977) is often considered as ratio of the 
number of line code, while it's actually not at all. The 
Halstead is based on the operations and the operations 
arguments. You can have small functions using a lot of operands 
that will be bug prone. You can have huge functions with very 
few operands used and that are not bug prone. The Halstead 
metric can detect them. It can tell you: "take care of this 
function".


;]


I think you mixed up Pow and Xor.

You will probably want to change from a AA to a normal array and 
just assign a numeric index to each expression you care about :)

send doesn't work

[unDEFER via Digitalmars-d]

Hello!
In my thread I'm sending the Tid of the thread to the parent to 
inform it about finishing:

send(tid, thisTid);

The parent thread has the next code to receive it and handle:
receiveTimeout( dur!"hnsecs"(1),
(Tid tid)
{//the message from child thread handler} );

It is good works for my first child thread.
But, some times ago I have added the second child thread (no, no, 
the first thread and the second thread works not simultaneously) 
and have found that the receiving message doesn't work! The 
parent doesn't get the message although the child sends it.
So in my code have appeared the next insertion in the start of 
thread:

/* Strange, but without sending message
   at start thread makes not working
   sending at end thread */
send(tid, "Hello");

Now I have added the third child thread. At the first it have 
worked good, but now it again doesn't receive the message. And 
"send hello"-hack doesn't help.

What to do? Why the sending of the message may doesn't work?

Re: Intresa in Static Analysis for D ?

[Basile B. via Digitalmars-d]

On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:

Hi Guys,

I was wondering how much interest in static analysis exists in 
this community .

DMD already has rudimentary support for these kinds of things.


cyclic complexity
NPath complexity
Halstead complexity

3 nice fields of static analysis.

I'm currently working on Halstead 
(https://github.com/BBasile/Coedit/blob/master/dastworx/src/halstead.d)


The Halstead metric (1977) is often considered as ratio of the 
number of line code, while it's actually not at all. The Halstead 
is based on the operations and the operations arguments. You can 
have small functions using a lot of operands that will be bug 
prone. You can have huge functions with very few operands used 
and that are not bug prone. The Halstead metric can detect them. 
It can tell you: "take care of this function".


;]

Re: D Lang installation on Windows, dependency on Visual Studio?

[AB via Digitalmars-d]

On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
It's not just the linker. You need the libs as well (static and 
dynamic ones), and not just the WinSDK ones, but the MSVCRT 
ones too.


I was under the impression that DMD for Windows was (meant to be) 
self-sufficient. I must have been misled by how it can build 
32-bit applications just fine without requiring the many 
gigabytes of WinSDK and MSVCRT extras.


Hopefully, future releases of DMD will fix this inconsistency by 
requiring Visual Studio for 32-bit D programs as well.

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

[Andrei Alexandrescu via Digitalmars-d-announce]

On 11/15/16 5:51 AM, Adrian Matoga wrote:

On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu wrote:

We're happy to announce that the D Language Foundation is cooperating
again with Sociomantic to organize DConf 2017 in Berlin for the second
time. Same location, same dates, but of course a whole new experience!
(...)
http://dconf.org/2017/index.html


It would be less confusing if the dates were updated with more attention
than just s/2016/2017/g, as there's no February 29 in 2017, and all
others dates are on different days of week than in 2016.
Otherwise, excellent news.


Sorry. Fixed, thanks. -- Andrei

Re: interest in Static Analysis for D ?

[ketmar via Digitalmars-d]

On Tuesday, 15 November 2016 at 15:33:30 UTC, Stefan Koch wrote:

On Tuesday, 15 November 2016 at 15:28:14 UTC, ketmar wrote:

if it will be independent utility -- yes. dmdfe part -- no.


It would relay on the parser of the dmdfe, and parts of dmd's 
semantic analysis.


DMD will be much nicer to work with the facility envision.
As I see it there is little reason for writing yet another D 
parser.


the more features dmdfe will get, the slower (and more 
memory-hungry) it will become. so i don't want any fancy (and 
even useful ;-) features in dmd itself (that's what i meant when 
i wrote "dmdfe"). if it will be separate app based on dmdfe -- 
sure, it would be great!

Re: D Lang installation on Windows, dependency on Visual Studio?

[kink via Digitalmars-d]

On Tuesday, 15 November 2016 at 13:23:38 UTC, AB wrote:

On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:

Are there plans to write a homebrew 64-bit linker for DMD?


There are already ld from mingw and lld from llvm team.


Why aren't they used and distributed in DMD for Windows by 
default?


If the tools mentioned above (LD and LLD) are available and 
usable on Windows x64 instead of the ones provided in heavily 
bloated packages by Microsoft, how come the DMD installer for 
Windows doesn't offer them as an alternative (or better yet as 
the default)?


It's not just the linker. You need the libs as well (static and 
dynamic ones), and not just the WinSDK ones, but the MSVCRT ones 
too. Just use the Visual C++ Build Tools if there's not enough 
disk space in 2016 *cough*. IMO there's just no way of doing 
professional Windows development without the MS toolchain. And no 
reason to complain about it just because most Linux distros come 
with a fully fledged development ecosystem.

vibed ssl stream and SSL_CTX_set_default_verify_paths

[ikod via Digitalmars-d-learn]

Hello,

Sorry if this is FAQ, or any other way stupid question, e.t.c.

I have to configure vibe.d tlsstream to verify remote certificate.

Please correct me if I'm wrong -- here is part of my code to 
request certificate verification:


auto sslctx = createTLSContext(TLSContextKind.client);

sslctx.useTrustedCertificateFile("/opt/local/etc/openssl/cert.pem");

sslctx.peerValidationMode = TLSPeerValidationMode.trustedCert;
auto _stream = createTLSStream(_conn, sslctx, host);

the problem here is call to useTrustedCertificateFile. At compile 
time I do not know place of cert authority file, and this 
location can also be unknown for program user even if there is a 
way to configure it during program start.


libopenssl provide call SSL_CTX_set_default_verify_paths(ctx) - 
which configure default (already known to library code) location 
of ca certs distributed with openssl.


Is there any way for vibed sslctx to configure CA cert path "by 
default value"?


Thanks for your responce!

[Issue 16688] DMD needs to work with the MSC build tools distribution

[via Digitalmars-d-bugs]

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

--- Comment #1 from ki...@gmx.net ---
LDC already detects it. The registry keys to be looked into (supporting both VS
and the Build Tools alone) can be found here:
https://github.com/ldc-developers/ldc/blob/master/vcbuild/msvcEnv.bat

--

Re: The return of std.algorithm.find

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 15 November 2016 at 09:50:40 UTC, RazvanN wrote:

On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:
The find function which receives an input haystack and a 
needle returns the haystack advanced to the first occurrence 
of the needle. For normal ranges this is fine, but for

sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 
7]. This is in terms with the general policy of the find 
function, but is weird. Since we know the range is sorted, 
shouldn't the result be [1, 2, 4]?


The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 
6, 7]), 4). And the result is

the whole range [1, 2, 4, 5, 6, 7].


Are you sure you don't want filter ?

Re: interest in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 15:28:14 UTC, ketmar wrote:

if it will be independent utility -- yes. dmdfe part -- no.


It would relay on the parser of the dmdfe, and parts of dmd's 
semantic analysis.


DMD will be much nicer to work with the facility envision.
As I see it there is little reason for writing yet another D 
parser.

[Issue 4851] Three suggestions for std.random

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/783d15bfa0e55d753999e7cc38236763c6b95092
enhancement issue 4851: add choice function to std.random

https://github.com/dlang/phobos/commit/adb71a6c6b8e51680ce2337eb93c28fa7ea9a3fd
enhancement issue 4851: use assert in choice function

https://github.com/dlang/phobos/commit/6bc3a4f343ab653e85d11966a4b559da59c8
Merge pull request #4897 from edi33416/implement_choice

enhancement issue 4851: add choice function to std.random

--

Re: interest in Static Analysis for D ?

[ketmar via Digitalmars-d]

if it will be independent utility -- yes. dmdfe part -- no.

Re: PDF generation in D?

[Adrian Matoga via Digitalmars-d]

On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote:
On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga 
wrote:
On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner 
Schadek wrote:
I used text files and LaTeX in the past, it works with 
everything


textfile -> process -> LaTeX -> pdf


This.

Another (a bit lower-level) option would be to produce a 
PostScript file and pass it to (e)ps2pdf.



Then that begs the question about how to generate ps in D and 
just kicks the can down the road.


PostScript is a programming language and PS files are plain text 
files with programs written in it, so formatted file output is 
your friend here.


"Lower-level" means that you need to take care of the layout of 
items on a page manually, using physical positions. It's quite 
straightforward for simple vector graphics, but not so much for 
multi-page text documents with figures and tables.

[Issue 16689] New: Errors in instantiated mixin templates should show instantiation point

[via Digitalmars-d-bugs]

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

  Issue ID: 16689
   Summary: Errors in instantiated mixin templates should show
instantiation point
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: diagnostic
  Severity: enhancement
  Priority: P5
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

When an error occurs in an instantiated template, DMD will show where the
template was instantiated (in addition to the location of the error itself).
This does not happen for mixin templates, i.e.:

 test.d 
mixin template Foo()
{
static assert(false, "foo");
}

mixin Foo!();


$ dmd -o- test.d 
test.d(3): Error: static assert  "foo"

DMD should also mention line 6, where the mixin template was instantiated.

--

Re: interest in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:

Hi Guys,

I was wondering how much interest in static analysis exists in 
this community .

DMD already has rudimentary support for these kinds of things.


Whoops I accidentally pressed enter too soon.

I am currently working on extending the existing support a little 
because the new CTFE engine really profits form having more 
information up-front.


At the moment it is rather cumbersome to write analysis passes.
And passing information from pass to pass is not exactly trivial 
either.


Therefore I am planning to spent some time next year to implement 
and polish a facility that allows matching patterns on dmd's AST 
in an event driven style.


However this will only bear fruit if there is actual interest in 
static analysis for D.


One possible application would be to automatically produce a 
precise complexity analysis for algorithms based on the compilers 
knowledge of the range interface.


Another one is to automatically reduce template-bloat and other 
duplicated code-blocks early on. (This one is my intended target.)


Cheers,
Stefan

Intresa in Static Analysis for D ?

[Stefan Koch via Digitalmars-d]

Hi Guys,

I was wondering how much interest in static analysis exists in 
this community .

DMD already has rudimentary support for these kinds of things.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Daniel Kozak via Digitalmars-d]

Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):


On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:

Are there plans to write a homebrew 64-bit linker for DMD?


There are already ld from mingw and lld from llvm team.


Why aren't they used and distributed in DMD for Windows by default?

If the tools mentioned above (LD and LLD) are available and usable on 
Windows x64 instead of the ones provided in heavily bloated packages 
by Microsoft, how come the DMD installer for Windows doesn't offer 
them as an alternative (or better yet as the default)?


AFAIK ld on mingw can`t link against mscoff file format so it is not 
very usable. LLD is quite new so I do not know how production ready is. 
But I believe LLD will be the answer in future.


Btw. today I want to start working on a D project in work, but I cant, 
because there is not enoght space on C:\ partion and there is not 
possible to instal VS to another disk :( (Ok in few attempt of 
installing VS there has been path I can change but it does not work 
anyway, still VS is trying to install to C:\ ).


So maybe one day I will be able to work at job on D windows project. 
Fortunately I can still work on other part (still in D) of project which 
is running on linux

Re: D Lang installation on Windows, dependency on Visual Studio?

[AB via Digitalmars-d]

On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:

Are there plans to write a homebrew 64-bit linker for DMD?


There are already ld from mingw and lld from llvm team.


Why aren't they used and distributed in DMD for Windows by 
default?


If the tools mentioned above (LD and LLD) are available and 
usable on Windows x64 instead of the ones provided in heavily 
bloated packages by Microsoft, how come the DMD installer for 
Windows doesn't offer them as an alternative (or better yet as 
the default)?

Re: Appender bug, or impossible?

[Rainer Schuetze via Digitalmars-d]

On 14.11.2016 21:26, Timon Gehr wrote:

On 14.11.2016 00:32, Steven Schveighoffer wrote:


A Foo[] can be stored in a Foo, because it doesn't need the size. But
yes, as soon as you start needing Appender functions, then the compiler
chokes.

It is a forward reference bug, but still a bug IMO. If you can store the
appender, then the compiler knows how big it has to be. So it should be
fine at that point.

Paging Timon, I'm betting your front end handles this just fine ;)

-Steve


It does. :)

Minimal example:

struct Appender(A){
alias T = typeof({ A a; return a[0]; }());
T[] data;
void put(T item){ data~=item; }
}
struct Foo{ Appender!(Foo[]) fooAppender; }
Foo[] test(){
Foo f;
f.fooAppender.put(Foo());
return f.fooAppender.data;
}
static assert(test().length==1);


Error with DMD, works with my front end.


Coincidentally, I've tried compiling your front end with latest dmd just 
yesterday. There is one file missing, though: cent_.d. Could you please 
commit this, too?


The cent code commented out, I noticed your code is suffering from the 
same issue as the OP (also happens for AAs, e.g. T[int]). A workaround 
is to use void[] and wrap it in property functions.


I've fixed/worked around a number of issues in dmd with respect to 
incomplete semantic analysis that happen with template mixins, but more 
still pop up afterwards.


Are there limitations to what the front end understands? Is it able to 
digest itself? That would be pretty impressive ;-)

[Issue 4577] Third way to create a std.typecons.Tuple

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #1 from Nick Treleaven  ---
This now works:
auto entry = tuple!("index", "value")(4, "Hello");

http://dlang.org/phobos/typecons.html#tuple

Can we close this?

--

Re: GitHub now supports editing the target branch for PR

[Dicebot via Digitalmars-d]

On 11/12/2016 12:34 PM, Sönke Ludwig wrote:
> Not sure if this is common knowledge already, but it was new for me. If
> you click the edit button at the top of a pull request on GitHub, you
> now get a drop down to change the base branch to which the request will
> be pulled. Really handy for PRs that should be targeted at a stable
> branch, but instead target master.

I think I have sent 3 or 4 support request to GitHub asking about it and
finally it arrives! :) Makes even bigger difference if one has to
maintain multiple version branches as opposed to plain stable/master.



signature.asc
Description: OpenPGP digital signature

Re: {DMD-AST-Tool} For beginning DDMD hackers

[Dicebot via Digitalmars-d]

On 11/13/2016 10:40 AM, Stefan Koch wrote:
> On Saturday, 12 November 2016 at 10:26:53 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I have written a small utility called dmd-ast-tool.
>> It can be used to quickly generate boilerplate code for dmd-ast-visitors.
>> Originally it was only written for my personal use, it used to work
>> with a handwritten text-file representing dmds ast class hierarchy.
>>
>> However I recently updated it construct the class hierarchy from ddmds
>> source code.
>>
>> It is pretty bare-boned, but maybe it can be useful to some of you :)
>>
>> https://github.com/UplinkCoder/dmd-ast-tool.
> 
> I have just added a bit of code to modify the ast-nodes.
> It can also print a few stats about dmd.
> For example the names of the visitors implemented in dmd.

You may want to consider adding it to https://github.com/dlang/tools




signature.asc
Description: OpenPGP digital signature

Re: D Lang installation on Windows, dependency on Visual Studio?

[Kagamin via Digitalmars-d]

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:

Are there plans to write a homebrew 64-bit linker for DMD?


There are already ld from mingw and lld from llvm team.

Re: PDF generation in D?

[Jot via Digitalmars-d]

On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote:
On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner 
Schadek wrote:
I used text files and LaTeX in the past, it works with 
everything


textfile -> process -> LaTeX -> pdf


This.

Another (a bit lower-level) option would be to produce a 
PostScript file and pass it to (e)ps2pdf.



Then that begs the question about how to generate ps in D and 
just kicks the can down the road.

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

[HaraldZealot via Digitalmars-d-announce]

On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu 
wrote:
Please join us at DConf 2017, the conference of the D 
programming language in Berlin, Germany, May 4-6 2017.


http://dconf.org/2017/index.html


Great!

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

[Adrian Matoga via Digitalmars-d-announce]

On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu 
wrote:
We're happy to announce that the D Language Foundation is 
cooperating again with Sociomantic to organize DConf 2017 in 
Berlin for the second time. Same location, same dates, but of 
course a whole new experience!

(...)
http://dconf.org/2017/index.html


It would be less confusing if the dates were updated with more 
attention than just s/2016/2017/g, as there's no February 29 in 
2017, and all others dates are on different days of week than in 
2016.

Otherwise, excellent news.

[Issue 16682] [REG 2.072] "privatization" of symbols in std.stdio breaks DFMT

[via Digitalmars-d-bugs]

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

Dicebot  changed:

   What|Removed |Added

 CC||pub...@dicebot.lv

--- Comment #1 from Dicebot  ---
https://github.com/dlang/phobos/pull/4902

--

Re: Release D 2.072.0

[Dicebot via Digitalmars-d-announce]

On 11/11/2016 09:36 PM, Nick Sabalausky wrote:
> On 11/11/2016 08:30 AM, Dicebot wrote:
>> On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
>>> Run the new dmd. If it fails, either fix your code or go temporarily
>>> go back to the old dmd until you can fix your code.
>>
>> D will never be considered production ready as pong as this attiude
>> remaind. Your described scenario in practice works like this:
>>
>> - You decide to delay fix until you have time to investigate
> 
> I've gone through a lot of compiler upgrades on a lot of D projects, and
> in my experience, this "investigate and fix for the new dmd" has always
> been trivial (aside from one instance where Phobos's standard function
> deprecation policy wasn't followed).

Speaking of Sociomantic experience, practice has shown that any breaking
change that requires 5 min fix for any given project can easily take
from weeks to months (!) before all maintained interdependent projects
are updated. With deprecations it is not a problem at all because
everyone moves on using own schedule caring only about hard time limit.
With _any_ sort of immediate breakage it is pain because now upgrade
both becomes urgent and needs to be explicitly synced between all
developers.

It is simply another side of "nine women can't make a baby in one month"
thing. Best way to scale large teams is to split them so that amount of
people involved in any specific process is minimal, otherwise even
trivialities escalate exponentially under weight of communications. And
with software development "large" starts pretty small.

> Some things should certainly have a smooth transition path (like above,
> when replacing a Phobos function with a different one), but really, not
> everything needs to be.
> 
>> - Half of users of your library you (or your colleagues) complain that
>> they can't upgrade their projects because you areso slow
>> - You desperately find time to do required fix which proves bavkwards
>> incompatible
> 
> AFAICT, That's not the case with this particular cycle detection matter.

Yes, but this is mentality I am talking about. In vast majority of cases
providing smooth deprecation path is trivial - replacing `error` call
with `deprecation` call in DMD patch, marking symbol as deprecated
before removing in Phobos. In some of PRs I have found while checking
last breakage, amount of time spent on discussion if it is OK to make a
change was 10x more than amount of time that adding deprecations would
take. It is waste of everyone's time!

We need to establish attitude were doing deprecations is a no-brainer,
like providing unittests for new functionality already is. Not because
some weird corporate ass demands it but because it is simple and
benefits the whole dub ecosystem.



signature.asc
Description: OpenPGP digital signature

Re: Release D 2.072.0

[Dicebot via Digitalmars-d-announce]

On 11/12/2016 02:20 PM, Basile B. wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/download.html
>>
>> This is the release ships with the latest version of dub (v1.1.0), comes
>> with lots of phobos additions and native TLS on OSX.
>> See the changelog for more details.
>>
>> http://dlang.org/changelog/2.072.0.html
>>
>> -Martin
> 
> Sorry another regression:
> 
> https://issues.dlang.org/show_bug.cgi?id=16682
> 
> I don't know if it's a real regression, maybe the PR that breaks dfmt is
> legit but at least
> - you (you == dlang team as an entity) could start a deprecation period.
> - the community could detect that before.

Thank you for the report! Will add that to required reverts in a moment.

Both points you have mentioned indeed can and should be addressed.




signature.asc
Description: OpenPGP digital signature

Re: D Lang installation on Windows, dependency on Visual Studio?

[AB via Digitalmars-d]

On Monday, 14 November 2016 at 10:20:48 UTC, Kagamin wrote:

On Monday, 14 November 2016 at 09:51:39 UTC, John Colvin wrote:
Now there is 
http://landinghub.visualstudio.com/visual-cpp-build-tools, 
perhaps we should be encouraging using that instead?


It's still 3gb, so one might want to delete unneeded stuff 
after installation, like arm tools and cross compilers.


Are there plans to write a homebrew 64-bit linker for DMD?

To this question I would appreciate an answer from the people who 
develop DMD itself and its 32-bit linker.

[Issue 16686] Can not spawn subprocess and read from File at same time

[via Digitalmars-d-bugs]

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

Alexander Milushev  changed:

   What|Removed |Added

 CC||zunk...@gmail.com

--

Re: The return of std.algorithm.find

[drug via Digitalmars-d-learn]

15.11.2016 12:50, RazvanN пишет:

On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:

The find function which receives an input haystack and a needle
returns the haystack advanced to the first occurrence of the needle.
For normal ranges this is fine, but for
sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7].
This is in terms with the general policy of the find function, but is
weird. Since we know the range is sorted, shouldn't the result be [1,
2, 4]?


The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]),
4). And the result is
the whole range [1, 2, 4, 5, 6, 7].
IIRC find!"a <= b" will return the first element that is less or equal 
to needle, so this will be the whole range. To find all elements of 
SortedRange that are less or equal to needle you need to use 
SortedRange.lowerBound

http://dlang.org/phobos/std_range.html#.SortedRange.lowerBound

Re: The return of std.algorithm.find

[Ali Çehreli via Digitalmars-d-learn]

On 11/15/2016 01:50 AM, drug wrote:

15.11.2016 12:48, drug пишет:

15.11.2016 12:43, RazvanN пишет:

The find function which receives an input haystack and a needle returns
the haystack advanced to the first occurrence of the needle. For normal
ranges this is fine, but for
sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This
is in terms with the general policy of the find function, but is weird.
Since we know the range is sorted, shouldn't the result be [1, 2, 4]?




I don't think so. You could use findSplit, it returns three ranges [1,
2], [4], [5, 6, 7].


See also SortedRange.trisect


Indeed. This is what I was typing:

import std.stdio;
import std.range;

void main() {
auto r = assumeSorted([1, 2, 4, 5, 6, 7]);
auto found = r.trisect(4);

auto desired = chain(found[0], found[1]);
writeln(desired);
}

Prints

[1, 2, 4]

Ali

Re: The return of std.algorithm.find

[drug via Digitalmars-d-learn]

15.11.2016 12:48, drug пишет:

15.11.2016 12:43, RazvanN пишет:

The find function which receives an input haystack and a needle returns
the haystack advanced to the first occurrence of the needle. For normal
ranges this is fine, but for
sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This
is in terms with the general policy of the find function, but is weird.
Since we know the range is sorted, shouldn't the result be [1, 2, 4]?




I don't think so. You could use findSplit, it returns three ranges [1,
2], [4], [5, 6, 7].


See also SortedRange.trisect

Re: The return of std.algorithm.find

[RazvanN via Digitalmars-d-learn]

On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:
The find function which receives an input haystack and a needle 
returns the haystack advanced to the first occurrence of the 
needle. For normal ranges this is fine, but for

sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 
7]. This is in terms with the general policy of the find 
function, but is weird. Since we know the range is sorted, 
shouldn't the result be [1, 2, 4]?


The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 
7]), 4). And the result is

the whole range [1, 2, 4, 5, 6, 7].

Re: The return of std.algorithm.find

[drug via Digitalmars-d-learn]

15.11.2016 12:43, RazvanN пишет:

The find function which receives an input haystack and a needle returns
the haystack advanced to the first occurrence of the needle. For normal
ranges this is fine, but for
sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This
is in terms with the general policy of the find function, but is weird.
Since we know the range is sorted, shouldn't the result be [1, 2, 4]?



I don't think so. You could use findSplit, it returns three ranges [1, 
2], [4], [5, 6, 7].

The return of std.algorithm.find

[RazvanN via Digitalmars-d-learn]

The find function which receives an input haystack and a needle 
returns the haystack advanced to the first occurrence of the 
needle. For normal ranges this is fine, but for

sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 
7]. This is in terms with the general policy of the find 
function, but is weird. Since we know the range is sorted, 
shouldn't the result be [1, 2, 4]?

Re: PDF generation in D?

[Adrian Matoga via Digitalmars-d]

On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner 
Schadek wrote:
I used text files and LaTeX in the past, it works with 
everything


textfile -> process -> LaTeX -> pdf


This.

Another (a bit lower-level) option would be to produce a 
PostScript file and pass it to (e)ps2pdf.

Re: Appender bug, or impossible?

[Ali Çehreli via Digitalmars-d]

On 11/14/2016 12:26 PM, Timon Gehr wrote:


Error with DMD, works with my front end.


What are the steps to use your front end instead of dmd's? Is the 
awesome combo of Timon front-end plus ldc back-end possible?


Ali

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 15 November 2016 at 09:02:08 UTC, Kagamin wrote:
On Tuesday, 15 November 2016 at 08:33:26 UTC, Vladimir 
Panteleev wrote:
UIs where each key press launches a command (e.g. magit, 
background builds...)


emacs?


Yep.


Also doesn't dmdfe spend most of its time in semantic analysis?


Yep, but this isn't restricted to D, of course. More complicated 
build systems do a lot of I/O (and, often, unnecessary sync()ing).

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Kagamin via Digitalmars-d]

On Tuesday, 15 November 2016 at 08:33:26 UTC, Vladimir Panteleev 
wrote:
UIs where each key press launches a command (e.g. magit, 
background builds...)


emacs?
Also doesn't dmdfe spend most of its time in semantic analysis? 
You can't possibly optimize that with IO.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Kagamin via Digitalmars-d]

On Monday, 14 November 2016 at 13:44:29 UTC, Patrick Schluter 
wrote:
That's a true issue imho also. I had the same problem. Both my 
machine at work and at home have their windows system partition 
on a smallish SSD.


You can move stuff from the system drive with symbolic links; 
e.g. windows\installer, just see what takes space and has no 
reason to be on the system drive.

[OT] D Lang installation on Windows, dependency on Visual Studio?

[Vladimir Panteleev via Digitalmars-d]

On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky 
wrote:

SSDs are still far too small.


Hmm...

http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/


the ONLY time I ever have speed issues


"Speed issues" is one thing. Having most operations be INSTANT is 
another. It MASSIVELY transforms your workflow; UIs where each 
key press launches a command (e.g. magit, background builds...) 
become sensible and usable "blindly", and can easily multiply 
productivity by an order of magnitude.


If you don't have an SSD in your work machine (but can afford 
one), you simply don't value your time.

[Issue 12492] [AA] Clarify what types can be used to get associative array key value

[via Digitalmars-d-bugs]

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

Ali Cehreli  changed:

   What|Removed |Added

 CC||acehr...@yahoo.com

--- Comment #1 from Ali Cehreli  ---
I hit this problem in a const member function where the member type of .values
turned out to be const:

struct S {
int[char[]] aa;

void constFunc() const {
static assert(is(typeof(aa.keys[0]) == const(char)[]));  // Passes,
good
static assert(is(typeof(aa.values[0]) == int));  // FAILS
}
}

void main() {
}

(In my particular case, I had attempted to sort the copy of values, which had
failed due to const(int) members.)

Note that the workaround of declaring a non-const array is totally safe:

int[] values;
foreach (v; aa.byValue) {
values ~= v;
}

Of course functional style with .byValue would still produce the wrong type:

auto values = aa.byValue.array;
static assert(is(typeof(values[0]) == int));  // FAILS

Ali

--

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

[Martin Tschierschke via Digitalmars-d-announce]

On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu 
wrote:
Please join us at DConf 2017, the conference of the D 
programming language in Berlin, Germany, May 4-6 2017.



Great news for all living in D and programming in D :-)

Please take care to enable early registration now:


Not Found


The requested URL /2017/registration.html was not found on this 
server.


[...]


http://dconf.org/2017/index.html


Regards mt.

[D is the common one letter acronym for Deutschland = Germanay
https://en.wikipedia.org/wiki/D_(disambiguation)]