[Issue 17289] With Xcode 8.3 linker, warnings of "pointer not aligned"

[via Digitalmars-d-bugs]

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

Jon Degenhardt  changed:

   What|Removed |Added

 CC||jrdemail2000-dl...@yahoo.co
   ||m

--- Comment #1 from Jon Degenhardt  ---
Seeing the same behavior. Occurs in most of my programs. DMD64 D Compiler
v2.073.1; Xcode 8.3, Build version 8E162. Does not occur with LDC.

--

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Walter Bright via Digitalmars-d]

On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:

There are certainly advantages to having the compiler skip over code where
it can, but it's pretty weird for the language to require that something be
valid and then have the compiler ignore it. That makes it really easy to
have something compile on one compiler but not another. Granted, properly
unit testing and testing code on a variety of platforms (so that all of the
version blocks and static if branches are tested) should catch those issues
regardless, but it does seem a bit off to me for the language to require
something and for the compiler to not care - especially the reference
compiler.


I know. But it is worth it. It should enable D compilers to scale to handling 
very large imports.

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Jonathan M Davis via Digitalmars-d]

On Friday, March 31, 2017 17:49:48 Walter Bright via Digitalmars-d wrote:
> One of my longer term goals for DMD is to make it as lazy as possible -
> only parse and do semantic analysis if the result is actually needed. Not
> doing the parse for unused unittest blocks is a step in that direction.
>
> The code is still required to be correct, but the compiler isn't required
> to diagnose it.

There are certainly advantages to having the compiler skip over code where
it can, but it's pretty weird for the language to require that something be
valid and then have the compiler ignore it. That makes it really easy to
have something compile on one compiler but not another. Granted, properly
unit testing and testing code on a variety of platforms (so that all of the
version blocks and static if branches are tested) should catch those issues
regardless, but it does seem a bit off to me for the language to require
something and for the compiler to not care - especially the reference
compiler.

- Jonathan M Davis

Re: Upgrading the minimum version of FreeBSD supported

[Jonathan M Davis via Digitalmars-d]

On Friday, March 31, 2017 15:51:33 Walter Bright via Digitalmars-d wrote:
> The autotester is currently at FreeBSD 8.4. This is rather obsolete. The
> linker that is standard on 8.4 is causing problems:
>
>https://github.com/dlang/dmd/pull/6564
>
> The oldest supported version of FreeBSD stands at 10.3:
>
>https://www.freebsd.org/security/unsupported.html
>
> I know the linker with FreeBSD 11.0 does work correctly. I don't know
> which FreeBSD version it was fixed on.
>
> So the question is, can we at least move to FreeBSD 10.3 as the minimum
> supported version? Is anyone very dependent on an older FreeBSD? Is there
> a case for supporting FreeBSD versions that are officially unsupported?

