Re: My two cents
On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote: In C++ incremental rebuilds are simple as you compile each file individually anyhow, but that's the crux for why C++ compilations are so slow in the first place. Compiling multiple modules at once provides lots of speedups as you do not have to reparse and analyze common/mutual imports, but on the downside it cannot be parallelized that well. I wish I knew how Delphi was compiling things because it is by far the fastest compiler I have ever tried. It compiled individual files as well but not into obj files but some dcu files and it used them if source wasn't changed when compiling sources that depended on that module.
Re: Multiline string literal improvements
On Friday, 13 October 2017 at 07:59:36 UTC, Biotronic wrote: D version that works in CTFE: Thanks Biotronic! This is just what I had in mind.
Re: Multiline string literal improvements
On Wednesday, 11 October 2017 at 14:28:32 UTC, Meta wrote:
On Wednesday, 11 October 2017 at 09:56:52 UTC, Igor wrote:
On Wednesday, 11 October 2017 at 08:35:51 UTC, Walter Bright
wrote:
On 10/10/2017 3:16 PM, sarn wrote:
Works even better in D because it can run at compile time.
Yes, I see no need for a language feature what can be easily
and far more flexibly done with a regular function -
especially since what |q{ and -q{ do gives no clue from the
syntax.
You are right. My mind is just still not used to the power of
D templates so I didn't think of this. On the other hand that
is why D is still making me say "WOW!" on a regular basis :).
Just to confirm I understand, for example the following would
give me compile time stripping of white space:
template stripws(string l) {
enum stripws = l.replaceAll(regex("\s+", "g"), " ");
}
string variable = stripws(q{
whatever andever;
});
And I would get variable to be equal to " whatever and ever;
". Right?
Even better, you could write the same code that you would for
doing this at runtime and it'll Just Work:
string variable = q{
whatever and ever;
}.replaceAll(regex(`\s+`, "g"), " ");
I tried this but Disassembly view shows:
call std.regex.regex!string.regex
and
call std.regex.replaceAll!(string, char,
std.regex.internal.ir.Regex!char).replaceAll
which means that replaceAll with regex is done at runtime, not
compile time. Also when I just added enum in front of string
variable then I got this:
Error: malloc cannot be interpreted at compile time, because it
has no available source code
Re: Multiline string literal improvements
On Wednesday, 11 October 2017 at 08:35:51 UTC, Walter Bright
wrote:
On 10/10/2017 3:16 PM, sarn wrote:
Works even better in D because it can run at compile time.
Yes, I see no need for a language feature what can be easily
and far more flexibly done with a regular function - especially
since what |q{ and -q{ do gives no clue from the syntax.
You are right. My mind is just still not used to the power of D
templates so I didn't think of this. On the other hand that is
why D is still making me say "WOW!" on a regular basis :).
Just to confirm I understand, for example the following would
give me compile time stripping of white space:
template stripws(string l) {
enum stripws = l.replaceAll(regex("\s+", "g"), " ");
}
string variable = stripws(q{
whatever andever;
});
And I would get variable to be equal to " whatever and ever; ".
Right?
Multiline string literal improvements
D has a very nice feature of token strings:
string a = q{
looksLikeCode();
};
It is useful in writing mixins and to have syntax highlighting in
editors. Although I like it, it is not something I ever felt like
missing in other languages. What I do always miss are these two
options:
1. Have something like this:
string a = |q{
firstLine();
if (cond) {
secondLine()
}
};
mean count the number of whitespace characters at the start of a
first new line of string literal and then strip up to that many
whitespace characters from the start of each line.
2. If we just put for example "-" instead of "|" in above example
have that mean: replace all whitespace with a single space in
following string literal.
I think it is clear why would these be useful but if you want me
I can add a few examples. This would not make any breaking
changes to the language and it should be possible to simply
implement it wholly in the lexer.
So what do think?
Re: Go 1.9
Maybe I am wrong but I get a feeling from posts in this thread that some people are greatly underestimating the size of some segments, like mentioning niche C++ programmers and only 0.01% percent of developers needing memory management. The games industry is growing like crazy [1][2] and after all these years C++ is still the main language for that except that today 99% of those developers have many bad things to say about it. Imagine how D adoption would jump if someone created something on par with Unity or Unreal engine, or even Cocos engine in D. And I think D is already up to that task, with biggest pain points being only cross platform support, especially for Android and iOS. Also regarding the question whether D should be marketed as general purpose or some special purpose language I find this article [3] has it explained nicely, except that it seems to me language should be marketed as general but have strong libraries (or game engines) for specific purposes through which it should market itself as something specialized. [1] http://kotaku.com/nearly-40-of-all-steam-games-were-released-in-2016-1789535450 [2] http://www.gamasutra.com/view/news/267645/Over_500_games_now_submitted_to_iOS_App_Store_every_day.php [3] https://simpleprogrammer.com/2017/06/19/generalists-specialists/
Re: DMD VS2017 Support
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: VS 2017 uses a "private" registry that the Visual D installer doesn't have access to. I'll change the registry location in the next release. Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 That is great news! Thanks for quick response.
Re: DMD VS2017 Support
On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote: On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote: I should also mention that compiling using DUB works. It only doesn't work from VS. Check your VisualD settings and make sure it has DMD path set up. See under Tools>Options>Projects and solutions>Visual D Settings That was it. It didn't occur to me that this was the problem because I payed closed attention during VisualD installation and saw it properly recognized where DMD was installed but for some reason the path wasn't set in Options. Once I did set it, compile and build worked. Thanks evilrat! So in conclusion it seems the problem is in VisualD installation which doesn't set the path properly even though it recognizes where DMD is installed. Hope the author takes a look at this problem so beginners wanting to try D don't give up on a problem like this.
Re: DMD VS2017 Support
On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote: Here are mine, if it helps: I tried but still the same problem. I also tried reinstalling VisualD after changing sc.ini in DMD but that didn't help either.
Re: DMD VS2017 Support
On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote: On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote: I tried updating sc.ini to new paths but I still get this error. Can someone offer some advice? Which paths did you set? These are the ones I changed: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\ UCRTVersion=10.0.15063.0 LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64 LIB=%LIB%;"%VCINSTALLDIR%\lib\x64" Same for x86 environment, except, of course I replaced x64 with x86 in the values. I should also mention that compiling using DUB works. It only doesn't work from VS.
Re: DMD VS2017 Support
On Saturday, 22 April 2017 at 02:46:30 UTC, Mike Parker wrote: On Saturday, 22 April 2017 at 02:39:41 UTC, evilrat wrote: Also VS 2017 is much more modular now, so its now lighter than ever before. but of course for C++ (and D) you still need Windows SDK. The SDK stuff is installed with VS. IIRC D also can be used without VS or WinSDK at all, just forget about m32mscoff and x64 builds Yes, that is correct. But that comes with its own headaches. I had a working VS 2015 with VisualD and DMD. Today I uninstalled VS2015 and VisualD, then installed VS2017 and latest VisualD but when I create new D windows app and try to run it I get this error: Command Line set PATH=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;.\windows\bin;%PATH% dmd -g -debug -X -Xf"Win32\Debug\testapp.json" -deps="Win32\Debug\testapp.dep" -c -of"Win32\Debug\testapp.obj" winmain.d if errorlevel 1 goto reportError set LIB= echo. > D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo "Win32\Debug\testapp.obj","Win32\Debug\testapp.exe","Win32\Debug\testapp.map",ole32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo kernel32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo user32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo comctl32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo comdlg32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo user32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg "C:\Program Files (x86)\VisualD\pipedmd.exe" -deps Win32\Debug\testapp.lnkdep link.exe @D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg if errorlevel 1 goto reportError if not exist "Win32\Debug\testapp.exe" (echo "Win32\Debug\testapp.exe" not created! && goto reportError) goto noError :reportError echo Building Win32\Debug\testapp.exe failed! :noError Output Microsoft (R) Incremental Linker Version 14.10.25019.0 Copyright (C) Microsoft Corporation. All rights reserved. "Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+" kernel32.lib+ user32.lib+ comctl32.lib+ comdlg32.lib+ user32.lib+ kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS LINK : fatal error LNK1181: cannot open input file 'Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+' Building Win32\Debug\testapp.exe failed! I tried updating sc.ini to new paths but I still get this error. Can someone offer some advice?
Re: C++17
On Wednesday, 27 January 2016 at 05:28:56 UTC, Jack Stouffer wrote: On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote: What D lacks is organizational structure! It's akin to a bunch of kids programming in their bedrooms cobbling together stuff and being ecstatic that it works(for them at least). I'm going to chalk this up to lack of experience in volunteer based software projects. D is basically stagnate(bug fixes and piddly stuff don't count), which is pretty sad considering it looks to be a one of the best languages on the planet. This is absolutely ridiculous, I'm sorry, there's no other way to describe this. The sheer number of new language features, removals of bad ideas, and new library features makes C++ growth look glacial in comparison. I literally know of no other language than Python that has as quick a turnaround on new ideas than D has. Um, 1. I'm not comparing it to C++. 2. Compared to the explosion that D1 had several years ago and all the libraries that were create and all the work, D is relatively stagnate. Just because stuff is still happening doesn't mean anything. D has lost a lot of momentum in the Phobos\Tango mess and many of the eager programmers in D seemed to have moved on to greener pastures. It's been over 15 years since D's incarnation and one would expect it to be much much further along? "C was originally developed by Dennis Ritchie between 1969 and 1973". Within 10 years C as pretty much the defacto standard. Maybe D needs to create it's own OS built on an OOP foundation without all the pitfalls of modern windows, OSX and Linux? Maybe that will put it on the map.
Re: C++17
On Tuesday, 26 January 2016 at 21:21:53 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 21:15:07 UTC, rsw0x wrote: In any case where you attempt to write code in D that is equal in performance to C++, you must avoid the GC. Yes, I don't see why anyone should have to link in the GC if they don't want to use it. I think the leaders are in over their heads. They have no real vision or plan to make D the language it can be. They are satisfied with their niche in the programming world. They need a Steve Jobs type of person to make this stuff happen. Someone that understands what has to be done, in what order, and how to make it happen. What D lacks is organizational structure! It's akin to a bunch of kids programming in their bedrooms cobbling together stuff and being ecstatic that it works(for them at least). D is basically stagnate(bug fixes and piddly stuff don't count), which is pretty sad considering it looks to be a one of the best languages on the planet. If I said this stuff in North Korea I'd be hung!
Re: Fun with extern(C++)
On Tuesday, 26 January 2016 at 16:25:35 UTC, Benjamin Thaut wrote:
On Tuesday, 26 January 2016 at 16:13:55 UTC, Manu wrote:
Probably, but the layout of the vtable is defined by the
interface,
and the interface type is always known, so I don't see why
there
should be any problem. Whether it's extern(C++) or extern(D),
the
class populating the vtable with functions knows the layout.
I think it all comes down to this conversion to Object thing.
If an
interface must do that, then that's probably an issue without
jamming
an Object instance in the class somewhere.
For a C++ class the first entry in the vtable is actually the
first virtual function. (usually the destructor).
For a D class the first entry in the vtable is the classinfo.
Thus the problem if you derive a D class from a extern(C++)
base class. I don't see any way to actually fix this, adjusting
the this pointer won't help. Once you derive a D class from a
extern(C++) base class it is no longer a fully functional D
class. For example monitor (e.g. synchronized methods) won't
work.
Why couldn't D have been designed to extend the C++ class layout
with the vtable at the start and the new stuff at the bottom?
Would that have worked? If so, why not allow for a new class
layout like "extern(C++) class X { }"
Re: When is the Win API supported?
On Monday, 25 January 2016 at 18:40:14 UTC, Vladimir Panteleev wrote: On Monday, 25 January 2016 at 18:34:30 UTC, Igor wrote: [...] There currently aren't any. [...] The core.sys package mirrors various C system headers. As such, you can consult the C documentation instead. Though I agree, it would be nice to have at least an overview for each module. Feel free to file a bug or contribute. [...] core.sys.windows is a package (without a package.d), so you can't import it directly. You probably want to import core.sys.windows.windows, that will import most common headers (as described above, it is the equivalent of "#include "). Thanks. I see how it works now.
Re: When is the Win API supported?
On Monday, 25 January 2016 at 18:18:48 UTC, Vladimir Panteleev wrote: On Monday, 25 January 2016 at 18:09:47 UTC, Igor wrote: On Monday, 25 January 2016 at 02:21:49 UTC, Rikki Cattermole wrote: On 25/01/16 2:46 PM, Igor wrote: When will the proper Win API be included in D? About how long(months, years?)? Does it support seamless narrow and wide characters? I am not referring to the defunct win32 support already included. You mean the MingW based bindings that is in 2.070? https://github.com/D-Programming-Language/druntime/tree/v2.070.0-b2/src/core/sys/windows The only issue is for -m32 with import libs. I've included the .def files that came with the Win32 bindings, and added them to the build, so many import libs will be supported already. How do I use it? I can't find any docs on it(The D page, at least doesn't seem to have anything for windows in phobos except charset. When in C you would `#include `, in D you can `import core.sys.windows.foo;`, then just use it exactly like from C. Where are the docs for this? http://dlang.org/phobos-prerelease/index.html doesn't show anything about sys in core. I remember seeing somewhere that win32 api was included in dmd but that it wasn't working and was suppose to be updated. I would like to try it out but I can't find any working information about it. If I add `import core.sys.windows;` Dmd says `Error: module windows is in file 'core\sys\windows.d' which cannot be read`. I am using DMD Beta 2.070.0-b2 Thanks.
Re: Dmd sc.ini and VS do not work well together!
On Sunday, 24 January 2016 at 08:27:43 UTC, Igor wrote: On Sunday, 24 January 2016 at 05:34:18 UTC, Brad Anderson wrote: [...] Ok, I hope that it will be fixed because it seems like a rather simple issue(location issue). I can't know if there are any other problems until it is fixed. [...] When I added 'LIB=%LIB%;"C:\PF\Windows\Kits\10\Lib\10.0.10586.0\ucrt\x64"' to sc.ini, I was able to compile. The installer is not adding this path. The installer is not functioning properly for latest VS. By scanning for these folders, it should work. The installer needs a more generic and intelligent path finding system than the somewhat hard coded one it uses now. This will make it easier to maintain in the years to come.
Re: When is the Win API supported?
On Monday, 25 January 2016 at 02:21:49 UTC, Rikki Cattermole wrote: On 25/01/16 2:46 PM, Igor wrote: When will the proper Win API be included in D? About how long(months, years?)? Does it support seamless narrow and wide characters? I am not referring to the defunct win32 support already included. You mean the MingW based bindings that is in 2.070? https://github.com/D-Programming-Language/druntime/tree/v2.070.0-b2/src/core/sys/windows The only issue is for -m32 with import libs. How do I use it? I can't find any docs on it(The D page, at least doesn't seem to have anything for windows in phobos except charset.
When is the Win API supported?
When will the proper Win API be included in D? About how long(months, years?)? Does it support seamless narrow and wide characters? I am not referring to the defunct win32 support already included.
Re: Dmd sc.ini and VS do not work well together!
On Sunday, 24 January 2016 at 05:34:18 UTC, Brad Anderson wrote: On Saturday, 23 January 2016 at 21:38:19 UTC, Igor wrote: I feel like I am in the cave man times. I installed Dmd2 from scratch. VisualD x64 project would not compile due to libucrt.lib not being found. Sorry you are having trouble. The Universal CRT and Visual Studio 2015 are very new and I'm sure there are still some bugs to work out. Ok, I hope that it will be fixed because it seems like a rather simple issue(location issue). I can't know if there are any other problems until it is fixed. [snip] HKLM "Software\Microsoft\Windows Kits\Installed Roots" "KitsRoot10" Then searching for the latest UCRT version in a subdirectory. That's probably where the bug is. This is brand new detection however so it might be buggy. You can see how it works here: https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L379 Would you happen to know a better way to do this? [snip] The installer should be modernized and provide path information and resolve dependencies properly before installing. It is clear that dmd was not designed for windows use. We make updates to it pretty much every release cycle. We'd love some help making it bulletproof. Rock solid VS/Platform SDK detection is what we want but it's proved a bit trickier than expected (Microsoft has changed a few things up with different VS releases so there is not just one way to do it). Ok, I think you need to use all the reg keys in HKLM "Software\Microsoft\Windows Kits\Installed Roots" and search all valid paths for the proper files. In my case, if that was done, it would find the proper library files. Basically any subdirectory that has a lib file is a possible candidate for a lib path. This is the part! The hard part is to figure out which are the "correct" libs. One can check the libs for architecture. 32-bit libs folders are candidates for the 32-bit build and ditto for 64-bit. Out of those, one should determine debug versions and separate that, even though sc.ini doesn't seem to have this capability. Maybe it could be added and then dmd can choose the correct path for debug builds. After than, one will have duplicates due to versioning. One could try and partition down further, take the latest version, or present the user with options at this point. At the very least, the installer could add all possible path candidates to the sc.ini as comments so when one goes in and edits the file, they just have to try one at a time and not go bonkers looking for the paths. Also, allow the option to copy the lib files(and possibly VC linker files) into a subfolder to use instead. This way one can avoid even having to reinstall the kits or could uninstall them and still retain the libraries outside of the VS mess. This would avoid having to have multiple VS versions installed. A simple sc.ini reconfiguration tool or re-install/modify could then be used to select the different build varieties.
Re: Dub needs some additions
On Sunday, 24 January 2016 at 00:24:27 UTC, develop32 wrote: On Saturday, 23 January 2016 at 21:24:27 UTC, Igor wrote: Ah, yeah, that makes sense. To me personally setting project working directory to $(OUTDIR) when generating would be nice. Doesn't sound like a hard thing to do, I'll try making a pull request for that. I don't mind too much where it is put but I would just like it to work well and provide the standard build options to make life easy.
Re: Dmd sc.ini and VS do not work well together!
On Sunday, 24 January 2016 at 02:59:02 UTC, Mike Parker wrote: On Saturday, 23 January 2016 at 23:49:23 UTC, Igor wrote: If editing a configuration file is so difficult, you should use the installer. It will find your Microsoft tool installations and configure everything for you. Please don't parrot! I, Of course, used the installer and it didn't work, else why would I be here? The installer is obviously flawed, if you looked in to this you would see that it is the case.
Re: Dmd sc.ini and VS do not work well together!
On Sunday, 24 January 2016 at 00:46:32 UTC, Walter Bright wrote: Sucking the life force from D users is all the sustenance I need. Lol, ok! ;) Well, Sorry, I don't have much life force to give!
Re: Dmd sc.ini and VS do not work well together!
On Saturday, 23 January 2016 at 22:47:35 UTC, Walter Bright wrote: On 1/23/2016 1:38 PM, Igor wrote: As of now I personally cannot use dmd to build windows apps. You know, sc.ini is editable by you! Yes, But why do you expect me to be so smart or have a desire to waste my time looking for paths and such when YOU can write about 100 lines of code in about the same time it would take me to get sc.ini to work properly? There is a multiplicative factor here. If you do the work then it saves N people N hours of there life. If I do it, it wastes 1 hr of my life and helps no one! Please don't be a life thief! I know it takes your own life-hours to implement the code but you are the head D hauncho! Maybe hire someone or ask someone? You seem to have a following! If I actually knew what sc.ini really needed to work properly then I might do it myself, but it looks kinda crappy old win3.1 style stuff that never made much sense in the first place.
Re: Dmd sc.ini and VS do not work well together!
The installer should be modernized and provide path information and resolve dependencies properly before installing. It is clear that dmd was not designed for windows use. Also, sc.ini global variables should be at the top most section: [Environment] DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" LIB="%@P%\..\lib" These should be placed here instead of the individual sections as it creates redunancy and is bug prone: VCINSTALLDIR=C:\PF\VS2015\VC\ WindowsSdkDir=C:\PF\Windows Kits\8.1\ UniversalCRTSdkDir=C:\PF\Windows\Kits\10\ or even in [Version]
Dmd sc.ini and VS do not work well together!
I feel like I am in the cave man times. I installed Dmd2 from scratch. VisualD x64 project would not compile due to libucrt.lib not being found. Using Process Monitor, it seems that dmd is looking all over the place for libucrt.lib but can't find it. Check out sci.ini has some weird results. I have installed some windows kits and sdk's for win 8.1 and win 10 but I do not remember all the details. What I do know is that I have about 20 libucrt's in on my harddrive(global search). 1. The archaic sc.ini file gets things backwards. It uses VCINSTALLDIR before it is defined! This is the exact file generated on my system minus the comments: [Version] version=7.51 Build 020 ; environment for both 32/64 bit [Environment] DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" LIB="%@P%\..\lib" [Environment32] LIB="%@P%\..\lib" LINKCMD=%@P%\link.exe [Environment64] LIB="%@P%\..\lib64" DFLAGS=%DFLAGS% -L/OPT:NOICF LINKCMD=%VCINSTALLDIR%\bin\link.exe ;;; <<< UM, Where is VCINSTALLDIR? VCINSTALLDIR=C:\PF\VS2015\VC\ WindowsSdkDir=C:\PF\Windows Kits\8.1\ UniversalCRTSdkDir=C:\PF\Windows\Kits\10\ UCRTVersion=winv6.3 LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\bin LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64" LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64" LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64" LIB=%LIB%;"%WindowsSdkDir%\Lib\winv6.3\um\x64" LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64" LIB=%LIB%;"%WindowsSdkDir%\Lib\x64" LIB=%LIB%;"%DXSDK_DIR%\Lib\x64" [Environment32mscoff] LIB="%@P%\..\lib32mscoff" DFLAGS=%DFLAGS% -L/OPT:NOICF VCINSTALLDIR=C:\PF\VS2015\VC\ WindowsSdkDir=C:\PF\Windows Kits\8.1\ UniversalCRTSdkDir=C:\PF\Windows\Kits\10\ UCRTVersion=winv6.3 LINKCMD=%VCINSTALLDIR%\bin\link.exe PATH=%PATH%;%VCINSTALLDIR%\bin LIB=%LIB%;"%VCINSTALLDIR%\lib" LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x86" LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x86" LIB=%LIB%;"%WindowsSdkDir%\Lib\winv6.3\um\x86" LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x86" LIB=%LIB%;"%WindowsSdkDir%\Lib" LIB=%LIB%;"%DXSDK_DIR%\Lib\x86" Um, So, first off VCINSTALLDIR is used before defined!! Pretty basic bug here, should never have happened. Second, UCRTVersion is just wrong. I have no winv6.3 subdir. Windows 10 and VS2015 use some folder names like C:\PF\Windows\Kits\10\Lib\10.0.10150.0 and C:\PF\Windows\Kits\10\Lib\10.0.10240.0 Which contains the libucrt libs. It seems the installer is pretty ignorant of reality and almost surely not designed by someone that uses windows as a development platform. As of now I personally cannot use dmd to build windows apps. I imagine there are other people in similar situations with similar build setups. The installer should be modernized and provide path information and resolve dependencies properly before installing. It is clear that dmd was not designed for windows use.
Re: Dub needs some additions
On Saturday, 23 January 2016 at 20:54:36 UTC, develop32 wrote: On Saturday, 23 January 2016 at 20:24:05 UTC, Igor wrote: Some simple extensions to dub are required for proper windows support: 1. The Ability to generate full build selections for Visual D. I only get Win32 when using `dub generate VisualD`. Win64 support should be added, along with alternate compiler support. (GDC and LDC) dub generate visuald --arch=x86_64 etc. You have to use flags to configure the project. No, I am talking about adding the different build options inside the visual studio project. When one generates the project, it should add the 64bit build options regardless. It is a standard with all Visual Studio projects in C++, C#, and VB. It should not require a flag to set. It doesn't change the architecture but only provides a simple build option. When I use the flag, I only get 64... I want both!!! I should be able to switch seemlessly between 64-bit and 32-bit by using the configuration manager/combo box like every other normal project in VS has as default. 2. The ability to refresh a project by adding new dependencies and files to the previously generate Visual D project. It should retain modified settings of the project file. I'm thinking of something like `dub refresh VisualD` would work. Yeah, that would be nice. The current generate settings are just child's toys without the ability to retain and update project info. Thank You.
Dub needs some additions
Some simple extensions to dub are required for proper windows support: 1. The Ability to generate full build selections for Visual D. I only get Win32 when using `dub generate VisualD`. Win64 support should be added, along with alternate compiler support. (GDC and LDC) 2. The ability to refresh a project by adding new dependencies and files to the previously generate Visual D project. It should retain modified settings of the project file. I'm thinking of something like `dub refresh VisualD` would work. The current generate settings are just child's toys without the ability to retain and update project info. Thank You.
Representation of a tree
Hello,
I want to represent a tree node in D. I think if struct works for
it:
struct Node {
Node* l, r;
}
But can I use pointers? Will GC treat them properly? I'm leaning
to think it should be okay.
Auto and empty array
In case I want to create a new array with size I know, it's very convenient to use auto: auto a = new int[](13); But if I want to create a new, empty array? Then using auto is not convenient and I have: auto a = new int[](0); It seems a bit bloated, compared to int[] a = []. I like using auto because of uniform syntax and other reasons. Is there any concise way to create a new empty array with auto?
Re: sscanf replacement in D
On Monday, 16 June 2014 at 01:08:33 UTC, safety0ff wrote: On Monday, 16 June 2014 at 01:05:46 UTC, Igor wrote: Hi, I came to D from the C++ world. What is sscanf replacement? std.streams seems deprecated, std.stdio doesn't offer something like readf for string. What should I use? std.format is one option: http://dlang.org/phobos/std_format.html#.formattedRead Thanks, it's exactly I was looking for.
sscanf replacement in D
Hi, I came to D from the C++ world. What is sscanf replacement? std.streams seems deprecated, std.stdio doesn't offer something like readf for string. What should I use?