Some work was done a year or two ago to fix FreeBSD 9 and 10, and AFAIK,
they both work, though I've never used FreeBSD 9. 10.3 did work the last
time I tried it, as did 11.0 (both passed druntime and phobos' unit tests,
and I _think_ that I ran dmd's tests and that they passed, but I'm not 100%
sure, since I don't run those normally). FreeBSD CURRENT does _not_
currently work properly due to a problem with stack unwinding that results
in bus errors when an exception is thrown. I think that there's a decent
chance that it's a FreeBSD bug as opposed to ours, but I haven't gotten
around to contacting the FreeBSD devs about it yet. However, that problem
has not yet made it into an official release, and hopefully it never does.

As for the minimum version to support, I'd be very much inclined to argue
that we only officially support the versions that the FreeBSD folks
currently support, or we're just asking for trouble. And honestly, I think
that we should do the same on all platforms. If someone wants to run an
unsupported version of an OS, they're just begging for trouble anyway, and
they can always use an older version of the compiler that did support that
OS. And actually, the last time I checked, the official FreeBSD port for dmd
claimed that we don't officially support FreeBSD, even though we
theoretically do (probably because support for it hasn't been as good - e.g.
we test on an outdated version of the OS and took quite a while to fix
druntime for newer versions of FreeBSD). Sadly, I think that the primary
reason that druntime works correctly on FreeBSD 10 and 11 now is because I
switched to using it as my primary OS and complained when it didn't work. It
seems to have primarily gone under the radar otherwise.

- Jonathan M Davis

Re: Building DMD

[Inquie via Digitalmars-d-learn]

On Saturday, 1 April 2017 at 00:12:10 UTC, Inquie wrote:
So, I rebuilt everything again from scratch, I fixed up the 
make files and such and everything went smooth. I was able to 
not have the errors.


[...]



I was able to solve the comdat problem by moving a local function 
outside a loop(didn't really need to define it in the loop)... 
but it had no problems on previous build. Seems that the function 
was being defined several times due to ctfe or whatever and that 
caused problems.

[Issue 16174] [SECURITY] HTTP header injection

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #1 from Steven Schveighoffer  ---
While I can see the concern, the truth is that you already are able to call a
function which is adding a header to the request. In that sense, this isn't
exactly a "security" issue, as you have permission to add the header already.

Where this can be a problem is if you are passing a string from an un-trusted
source, but that's probably not a good idea anyway, even if just adding one
header.

I'm not sure std.net.curl is the right place to make these types of decisions,
it's a pretty bare wrapper around curl.

Closing as WONTFIX, please re-open if you think this is in error.

--

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Walter Bright via Digitalmars-d]

On 3/29/2017 4:16 AM, deadalnix wrote:

I was wondering. When uniitests aren't going to run, it may be desirable to skip
parsing altogether, just lexing and counting braces until the matching closing
brace is found.

Obviously, this means that no error will be found in unittests blocks. That can
contain pretty much anything that lex, so it's even more lax than what's allowed
inside a static if.

Is that an acceptable tradeof ?



One of my longer term goals for DMD is to make it as lazy as possible - only 
parse and do semantic analysis if the result is actually needed. Not doing the 
parse for unused unittest blocks is a step in that direction.


The code is still required to be correct, but the compiler isn't required to 
diagnose it.

[Issue 17289] New: With Xcode 8.3 linker, warnings of "pointer not aligned"

[via Digitalmars-d-bugs]

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

  Issue ID: 17289
   Summary: With Xcode 8.3 linker, warnings of "pointer not
aligned"
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Keywords: wrong-code
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

Just updated to Xcode 8.3 and tried to build D libraries. I get a whole bunch
of messages that look similar to this:

ld: warning: pointer not aligned at address 0x10003A8BB
(_D11TypeInfo_Pv6__initZ + 0 from testpointernotaligned.o)

Code that reproduces this:

import std.typecons;

struct X
{
RefCounted!(int*) x;
}

void main()
{
}

RefCounted seems to trigger it. Not sure what triggers it or not, but always
seems to be the initializer that has the issue.

This happens on compilers back to 2.069.0. It does not happen on 2.068.2.

Note that the program compiles and runs, but this warning should not happen.

--

[Issue 15763] std.math.approxEqual is not symmetric

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |ASSIGNED

--- Comment #2 from Steven Schveighoffer  ---
Hm... also found an issue, because if rhs is a range, but lhs is a value, it
swaps the arguments and calls approxEqual(rhs, lhs). Clearly, if rhs is the
relative difference determination, you don't want to do this (as the comparison
isn't symmetrical).

PR: https://github.com/dlang/phobos/pull/5316

--

Re: The nail in the coffin of C++ or why don't GO there...

[Ali Çehreli via Digitalmars-d]

On 03/29/2017 11:58 PM, Ervin Bosenbacher wrote:

> From the  Programming in D book i  typed in the below code

In case it's useful to someone, the source code is available in zipped 
format as well (search for ".zip" on the index page):


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

Ali

Re: Building DMD

[Inquie via Digitalmars-d-learn]

So, I rebuilt everything again from scratch, I fixed up the make 
files and such and everything went smooth. I was able to not have 
the errors.


I think what I did first was I built dmdx64 then copied it to the 
bin dir and tried to use it but got the phobos errors. I then 
tried to build druntime/phobos and it was trying to use that 
version of the dmd, which I guess was faulty because 
phobos\druntime wasn't correct. Instead, I simply built 
everything first then copied everything together and that seemed 
to work.


It would be real nice if we could have the x64 version added to 
the distro so people don't have to rebuild each time. Also, the 
make files needs to be updated to support the latest VS. It's 
nice that the build process went pretty smooth otherwise though.


Seems to work but now I run in to two problems:

If I try to compile for win32 I get

Error: more than 32767 symbols in object file

if I try to compile for x64 I get

fatal error LNK1179: invalid or corrupt file: duplicate COMDAT 
'_D6modu2557__T19fooVAyaa13_6d50686f746f73686f70434f4dVAAyaA82a11_4170706c69636174696f6ea8_446f63756d656e74a8_4172744c61796572a8_546578744974656da10_536f6c6964436f6c6f72a8_524742436f6c6f72a9_47726179436f6c6f72a9_434d594b436f6c6f72a8_4c6162436f6c6f72a8_485342436f6c6f72a8_4c61796572536574a6_4c6179657273a9_4c6179657253657473a9_4172744c6179657273a12_486973746f72795374617465a12_446f63756d656e74496e666fa9_53656c656374696f6ea7_4368616e6e656ca11_584d504d65746164617461a16_4d6561737572656d656e745363616c65a8_4368616e6e656c73a13_486973746f7279537461746573a10_4c61796572436f6d7073a9_4c61796572436f6d70a9_506174684974656d73a8_506174684974656da12_537562506174684974656d73a11_537562506174684974656da10_50617468506f696e7473a9_50617468506f696e74a10_436f756e744974656d73a9_436f756e744974656da13_436f6c6f7253616d706c657273a12_436f6c6f7253616d706c6572a11_507265666572656e636573a9_446f63756d656e7473a9_54657874466f6e7473a8_54657874466f6e74a9_4e6f74696669657273a8_4e6f746966696572a14_4d6561737572656d656e74!

4c6f67a16_416374696f6e44657363726970746f72a10_416374696f6e4c697374a15_416374696f6e5265666572656e6365a18_50686f746f43444f70656e4f7074696f6e73a20_526177466f726d61744f70656e4f7074696f6e73a14_5044464f70656e4f7074696f6e73a14_4550534f70656e4f7074696f6e73a16_4449434f4d4f70656e4f7074696f6e73a20_43616d6572615241574f70656e4f7074696f6e73a20_50686f746f73686f70536176654f7074696f6e73a14_424d50536176654f7074696f6e73a14_474946536176654f7074696f6e73a14_455053536176654f7074696f6e73a15_4a504547536176654f7074696f6e73a14_504446536176654f7074696f6e73a19_5049435446696c65536176654f7074696f6e73a16_5069786172536176654f7074696f6e73a14_504e47536176654f7074696f6e73a14_526177536176654f7074696f6e73a17_534749524742536176654f7074696f6e73a16_5461726761536176654f7074696f6e73a15_5469536176654f7074696f6e73a16_444353315f536176654f7074696f6e73a16_444353325f536176654f7074696f6e73a24_4578706f72744f7074696f6e73496c6c7573747261746f72a23_4578706f72744f7074696f6e7353617665466f72576562a23_4269746d6170436f6e76657273!
696f6e4f7074696f6e73a24_496e6465786564436f6e76657273696f6e4f7074696f6e73a7_4e6f436f6c6f72a19_50726573656e746174696f6e4f7074696f6e73a14_47616c6c6572794f7074696f6e73a20_47616c6c65727942616e6e65724f7074696f6e73a20_47616c6c657279496d616765734f7074696f6e73a23_47616c6c6572795468756d626e61696c4f7074696f6e73a25_47616c6c657279437573746f6d436f6c6f724f7074696f6e73a22_47616c6c65727953656375726974794f7074696f6e73a19_436f6e7461637453686565744f7074696f6e73a21_506963747572655061636b6167654f7074696f6e73a12_42617463684f7074696f6e73a11_53756250617468496e666fa13_50617468506f696e74496e666fZ19.

It seems I get the corrupt comdat when using come ctfe stuff.

[Issue 5711] Accessing local variable of a function in which an inner class is instantiated trashes this.outer

[via Digitalmars-d-bugs]

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

Ryuichi OHORI  changed:

   What|Removed |Added

 CC||r.97...@gmail.com

--- Comment #1 from Ryuichi OHORI  ---
I don't observe this behavior with DMD2.073.
When was it fixed?

--

[Issue 15763] std.math.approxEqual is not symmetric

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com
   Assignee|nob...@puremagic.com|schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
I think that you need to pick one of the two parameters to determine the
relative error.

One could use a some test to determine the "best" value, but "best" is
subjective. Armed with the knowledge that the second parameter is the one that
is the basis for the percentage difference, you can call it in the correct
order.

Working on Doc PR.

--

[Issue 15536] [std.experimental.logger] More detailed example

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords|trivial |
 CC||rburn...@gmail.com,
   ||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
This bug needs more information. Please include a program (or link to one)
which exhibits the problem.

--

[Issue 15534] [std.experimental.logger.core] Documentation mismatch

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull
 CC||schvei...@yahoo.com
   Assignee|nob...@puremagic.com|schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
https://github.com/dlang/phobos/pull/5315

--

[Issue 14635] inconsistent type for line: uint vs size_t

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
  Component|phobos  |druntime
 Resolution|--- |WONTFIX

--- Comment #2 from Steven Schveighoffer  ---
Good point, however, this is a dmd internal hook, and uints implicitly cast to
size_t. We can worry about this the day DMD can successfully file a 2^32 + 1
line file.

--

[Issue 15642] std.utf.encode should return ubyte

[via Digitalmars-d-bugs]

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

--- Comment #1 from Steven Schveighoffer  ---
There was an attempt to fix this, but it died in committee.

https://github.com/dlang/phobos/pull/5077

--

[Issue 12940] std.bigint.Bigint.toSize_t too, and alternative API suggestion

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords|trivial |
 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
trivial to implement, but not trivial to decide whether this should happen.

cast(size_t)someBigInt works, so I'm not sure it's needed in any case.

--

Upgrading the minimum version of FreeBSD supported

[Walter Bright via Digitalmars-d]

The autotester is currently at FreeBSD 8.4. This is rather obsolete. The linker 
that is standard on 8.4 is causing problems:


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

The oldest supported version of FreeBSD stands at 10.3:

  https://www.freebsd.org/security/unsupported.html

I know the linker with FreeBSD 11.0 does work correctly. I don't know which 
FreeBSD version it was fixed on.


So the question is, can we at least move to FreeBSD 10.3 as the minimum 
supported version? Is anyone very dependent on an older FreeBSD? Is there a case 
for supporting FreeBSD versions that are officially unsupported?

[Issue 17286] A function for comparing two digests securely

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/290447ead429608c818db8c263c4df9b722c37c2
Fix Issue 17286 - A function for comparing two digests securely

https://github.com/dlang/phobos/commit/30b9da518941e2dfad18acbc1d99a2a2790d996a
Merge pull request #5312 from JackStouffer/secureCompare

Fix Issue 17286 - A function for comparing two digests securely

--

Re: Building DMD

[Inquie via Digitalmars-d-learn]

On Friday, 31 March 2017 at 14:24:43 UTC, Stefan Koch wrote:

On Friday, 31 March 2017 at 14:19:59 UTC, Inquie wrote:
On Friday, 31 March 2017 at 08:20:51 UTC, Nicholas Wilson 
wrote:

[...]


Yes, I downloaded druntime from github and built it as I did 
phobos. The 64-bit make files have issues because paths are 
hard coded and things are not so simple as they used to be, 
but I was able to, I think, get everything to work.


So, if this is a druntime issue, and if built it "correctly" 
is there any settings I would have to change to add them or 
anything like that? Any way to check if those symbols exist in 
druntime64.lib?


It seems the methods are in

src\core\exception.d

so not sure why they wouldn't be added.


But yes, I downloaded everything nearly simultaneously and 
build them.


Download the source of a release version.
~master is always a little unstable.
picking the ~stable branch for phobos druntime and dmd should 
end up in a working compiler close to the latest release.



So, I downloaded all stables an rebuilt and replaced and same 
error ;/(dmd, druntime, and phobos)


The error seems to be in something else:

1. I had to use fix up the paths to get win64.mak to compile 
because the paths are hard coded for old visual 
studio/clang/sdk's that simply do not translate in to the newer 
visual studio revamps. (wish it did, because it's a pain to find 
all the right files).


2. druntime64.lib has _d_arrayboundsp and _d_assertp in it(doing 
a text search).


Any ideas? I'm at a loss. So close but so far!

dlang.org SSL certs

[Ianis G. Vasilev via Digitalmars-d]

It's nice to see that all of the website's subdomains have SSL 
certificates. However, I noticed an inconsistency:


dlang.org, forum.dlang.org, code.dlang.org, tour.dlang.org, 
wiki.dlang.org all serve the same content over both http and 
https.


http://blog.dlang.org and https://blog.dlang.org, however, serve 
completely different content. The https version seems to serve 
the same page as https://digitalmars.com and, because the 
certificate is issued for digitalmars.com, browsers complain 
about it being invalid. If this is not intended behavior - maybe 
the same content should be served on both ports? Or maybe the 
subdomain should be removed in favor of https://dlang.org/blog?


Also, I don't want to start a flame war, but I think all the http 
traffic need to be redirected to https. At least for the 
subdomains that require user login.

Re: How to continue after the book?

[JamesD via Digitalmars-d-learn]

On Wednesday, 29 March 2017 at 06:39:17 UTC, Laeeth Isharc wrote:

On Wednesday, 29 March 2017 at 05:53:22 UTC, I Lindström wrote:
Thanks all. Your answers gave me a lot more confidence in 
starting. What I've always found to be the hardest is to know 
what you can do, and that's what I use books for. "Can" in the 
sense of what's possible and how. These forums and the docs on 
the site have given me a pretty decent idea about how to 
proceed and do things. It's not the work itself that I dread, 
but more the "can I find out how to do something", but some of 
your answers touched on this and I will take heed.


A lot to learn. You can expect me to come pester you guys if I 
hit a snag. Heh.


plus IRC chat if you get stuck.


All great tips above!

I have some rather simple examples here:
https://github.com/jasc2v8/dwt-support

I had created a vhd copy program in AutoIt, and set a goal to 
convert to D.


The result is a much better utility, as well as learning the D 
language from the very basics to a useful gui app.

Re: Building DMD

[Stefan Koch via Digitalmars-d-learn]

On Friday, 31 March 2017 at 14:19:59 UTC, Inquie wrote:

On Friday, 31 March 2017 at 08:20:51 UTC, Nicholas Wilson wrote:

[...]


Yes, I downloaded druntime from github and built it as I did 
phobos. The 64-bit make files have issues because paths are 
hard coded and things are not so simple as they used to be, but 
I was able to, I think, get everything to work.


So, if this is a druntime issue, and if built it "correctly" is 
there any settings I would have to change to add them or 
anything like that? Any way to check if those symbols exist in 
druntime64.lib?


It seems the methods are in

src\core\exception.d

so not sure why they wouldn't be added.


But yes, I downloaded everything nearly simultaneously and 
build them.


Download the source of a release version.
~master is always a little unstable.
picking the ~stable branch for phobos druntime and dmd should end 
up in a working compiler close to the latest release.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Friday, 31 March 2017 at 14:05:00 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:

[ ... ]


Alright guys.

I am just fixing the newCTFE LLVM backend such that I can have 
better guesses as to what performance a JIT could archive.


Due to the ABI changes the llvm-backend a little optimization 
potential.


It'll be a while until the llvm backend is on par again.
Because functions and such need to be dealt with quite 
differently.
Also the llvm backend recives less testing since I cannot run 
it at compile time(Yet :))


Cheers,
Stefan
--
sorry for the short message I am busy fixing codegen bugs as 
always.


oh, yeah ... If you want to checkout the llvm backend fethc the 
newCTFE_LLVMBackend branch from 
https://github.com/UplinkCoder/dmd.


the posix.mak is hardcoded to use libLLVM-3.5.
However you should be able to use any version newer then 3.3.

Re: Building DMD

[Inquie via Digitalmars-d-learn]

On Friday, 31 March 2017 at 08:20:51 UTC, Nicholas Wilson wrote:

On Friday, 31 March 2017 at 07:23:42 UTC, Inquie wrote:
I am trying to build DMD 64-bit. I was able to build 
everything after getting the paths fixed for zlib, druntime, 
and phobos. Everything seems to compile. I replaced all the 
files generated in to the dmd directories of the old ones. 
(phobos64.lib, gcstub.obj, dmd.exe)


But anytime I build my projects that worked fine in the x86 
compiler I get the errors:


 Error 42: Symbol Undefined __d_arrayboundsp
 Error 42: Symbol Undefined __d_assertp

These seem like dmd runtime functions or something similar but 
not sure why they don't exist.


Any ideas? Are these functions suppose to be in phobos or 
druntime? and why aren't they showing up when I build from 
sources and replaced everything, I believe, correctly?


Those are runtime functions. Did you build druntime64.lib? If 
so is it up to date? The compiler and runtime are required to 
by in sync.


Alternately compiling with `-release -boundscheck=off` should 
remove reliance on those functions (this is not a proper 
solution).


Yes, I downloaded druntime from github and built it as I did 
phobos. The 64-bit make files have issues because paths are hard 
coded and things are not so simple as they used to be, but I was 
able to, I think, get everything to work.


So, if this is a druntime issue, and if built it "correctly" is 
there any settings I would have to change to add them or anything 
like that? Any way to check if those symbols exist in 
druntime64.lib?


It seems the methods are in

src\core\exception.d

so not sure why they wouldn't be added.


But yes, I downloaded everything nearly simultaneously and build 
them.

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[deadalnix via Digitalmars-d]

On Thursday, 30 March 2017 at 20:29:26 UTC, Dukc wrote:

On Thursday, 30 March 2017 at 17:22:20 UTC, Stefan Koch wrote:

SDC has the goal to be more principled.
And Not to be Mr. fast and loose, right ?
If a file parses it'd better be syntactically correct!
All of it.


Just an idea, but could the solution for SDC be to enable 
unittests by default, disabling them would be explicit? That 
would sure make using it alot more principled that dmd, 
regardless whether it syntax checks unittests when they are 
disabled.


SDC uses an utility called sdunit to JIT the unittest. Right now, 
sdunit doesn't handle exceptions so its utility is limited, but 
it's getting there.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


Alright guys.

I am just fixing the newCTFE LLVM backend such that I can have 
better guesses as to what performance a JIT could archive.


Due to the ABI changes the llvm-backend a little optimization 
potential.


It'll be a while until the llvm backend is on par again.
Because functions and such need to be dealt with quite 
differently.
Also the llvm backend recives less testing since I cannot run it 
at compile time(Yet :))


Cheers,
Stefan
--
sorry for the short message I am busy fixing codegen bugs as 
always.

Re: Dlang Boston Meetup - Hack-a-thon

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/24/17 2:20 PM, Steven Schveighoffer wrote:

For those D enthusiasts living in or around Boston, I've scheduled a
mini hack-a-thon for next Friday 3/31 in the Back Bay. Would be great to
see you all there!

Details here:
https://www.eventbrite.com/e/dlang-boston-hack-a-thon-tickets-33151627410



It seems mother nature doesn't like Boston D meetups! However, I'm still 
planning on having this, as despite NH getting over a foot of snow 
overnight, I think Boston is getting mostly rain. See you all there tonight!


-Steve

Project Highlight: workspace-d

[Mike Parker via Digitalmars-d-announce]

Jan Jurzitza (a.k.a. WebFreak001 in these forums) talks a little 
about workspace-d. For those unfamiliar with it, it's a common 
backend plugin authors can use when creating D plugins for any 
IDE or text editor.


Blog:
https://dlang.org/blog/2017/03/31/project-highlight-workspace-d/

Reddit:
https://www.reddit.com/r/programming/comments/62l8ys/workspaced_a_common_backend_for_d_editoride/

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Jacob Carlborg via Digitalmars-d]

On 2017-03-29 13:16, deadalnix wrote:

I was wondering. When uniitests aren't going to run, it may be desirable
to skip parsing altogether, just lexing and counting braces until the
matching closing brace is found.

Obviously, this means that no error will be found in unittests blocks.
That can contain pretty much anything that lex, so it's even more lax
than what's allowed inside a static if.

Is that an acceptable tradeof ?


I know Andrei has said he want to do this for as much as possible.

--
/Jacob Carlborg

Re: [your code here]

[Paul Backus via Digitalmars-d]

On Friday, 31 March 2017 at 02:22:14 UTC, April Dale wrote:

I need some informations on what this is


Hovering your mouse over it should cause the following message to 
appear:




Got a brief example illustrating D?

Submit your code to the digitalmars.D forum specifying "[your 
code here]" in

the subject.

Upon approval it will be showcased here on a random schedule.

Re: Rename 'D' to 'D++'

[Chris via Digitalmars-d]

On Friday, 31 March 2017 at 06:40:51 UTC, Ali wrote:

On Saturday, 11 March 2017 at 15:27:50 UTC, Kagamin wrote:

D••
:D


thanks for sharing 
https://img.memesuper.com/9d0f96eb3d5a68cff0a3dd357957895b_muahaha-muahaha-meme_625-833.jpeg


So if your first child is called, say, Ali, your second child 
will be called Ali++. :-) The Romans actually had that naming 
scheme: Primus, Secundus ...

Re: pointer not aligned

[Adam Wilson via Digitalmars-d-learn]

On 3/30/17 10:47 PM, H. S. Teoh via Digitalmars-d-learn wrote:

On Fri, Mar 31, 2017 at 04:41:10AM +, Joel via Digitalmars-d-learn wrote:

Linking...
ld: warning: pointer not aligned at address 0x10017A4C9
(_D30TypeInfo_AxS3std4file8DirEntry6__initZ + 16 from 
.dub/build/application-debug-posix.osx-x86_64-dmd_2072-EFDCDF4D45F944F7A9B1AEA5C32F81ED/spellit.o)
...

and this goes on forever!


More information, please.  What was the code you were trying to compile?
What compile flags did you use? Which compiler?


T



I see this on OSX as well. Any code referencing Phobos appears to 
produce this. It appear after updating the XCode command line tools. It 
does not appear to effect program execution, but the pages of warnings 
are really quite annoying.


DMD 2.073.2

--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: Building DMD

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 31 March 2017 at 07:23:42 UTC, Inquie wrote:
I am trying to build DMD 64-bit. I was able to build everything 
after getting the paths fixed for zlib, druntime, and phobos. 
Everything seems to compile. I replaced all the files generated 
in to the dmd directories of the old ones. (phobos64.lib, 
gcstub.obj, dmd.exe)


But anytime I build my projects that worked fine in the x86 
compiler I get the errors:


 Error 42: Symbol Undefined __d_arrayboundsp
 Error 42: Symbol Undefined __d_assertp

These seem like dmd runtime functions or something similar but 
not sure why they don't exist.


Any ideas? Are these functions suppose to be in phobos or 
druntime? and why aren't they showing up when I build from 
sources and replaced everything, I believe, correctly?


Those are runtime functions. Did you build druntime64.lib? If so 
is it up to date? The compiler and runtime are required to by in 
sync.


Alternately compiling with `-release -boundscheck=off` should 
remove reliance on those functions (this is not a proper 
solution).

Building DMD

[Inquie via Digitalmars-d-learn]

I am trying to build DMD 64-bit. I was able to build everything 
after getting the paths fixed for zlib, druntime, and phobos. 
Everything seems to compile. I replaced all the files generated 
in to the dmd directories of the old ones. (phobos64.lib, 
gcstub.obj, dmd.exe)


But anytime I build my projects that worked fine in the x86 
compiler I get the errors:


 Error 42: Symbol Undefined __d_arrayboundsp
 Error 42: Symbol Undefined __d_assertp

These seem like dmd runtime functions or something similar but 
not sure why they don't exist.


Any ideas? Are these functions suppose to be in phobos or 
druntime? and why aren't they showing up when I build from 
sources and replaced everything, I believe, correctly?

Re: pointer not aligned

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

On Fri, Mar 31, 2017 at 04:41:10AM +, Joel via Digitalmars-d-learn wrote:
> Linking...
> ld: warning: pointer not aligned at address 0x10017A4C9
> (_D30TypeInfo_AxS3std4file8DirEntry6__initZ + 16 from 
> .dub/build/application-debug-posix.osx-x86_64-dmd_2072-EFDCDF4D45F944F7A9B1AEA5C32F81ED/spellit.o)
> ...
> 
> and this goes on forever!

More information, please.  What was the code you were trying to compile?
What compile flags did you use? Which compiler?


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character, 
give him power. -- Abraham Lincoln

Re: Rename 'D' to 'D++'

[Ali via Digitalmars-d]

On Saturday, 11 March 2017 at 15:27:50 UTC, Kagamin wrote:

D••
:D


thanks for sharing 
https://img.memesuper.com/9d0f96eb3d5a68cff0a3dd357957895b_muahaha-muahaha-meme_625-833.jpeg

Re: DMD 64-bit Windows

[Inquie via Digitalmars-d]

On Friday, 31 March 2017 at 05:42:08 UTC, Inquie wrote:

On Friday, 11 November 2016 at 17:04:08 UTC, Mario Silva wrote:
On Thursday, 10 November 2016 at 10:24:43 UTC, Rene Zwanenburg 
wrote:
On Thursday, 10 November 2016 at 09:35:00 UTC, Mario Silva 
wrote:
I haven't tried it yet, but I would want to avoid changing 
the compiler at this point, since we already have all our 
tooling build around DMD.


That is why I'm asking specifically about the state of the 
64-bit windows version of DMD.


There is no official 64 bit build of DMD, but it's quite easy 
to make one yourself using Digger:


https://github.com/CyberShadow/Digger

Since the 64 bit build is not automatically tested master 
will sometimes fail to compile, but sticking to releases 
always works for me so far.


Thanks all for the info, I build it locally as suggested.

Still not sure why there is not an official release it since 
it is already being supported. I would suggest doing it so if 
possible.



I second that. Either add a dmdx64.exe to the regular release 
or create a new package for it. It would be very nice to have. 
If we have to build it ourselves then it means that who ever 
builds x86 can do it too and add it to the package quite easily.


I am having trouble building phobos for x64. Mainly runtime. This 
is due to the fact that the paths for druntime are hard coded to 
old visual studio versions. They should not be hard coded by 
attempt to detect(derive from registry settings or paths).


I get

--- errorlevel -1073741701

which is uninformative.

I was able to built for x86 without issue. (although phobos 
crapped out on trying to build druntime, I was able to build 
druntime first then phobos and it worked)

Re: DMD 64-bit Windows

[Inquie via Digitalmars-d]

On Friday, 11 November 2016 at 17:04:08 UTC, Mario Silva wrote:
On Thursday, 10 November 2016 at 10:24:43 UTC, Rene Zwanenburg 
wrote:
On Thursday, 10 November 2016 at 09:35:00 UTC, Mario Silva 
wrote:
I haven't tried it yet, but I would want to avoid changing 
the compiler at this point, since we already have all our 
tooling build around DMD.


That is why I'm asking specifically about the state of the 
64-bit windows version of DMD.


There is no official 64 bit build of DMD, but it's quite easy 
to make one yourself using Digger:


https://github.com/CyberShadow/Digger

Since the 64 bit build is not automatically tested master will 
sometimes fail to compile, but sticking to releases always 
works for me so far.


Thanks all for the info, I build it locally as suggested.

Still not sure why there is not an official release it since it 
is already being supported. I would suggest doing it so if 
possible.



I second that. Either add a dmdx64.exe to the regular release or 
create a new package for it. It would be very nice to have. If we 
have to build it ourselves then it means that who ever builds x86 
can do it too and add it to the package quite easily.