Re: Visual D doesn't work, now Visual Studio Code / D doesn't work!!!! ....
On 02/10/2022 13:00, Daniel Donnell wrote: Visual D doesn't work - it just ate my app.obj file and can't find it anymore no matter if I clean or re-order the executable paths in settings. Can you be more specific what you are doing and what is going wrong? On 02/10/2022 23:28, rikki cattermole wrote: > Visual Studio with its c++ components can debug D code, it should not > require Visual D to do so. > > Open executable as project. Or start "devenv program.exe" from the command line. Indeed, you don't have to build with Visual D to use the debugger. The C++-only native debugger works, but having Visual D installed also comes with a debugger extension that makes debugging smoother, e.g. you don't have to know the respective C++ syntax for watch expressions. BTW: Using compiler options -gf instead of -g will add more debug info and can improve the debug experience.
Re: Visual D showing weird errors
On 26/04/2021 20:22, Imperatorn wrote: > On Monday, 26 April 2021 at 17:37:26 UTC, Rainer Schuetze wrote: >> >> On 26/04/2021 10:00, Raimondo Mancino wrote: >>> [...] >> >> The problem is that the semantic engine used by Visual D is working >> with the DMD frontend of 2.095, but "noreturn" is a new language >> feature introduced with 2.096. >> >> You can filter out messages from "Intellisense" in the Error List >> window by selecting to show "Build only". >> >> I hope I can supply a new version of Visual D with an updated semantic >> engine soon. > > That would be awesome There is a new version 1.1.1 available now with the semantic engine updated to dmd 2.096.1.
Re: Visual D showing weird errors
On 26/04/2021 10:00, Raimondo Mancino wrote: > Hello, I'm new to the language; I just started learning it a few months > ago. I'm doing okay with it, I find it very versatile and fast to learn. > I come from Java and C/C++ and I think D solves tons of problems I had > with these. > > I was trying the Visual D extension to Visual Studio, but after the > first code generation (DLL library, x86 & x64 both checked), I get this > weird error: > > ``` > C:\D\dmd2\src\druntime\import\core\sys\windows\dll.d: > \object.d(18): can only `*` a pointer, not a `typeof(null)` > ``` The problem is that the semantic engine used by Visual D is working with the DMD frontend of 2.095, but "noreturn" is a new language feature introduced with 2.096. You can filter out messages from "Intellisense" in the Error List window by selecting to show "Build only". I hope I can supply a new version of Visual D with an updated semantic engine soon.
Re: DMD 2.090.1: SIGILL, Illegal instruction on (ahem) intel Pentium III
On 27/02/2020 11:30, kdevel wrote: > On Thursday, 27 February 2020 at 07:44:57 UTC, Seb wrote: >> On Thursday, 27 February 2020 at 00:36:49 UTC, kdevel wrote: > > [...] > >>> Program received signal SIGILL, Illegal instruction. > > [...] > >>> Does this exception relate to [1] and shall I file a bug or do I have >>> to decommission my PIII? > > [...] > >> I think so. > > File a bug report? > >> Have you tried: >> 1) LDC on your machine? > > Not yet. > >> 2) the DMD version before this change? > > 2.086.1 good > 2.087.0 bad > >From the 2.087 changelog: "32 Bit Linux now uses XMM registers for float and double rather than the x87. This should substantially speed up routine float and double processing. SIMD vector operations, however, are still not support on 32 bit Linux code because of issues with 16 byte stack alignment. This means that generated code will no longer work on older x86 processors that do not have XMM registers. If this is an issue, please file a bug report."
Re: can't run D app on VS 2019
On 27/02/2020 12:29, Greatsam4aure wrote: > I have install Vs 2019 and install the C++ package together with > Visual-D bundle with DMD and LDC. But by project refuse to run > > -- Build started: Project: DLangOne, Configuration: Debug Win32 -- > Building Win32\Debug\DLangOne.exe... > LINK : fatal error LNK1181: cannot open input file 'user32.lib' > Building Win32\Debug\DLangOne.exe failed! > Details saved as > "file://C:\Users\great\source\repos\DLangOne\Win32\Debug\DLangOne.buildlog.html" > > == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == > Did you also install the Windows SDK? According to your build log, I would expect user32.lib to be in folder "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86", but it is not listed on the command line. If it exists, then maybe auto-detection didn't work or has old settings. Try the "Reset Settings..." on the global Visual D option page or manually add the library search path in the DMD directories->Win32-COFF tab.
Re: can't run D project on Visual studio
On 13/02/2020 15:54, Akomire Samson wrote: > I am having this error on running D project using Visual studio 2019 and > Visual D > > > Build Log > > Building Win32\Debug\LearningD.exe > > Command Line > > set PATH=C:\D\ldc2-1.19.0-windows-multilib\bin;C:\Program Files > (x86)\Microsoft Visual > Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64;C:\Program > Files (x86)\Microsoft Visual > Studio\2019\Community\Common7\IDE;C:\Program Files (x86)\Windows > Kits\10\bin;%PATH% > set LIB=C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86;C:\Program Files > (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x86 > set VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\VC\ > set VCTOOLSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\VC\Tools\MSVC\14.24.28314\ > set VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\ > set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\ > set WindowsSdkVersion=10.0.18362.0 > set UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\ > set UCRTVersion=10.0.18362.0 > "C:\Program Files (x86)\VisualD\pipedmd.exe" -deps > Win32\Debug\LearningD.dep ldc2 -m32 -g -d-debug -X > -Xf="Win32\Debug\LearningD.json" -of="Win32\Debug\LearningD.exe" > -L/PDB:"Win32\Debug\LearningD.pdb" -L/SUBSYSTEM:CONSOLE -L/noopttls > -od="Win32\Debug" LearningD.d > if %errorlevel% neq 0 goto reportError > if not exist "Win32\Debug\LearningD.exe" (echo > "Win32\Debug\LearningD.exe" not created! && goto reportError) > > goto noError > > :reportError > echo Building Win32\Debug\LearningD.exe failed! > > :noError > Output > > LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' > Error: C:\Program Files (x86)\Microsoft Visual > Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\link.exe > failed with status: 1181 > Building Win32\Debug\LearningD.exe failed! > > > > I will appreciate any help. Maybe you don't have a Windows SDK installed? With the settings as shown above, kernel32.lib would be expected to exist in "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86". If that looks ok, maybe it has to do with using LDC to do the linking. Does it work when using DMD instead? Or try compilation model "Separate compile and link".
Re: D create many thread
On 07/02/2020 16:52, Steven Schveighoffer wrote: > But I still maintain, a hello world program should not need this to > avoid spawning 6 threads to scan itself. I agree, see https://issues.dlang.org/show_bug.cgi?id=20567 and https://github.com/dlang/druntime/pull/2933
Re: format with floating points GC allocating in DMD 2.090
On 31/01/2020 09:45, bauss wrote:
> On Friday, 31 January 2020 at 07:20:17 UTC, cc wrote:
>> char[4096] buf;
>> writeln(GC.stats.usedSize);
>> foreach (i; 0 .. 10) {
>> sformat(buf, "%f", 1.234f);
>> writeln(GC.stats.usedSize);
>> }
>>
>> Output with DMD32 D Compiler v2.089.1-dirty (Win10 x64):
>> 16
>> 16
>> 16
>> ...
>>
>> Output with DMD32 D Compiler v2.090.0-dirty:
>> 16
>> 848
>> 1664
>> 2480
>> 3296
>> 4112
>> 4944
>> 5760
>> 6576
>> 7392
>> 8208
>
> Report it as a bug because it's definitely a bug and there was changes
> to the GC in 2.090.0
It's a change in std.format: https://issues.dlang.org/show_bug.cgi?id=20566
Re: GC.collect inflating memory usage?
On 07/12/2019 21:05, Rainer Schuetze wrote: > > On 07/12/2019 12:20, cc wrote: >> Given the following program: > [...] >> >> Using DMD32 D Compiler v2.089.0-dirty >> > > Seems like a bug introduced in dmd 2.086, I've created a bugzilla issue: > https://issues.dlang.org/show_bug.cgi?id=20438 > > I suspect there is something broken with respect to the free-lists > inside the GC when manually freeing memory :-/ > Fixed in stable for the next point-release.
Re: GC.collect inflating memory usage?
On 07/12/2019 12:20, cc wrote: > Given the following program: [...] > But when both FREE and COLLECT are enabled, things seem to spiral out of > control: > // FREE, COLLECT > Stats(16, 1048560, 16) > 848 4096 > 40960832 40964096 > 81920832 81924096 > 122880832 122884096 > 163840832 163844096 > 204800832 204804096 > 245760832 245764096 > 286720832 286724096 > 327680832 327684096 > 368640832 368644096 > Elapsed: 29143 ms > > I wouldn't normally call GC.collect on every frame in my application, > but I'm curious why this is happening and if there is unnecessary bloat > being added somehow when I do choose to call GC.free manually and > garbage collection later occurs in a long-running program. Ideally I'd > like to free up as many objects and arrays as soon as they become unused > to avoid lengthy collections reducing performance. I know that > std.container.array is one alternative to using D's GC-managed dynamic > arrays, but could I run into the same issue when trying to manually > deallocate class objects as well? > > Using DMD32 D Compiler v2.089.0-dirty > Seems like a bug introduced in dmd 2.086, I've created a bugzilla issue: https://issues.dlang.org/show_bug.cgi?id=20438 I suspect there is something broken with respect to the free-lists inside the GC when manually freeing memory :-/
Re: Exceptions on Windows being "swallowed"
On 27/11/2019 06:55, cartland wrote:
> On Wednesday, 27 November 2019 at 05:43:33 UTC, Mike Parker wrote:
>> On Wednesday, 27 November 2019 at 05:15:10 UTC, cartland wrote:
>> *snip*
>>
>> dmd -m32mscoff -debug -g x.d
>>
>> And see what happens.
>
> No difference between "dmd -m32mscoff -debug -g x.d" and "dmd -m32mscoff
> x.d"
>
>
> C:\tmp\x>dmd -m32mscoff -debug -g x.d
>
> C:\tmp\x>x
> hello
>
> C:\tmp\x>dmd x.d
>
> C:\tmp\x>x
> hello
> finally
> catch first
> done
> --
>
> x.d contents
>
> import std.stdio;
> void main() {
> writeln("hello");
> try {
> try {
> throw new Exception("first");
> } finally{
> writeln("finally");
> throw new Exception("second");
> }
> } catch (Exception e) {
> writeln("catch ", e.msg);
> }
> writeln("done");
> }
> ---
>
In a debugger, I get:
Unhandled exception at 0x004010EF in x.exe: 0xC1A5: An invalid
exception handler routine has been detected (parameters: 0x0001).
This seems to happen when lld is used instead of the Microsoft linker.
Maybe related: https://bugs.llvm.org/show_bug.cgi?id=42221
Using lld from LLVM 9 spits out errors "not compatible with SEH", but
links using /SAFESEH:NO. The resulting executable then works.
I have created an issue: https://issues.dlang.org/show_bug.cgi?id=20421
Re: want to know precise GC benchmarks
On 01/10/2019 18:24, a11e99z wrote: > On Tuesday, 1 October 2019 at 16:12:18 UTC, a11e99z wrote: >> does anybody some kind of benchmark to test conservative and precise GC? >> precise GC is better or not? is STW improving? Without false pointers the precise GC is usually a bit slower (by a few %) due to additional work being done during allocations. But it can be a lot faster if there are false pointers that pin large amounts of memory still needed to be scanned during collections. False pointers are more likely for 32-bit processes, but can also happen with 64-bit processes (also depending on addresses used by OS allocations: OSX worse than Windows worse than Linux). > > and another question about GC and app parameters: >> program.exe “–DRT-gcopt=gc:precise parallel:4” >> “–DRT-scanDataSeg=precise” output.data > are this 2 -DRT params combined or overwriting each other? > link to doc for DRT+GC https://dlang.org/spec/garbage.html#gc_config These options are independent and can be used in arbitrary order. The last option wins if you actually overwrite an option, e.g. '“–DRT-gcopt=gc:precise parallel:4” “–DRT-gcopt=parallel:7”' will still use the precise GC, but 7 mark threads. Please note that “–DRT-scanDataSeg=precise” is only supported on Windows. > > I know about rt_options[] but asking about program args > > why I want to know such info? > CodinGame sometimes use time-limit for bot move for example 100ms, and > bot will be disqualified in case no answer There is no actual upper limit for the collection time, it mostly depends on how much life memory has to be scanned.
Re: Newbie linker errors - still missing _fltused _tls_index _tls_used localtime tzset mainCRTStartup
On 08/09/2019 00:30, malpropism wrote: > I just ported my Java application to D, got it to compile, but not to link. > > I'm using Windows 10 64 bit, DMD 2.088.0 , Visual D 0.50.1. This would > be a C/C++ project in Visual Studio with only D code. > > With my first attempt, I'm missing 65 externals, 328 errors. > > I added these two files > > ucrt.lib > vcruntime.lib > > to the Additional Dependencies in the linker property pages and have my > missing external count down to 6, 70 errors. > > I'm missing the following 6 symbols: > > _fltused _tls_index _tls_used localtime tzset mainCRTStartup > > What other libs would I need to add to the linker's additional > dependencies? I suspect you have disabled the C runtime library selection in the D compilation options to build against the shared C runtime DLLs (you can select that, too). Or your code might be missing a main function in which case the selection might not be embedded into any object file. In this case, you should add msvcrt.lib instead of vcruntime.lib. Depending on used functionality you will also need legacy_stdio_definitions.lib.
Re: precise GC
On 05/03/2019 22:30, H. S. Teoh wrote: > On Tue, Mar 05, 2019 at 09:50:34PM +0100, Rainer Schuetze via > Digitalmars-d-learn wrote: >> On 04/03/2019 12:12, KnightMare wrote: > [...] >>> 3) closures: do the closures have any internal types that helps to >>> GC or are they (full closure memory block) scanned as in the >>> conservative mode? >> >> No type information is generated for closures by the compiler, so >> these are always scanned conservatively. > [...] > > Just out of curiosity, how hard would it be for the compiler to emit > type information for closures? Given the prevalence of the range-based > idiom in D, I'd think this is a worthwhile area for GC improvements. I tried that first when I added debug information for closures on Windows recently, but it didn't easily work out. I suspect it cannot be generated early in the front-end as closures might also change due to inlining and optimizations. Maybe even worse than the conservative scanning: if structs are moved into the closure, their destructors are never called, even if the closure is collected.
Re: precise GC
On 04/03/2019 12:12, KnightMare wrote: > For example, we have some rooted memory block as > auto rooted = new long[1_000_000]; > 1) conservative-GC will scan it for false pointers every GC-cycle. is it > true? > 2) precise-GC will NOT scan it at all. is it true? As Adam pointed out, this memory block is neither scanned by the default GC nor the precise GC because they don't contain any references. > > 3) closures: do the closures have any internal types that helps to GC or > are they (full closure memory block) scanned as in the conservative mode? No type information is generated for closures by the compiler, so these are always scanned conservatively. > > 4) associative arrays: > SomeTypeWithRefsToClasses[string] > any pair will be allocated at some memory block [hash, key, value] as I > imagine. > Will be precise-GC scan at every pair block only some fields of > SomeTypeWithRefsToClasses or full [pair-block]? > will be scanned string-key memory block: span-struct and\or chars data? associative arrays use allocations containing both key and value. These are scanned as if they are combined to a struct, so only actual pointers with the precise GC, semi-precisely (as Adam put it) with the default GC.
Re: Bug in shifting
On 14/12/2018 02:56, Steven Schveighoffer wrote:
> On 12/13/18 7:16 PM, Michelle Long wrote:
>> byte x = 0xF;
>> ulong y = x >> 60;
>
> Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
It doesn't work as intuitive as you'd expect:
void main()
{
int x = 256;
int y = 36;
int z = x >> y;
writeln(z);
}
prints "16" without optimizations and "0" with optimizations. This
happens for x86 architecture because the processor just uses the lower
bits of the shift count. It is probably the reason why the language
disallows shifting by more bits than the size of the operand.
Re: Performance of GC.collect() for single block of `byte`s
On 01/10/2018 15:51, Steven Schveighoffer wrote: On 10/1/18 3:21 AM, Rainer Schuetze wrote: A profiler reveals that most of the time is spent in "sweeping" the memory, i.e. looking for allocations no longer referenced. The existing implementation checks every page which causes a linear growth of required CPU resources with used memory. Ouch! I hadn't thought of that. But we aren't checking actual *pages*, right, we are checking bits to see where allocations are present? It is not touching the pages, but a byte array classifying the page as free, used and first of a used block. I also remember that the way the bitsets work, they are always allocated for every 16 bytes, regardless of the block size for that page/pool. I didn't love that feature but maybe it is fixed by now. Not for the pool for "large" objects, it uses bits per page there. For small object pools, it's still as you remember. I would imagine that checking 64 pages at once should be possible by logic-anding the allocated and unmarked bits to check things as quickly as possible. With my patch, the number of pages of allocated blocks and regions of consecutive free pages are known (by consulting another array), so no bit-scanning is necessary.
Re: Performance of GC.collect() for single block of `byte`s
On 28/09/2018 14:21, Per Nordlöw wrote: On Monday, 24 September 2018 at 14:31:45 UTC, Steven Schveighoffer wrote: It's not scanning the blocks. But it is scanning the stack. Each time you are increasing the space it must search for a given *target*. It also must *collect* any previous items at the end of the scan. Note that a collection is going to mark every single page and bitset that is contained in the item being collected (which gets increasingly larger). Is this because of the potentially (many) slices referencing this large block? I assume the GC doesn't scan the `byte`-array for pointer-values in this case, but that happens for `void`-arrays and class/pointer-arrays right? Couldn't that scan be optimized by adding a bitset that indicates which pages need to be scanned? Is it common for GC's to treat large objects in this way? A profiler reveals that most of the time is spent in "sweeping" the memory, i.e. looking for allocations no longer referenced. The existing implementation checks every page which causes a linear growth of required CPU resources with used memory. This version https://github.com/rainers/druntime/tree/gc_opt_sweep takes advantage of the known size of allocations to skip unnecessary checks. The last commit also adds support for keeping track of the size of blocks of consecutive free pages. With this your example has more or less constant collection time (note that most of the program time is spent setting the array to zero, though not measured, and that the allocation often triggers a collection, too). I also noticed a rather serious bug for huge allocations: https://issues.dlang.org/show_bug.cgi?id=19281
Re: How to use LLD linker?
On 06/07/2018 05:48, SrMordred wrote: On Saturday, 30 June 2018 at 10:48:49 UTC, Suliman wrote: Correct me if I am wrong, but I have read news that dmd now can be used without C++ Build Tools. I trying to build simple project. And getting Error: Warning: no Visual C++ installation detected OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Error 8: Illegal Filename ... Error: C:\D\dmd2\windows\bin\link.exe failed with status: 1 ldc2 failed with exit code 1. Same with dmd. How to use LLD linker? Well I just installed the VS 2017 to try the ldc and get (maybe) the same error. dub run --config=application --arch=x86_64 --build=debug --compiler=ldc2 Performing "debug" build using ldc2 for x86_64. lib ~master: building configuration "application"... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Error 8: Illegal Filename /NOLOGO /DEBUG /OPT:REF /OPT:ICF /DEFAULTLIB:libcmt /DEFAULTLIB:libvcruntime "/OUT:.dub\build\application-debug-windows-x86_64-ldc_2081-FC0CCB721F0C7E0D58B93FB1E50E3401\lib.exe" ".dub\obj\lib.obj" "d:\ldc2\lib\ldc_rt.builtins.lib" /LIBPATH:d:/ldc2/bin/../lib phobos2-ldc.lib druntime-ldc.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib ^ Error: d:\D\dmd2\windows\bin\link.exe failed with status: 1 ldc2 failed with exit code 1. The problem is that the Digital Mars linker is called but the Microsoft linker is run, because they share the same name link.exe. For dmd/x64/32mscoff or LDC in general the latter is expected to be used. Usually dmd and ldc know how to find the appropriate one, but dub might just expect it to be found through the PATH environment variable. So, try to set your PATH so that the MS linker is found first.
Re: Visual D 0.47.0 released
On 27/06/2018 12:37, Robert M. Münch wrote: On 2018-06-27 06:22:19 +, Rainer Schuetze said: - Windows-10, 64bit, running in a Parallels VM on OSX 10.13.5 - VS-2017 latest patch applied If you try to debug 64-bit-builds, mago starts another monitoring process. Maybe there are issues with this in the Parallels VM. Please note that there is no need to select the Mago debug engine in VS2013 or later. Since a couple of versions of Visual D, the VS debugger is equipped with an extension based on Mago that can evaluate D expressions. Ok, so maybe the problem is related to changing the selection via the drop-down box in the project properties. If I use "Visual Studio" things work. If I switch to "Mango" things don't work. WRT: D expressions. I saw that variables inside a foreach body, where an opApply is used, are not visible in the debugger. I get a "symbol not found" message. Not sure if this is bacause of the foreach body beging used as a delegate? Delegate literals are problematic if the variables are declared outside of delegate: dmd doesn't emit debug info for these. LDC is often better in that regard.
Re: Visual D 0.47.0 released
On 26/06/2018 16:25, Robert M. Münch wrote: On 2018-06-24 13:08:53 +, Rainer Schuetze said: a new release of Visual D has just been uploaded. Major changes are * improved Visual C++ project integration: better dependencies, automatic libraries, name demangling * new project wizard * mago debugger: show vtable, dynamic type of interfaces, symbol names of pointer address As soon as I use the Mago debugger, it's impossible to start a debugging session. Any idea how to track down such a problem? Works for me, can you give more details? VS version, platform, etc. Please note that there is no need to select the Mago debug engine in VS2013 or later. Since a couple of versions of Visual D, the VS debugger is equipped with an extension based on Mago that can evaluate D expressions.
Re: "Start a Minimal web server" example do not work.
On 08/05/2018 21:36, BoQsc wrote: On Tuesday, 8 May 2018 at 19:19:26 UTC, Seb wrote: On Tuesday, 8 May 2018 at 18:40:34 UTC, BoQsc wrote: On Tuesday, 8 May 2018 at 18:38:10 UTC, BoQsc wrote: On Tuesday, 8 May 2018 at 17:35:13 UTC, Jesse Phillips wrote: [...] Tested with these versions so far, and had all the same errors: C:\Users\Vaidas>dmd --version DMD32 D Compiler v2.079.1 C:\Users\Vaidas>dub --version DUB version 1.8.1, built on Apr 14 2018 C:\Users\Vaidas>dmd --version DMD32 D Compiler v2.080.0 C:\Users\Vaidas>dub --version DUB version 1.9.0, built on May 1 2018 Linking... C:\D\dmd2\windows\bin\lld-link.exe: warning: eventcore.lib(sockets_106c_952.obj): undefined symbol: SetWindowLongPtrA C:\D\dmd2\windows\bin\lld-link.exe: warning: eventcore.lib(sockets_106c_952.obj): undefined symbol: GetWindowLongPtrA error: link failed Error: linker exited with status 1 C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. Unfortunately, the MinGW version that the replacement libraries are built from omit this symbol. Please file a bug report. For Win32 (--arch=x86_mscoff) this symbol is aliased to SetWindowLongA which should be fine. That's with DMD's bundled LLD linker. Have you tried: 1) installing MS Visual Studio (as others have mentioned their linker works) 2) Using LDC (they usually ship a newer version of the LLD linker) I have installed the one suggested by the dmd-2.080.0.exe installer: Microsoft Visual Studio Community 2017 Version 15.7.0 VisualStudio.15.Release/15.7.0+27703.1 Microsoft .NET Framework Version 4.7.02556 What you actually need is Visual C++ (linker and runtime libraries). For the missing symbol above you also need the Windows SDK which is usually included in the Visual C++ installation.
Re: How to compile for Win64 with Visual D? Optlink error?
On 19.09.2017 13:47, Timothy Foster wrote: I'm trying to compile my project as a Win64 application but this is happening: Building C:\Users\me\test\test.exe... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 183: Extension not .RES : obj\debug\dummy\test\..\source\c.obj obj\debug\dummy\test\..\source\b.obj(1) : Error 52: .DEF Syntax Error d†šöñÀY$@ ^ Building C:\Users\me\test\test.exe failed! I'm on a Win64 machine and compiling Win32 works fine. I'm using Visual Studio 17 Community with Visual D. DMD is up to date as is Visual D. I added a x64 "solution platform" to the configuration manager which added a -m64 flag to my linker options. I'm not sure what else I'm meant to do to get it to compile as x64? That usually happens if the DMD bin folder is searched first in the PATH variable (unfortunately the linker and other tools have the same name as the Microsoft programs). You should verify that the VC folder is listed first in Tools->Options->Projects and Solutions->Visual D Settings->DMD Directories->x64->Executable Paths, i.e. $(VCTOOLSINSTALLDIR)bin\HostX86\x86 should be listed before $(DMDInstallDir)windows\bin
Re: Profiling Windows App and DLL
On 17.07.2017 22:36, Igor wrote: Is there a known limitation in profiling these or am I doing something wrong? When I try to run my application from VisualD (x64 build) with -profile switch I just get Access Violation reported on WinMain function (actual declaration, it doesn't enter its body). If I build it with dub build --build=profile and then try to run it nothing happens, like it doesn't run at all. If I only add -profile switch on DLL part of the application I get the same Access Violation on DllMain. The problem seems to be that the compiler only excludes C main from being instrumented for profiling. This causes WinMain/DllMain to also call the tracing functions before the runtime had a chance to be initialized by Runtime.initialize(). A workaround could be to compile the respective module without -profile, and then link it as an object file to the rest of the code. I also tried "Very Sleepy" profiler but it only shows symbols for main application and not for the DLL that it loads which is also built with debug info. You can also use the "Performance profiler" from within Visual Studio.
Re: Finding source of typeid use
On 08.07.2017 07:55, Nicholas Wilson wrote: On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote: On 08/07/2017 2:35 AM, Nicholas Wilson wrote: On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote: My library is generating a typeid from somewhere. e.g. typeid(const(Pointer!(cast(AddrSpace)1u, float))) [...] It seems to be coming from the need to hash the type, goodness knows why, which explains why I only get the const variety. https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe? No, the culprit is https://github.com/dlang/druntime/blob/master/src/object.d#L1128 but IDK why it is being generated in the first place since nothing I wrote relies on being able to hash it. I suspect this is generated while building the hash function for your Pointer struct in buildXtoHash in ddmd/clone.d.
Re: Getting DUB to work with VS 2017
On 22.05.2017 03:54, Enjoys Math wrote: [...] C:\Users\Gabe\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\\infrastructure\windows\python27_digitalmars.lib+ user32.lib+ kernel32.lib/NOMAP/CO/NOI/DELEXE LINK : fatal error LNK1181: cannot open input file 'obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\source\led_ux_grammar.obj+' Building C:\Users\Gabe\Dropbox\MyProjects\___SOUND_UNITED\LED_UX_Designer\lang\PEGparser\PEGparser.exe failed! Details saved as "file://C:\Users\Gabe\Dropbox\MyProjects\___SOUND_UNITED\LED_UX_Designer\lang\PEGparser\.dub\obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\pegparser.buildlog.html" == Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped == This looks like the wrong link.exe has been found in path. When building for Win32/x86 the default is to use optlink that is installed with dmd. The error message is issued by MS link instead. I suspect the DMD installation folder is not set correctly (check Tools->Options->Projects and Solutions->Visual D Settings->DMD directories). Please also check the executable search paths below, they should include "$(DMDInstallDir)windows\bin". There was a bug in Visual D 0.44.0 where a bad character sneaked into the path to DMD's bin folder. > Opening any of the dub.json files with red X's opens them, but then immediately crashes VS. The red cross means it's not part of the build, so that's correct. The crash is not ok. I can reproduce it, seems to happen due to a function not being implemented (which seems fine for other files).
Re: How to setup DLL and EXE projects in one VS solution
On 18.05.2017 09:53, Igor wrote: On Thursday, 18 May 2017 at 07:10:54 UTC, Rainer Schuetze wrote: You have to add an import path to the folder with dllproj inside to the project configuration of the exeproject. If you want to limit the imported code to the declarations, you can enable "generate interface headers" and add an import path to these instead. Sharing data or resources between executable and DLL is currently limited to separate ownership as each binary contains its own copy of the runtime. (There is currently work being done to have a shared runtime, though). You might also run into other cross module dependencies... I tried just adding import paths to project and to di files and although compilation passes I still get link errors like: error LNK2019: unresolved external symbol _D10handmade_h10game_input6__initZ (handmade_h.game_input.__init) referenced in function _D8platform5win324main9myWinMainFPvPvPaiZi (int platform.win32.main.myWinMain(void*, void*, char*, int)) That's what I meant with "other cross module dependencies". In this case it might work if you export _D10handmade_h10game_input6__initZ from your DLL with the help of a def-file, but that's not something that scales well. This talk will give you some details on the complications involved: https://www.youtube.com/watch?v=MQRHxI2SrYM
Re: How to setup DLL and EXE projects in one VS solution
On 17.05.2017 18:56, Igor wrote: At the moment I have: EXEProject: app.d - it does loadlibrary of dllproj and uses data structures defined in dllproj.d (it imports dllproj). On the file system this file is under /platform/win32/ and is defined as module win32.app; DLLProject dllproj.d - exports functions and contains data structures those function use. On file system this file is under /source and is defined as module dllproj; EXEProject depends on DLLProject. DLL project compiles and builds DLL fine but, of course EXE project breaks with an error: module dllproj is in file dllproj.d which cannot be read. I could just copy all the structs from dllproj.d to app.d and remove the import and I guess it would all work but there has to be a better way to structure code so structs are only written in one place? You have to add an import path to the folder with dllproj inside to the project configuration of the exeproject. If you want to limit the imported code to the declarations, you can enable "generate interface headers" and add an import path to these instead. Sharing data or resources between executable and DLL is currently limited to separate ownership as each binary contains its own copy of the runtime. (There is currently work being done to have a shared runtime, though). You might also run into other cross module dependencies...
Re: TLS
On 13.03.2017 14:35, M-exe wrote: On Friday, 10 March 2017 at 21:32:05 UTC, sarn wrote: On Friday, 10 March 2017 at 19:24:29 UTC, bauss wrote: Mark your variables with __gshared. I would say shred, but it has some restrictions to it, where __gshared is the equivalent to global variables in C. immutable variables are also not put in TLS. Thank you for yours replys but there is a tls directory even when I compile empty main.. It's very likely that there are TLS variables in druntime that are linked in. You can identify them by looking at the map file.
Re: Adding linker paths with spaces using dmd and msvc toolchain
On 30.12.2016 19:24, Jeremy DeHaan wrote: On Friday, 30 December 2016 at 04:56:59 UTC, Jerry wrote: On Friday, 30 December 2016 at 03:51:13 UTC, Jeremy DeHaan wrote: How does one correctly add a linker path that has spaces? The quotes get consumed by the command line. The way DMD spawns the linker by creating a new string with all the flags. Does this happen on other platforms too? There has to be a GOOD way to pass a linker path that has spaces. Should this be considered as a bug? Not sure if it qualifies as "GOOD", but this works: dmd -m64 "-L/LIBPATH:\"path with spaces\"" main.d
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 08.09.2016 20:15, Rainer Schuetze wrote: On 08.09.2016 19:35, Tofu Ninja wrote: On Thursday, 8 September 2016 at 07:45:56 UTC, Rainer Schuetze wrote: Fixed it again. You can find a prebuilt binary of pipedmd.exe here: https://ci.appveyor.com/project/rainers/visuald/build/1.0.75/job/n9tf67jxcir6kpmg/artifacts Thanks for the response, I think there is more going on than that bug. The pipedmd that you linked did the same thing that mine did when I got rid of the rangeerror@pipedmd(285). Pipedmd just locks up and never finishes the build. Here is the project that gives me the problem, don't have something smaller that demonstrates it. https://www.dropbox.com/s/awtweclzl9kdm53/DGraphics.7z?dl=0 dub 1.0.0 dmd v2.071.0 visuald v0.3.44 beta 1 Generate the visuald project with "dub generate visuald -ax86_64", the project itself only builds in x64. Also fun fact, I get a different error if the folder that project is in has spaces in the path... so yeah... Thanks for the repro case. I can reproduce the lock-up with that project. You can disable the usage of pipedmd by unchecking both "demangle names in link errors" and "monitor linker dependencies" on the global options page "Project and Solutions -> Visual D Settings" which reveals that the command line is cut short. This seems to happen for the "Separate compile and link" compilation mode in the project configuration. If you switch to "Combined compile and link" it links successfully, even with pipedmd enabled. I think I fixed both issues in this build: https://ci.appveyor.com/project/rainers/visuald/build/1.0.76/job/kq0a5bqpy7anou46/artifacts
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 08.09.2016 19:35, Tofu Ninja wrote: On Thursday, 8 September 2016 at 07:45:56 UTC, Rainer Schuetze wrote: Fixed it again. You can find a prebuilt binary of pipedmd.exe here: https://ci.appveyor.com/project/rainers/visuald/build/1.0.75/job/n9tf67jxcir6kpmg/artifacts Thanks for the response, I think there is more going on than that bug. The pipedmd that you linked did the same thing that mine did when I got rid of the rangeerror@pipedmd(285). Pipedmd just locks up and never finishes the build. Here is the project that gives me the problem, don't have something smaller that demonstrates it. https://www.dropbox.com/s/awtweclzl9kdm53/DGraphics.7z?dl=0 dub 1.0.0 dmd v2.071.0 visuald v0.3.44 beta 1 Generate the visuald project with "dub generate visuald -ax86_64", the project itself only builds in x64. Also fun fact, I get a different error if the folder that project is in has spaces in the path... so yeah... Thanks for the repro case. I can reproduce the lock-up with that project. You can disable the usage of pipedmd by unchecking both "demangle names in link errors" and "monitor linker dependencies" on the global options page "Project and Solutions -> Visual D Settings" which reveals that the command line is cut short. This seems to happen for the "Separate compile and link" compilation mode in the project configuration. If you switch to "Combined compile and link" it links successfully, even with pipedmd enabled.
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 07.09.2016 22:10, Rainer Schuetze wrote: On 07.09.2016 19:28, Rainer Schuetze wrote: On 06.09.2016 06:38, Tofu Ninja wrote: I get "core.exception.RangeError@pipedmd(286): Range violation" whenever I try to build from visual D. Is there any workaround for this? It was reported[1] almost 9 months ago, does not seem like it's going to be fixed anytime soon. Visual D is completely broken for me right now because of it. Only reason I use Visual D is because it's the only useable debugger on windows, now I can't even do that... Lost a day of work trying to fix this, starting to get really annoyed... [1] https://issues.dlang.org/show_bug.cgi?id=15606 Please provide a test case. Without it, there is little that can be done. I now remember having investigated that bug before: https://forum.dlang.org/post/nmkfnm$2f51$1...@digitalmars.com and I did find it happened for symbols of exact length 2048. I even had a fix for it, but can't find it in the log. I'll try to reconstruct what happened... Fixed it again. You can find a prebuilt binary of pipedmd.exe here: https://ci.appveyor.com/project/rainers/visuald/build/1.0.75/job/n9tf67jxcir6kpmg/artifacts
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 07.09.2016 19:28, Rainer Schuetze wrote: On 06.09.2016 06:38, Tofu Ninja wrote: I get "core.exception.RangeError@pipedmd(286): Range violation" whenever I try to build from visual D. Is there any workaround for this? It was reported[1] almost 9 months ago, does not seem like it's going to be fixed anytime soon. Visual D is completely broken for me right now because of it. Only reason I use Visual D is because it's the only useable debugger on windows, now I can't even do that... Lost a day of work trying to fix this, starting to get really annoyed... [1] https://issues.dlang.org/show_bug.cgi?id=15606 Please provide a test case. Without it, there is little that can be done. I now remember having investigated that bug before: https://forum.dlang.org/post/nmkfnm$2f51$1...@digitalmars.com and I did find it happened for symbols of exact length 2048. I even had a fix for it, but can't find it in the log. I'll try to reconstruct what happened...
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 06.09.2016 06:38, Tofu Ninja wrote: I get "core.exception.RangeError@pipedmd(286): Range violation" whenever I try to build from visual D. Is there any workaround for this? It was reported[1] almost 9 months ago, does not seem like it's going to be fixed anytime soon. Visual D is completely broken for me right now because of it. Only reason I use Visual D is because it's the only useable debugger on windows, now I can't even do that... Lost a day of work trying to fix this, starting to get really annoyed... [1] https://issues.dlang.org/show_bug.cgi?id=15606 Please provide a test case. Without it, there is little that can be done.
Re: Easier way to add libraries to visual d?
On 26.05.2016 17:11, TheDGuy wrote: Hi, i use Visual D as a plugin for visual studio to create D applications. But what bothers me a bit is that i have to tell visual D the exact link to the .lib file for every lib i want to use in the project (!). So these are the steps i have to make to get an external lib working: 1. create a new folder in D:\dmd2\src\ with the name of the library 2. edit the 'sc.ini' file in D:\dmd2\windows\bin\ and add "-I%@P%\..\..\src\[foldername]" under '[Environment]' for every lib i want to use 3. add the .lib file to D:\dmd2\windows\lib 4. add the path to the lib in visual studio (project properties -> Linker -> General -> Library Files) Why do i have to do that? Why can i not just use one folder for the library files in visual d and the compiler searches the .lib files for each library which was imported into the project on its own? Is there an easier way to use libraries? You don't have to change anything in sc.ini. Just add the import path (the folder with the source files of your library) to "Project properties -> Compiler -> Additional import paths" and the full path to the .lib file to "Library Files". If it contains spaces, use quotes. If you want to use these libraries in multiple projects, you can also setup global search paths in "Tools -> Options -> Projects and Solutions -> Visual D Settings -> DMD directories".
Re: Debugging D DLL from C# app with C linkage for native Unity 5 plugin
On 30.03.2016 01:41, Thalamus wrote: Apologies if this has been discussed before, but I wasn't able to find anything similar on the forums or web. I can't seem to figure out how to debug a D DLL from a C# EXE. (My actual purpose here is to use D to build native plugins for Unity 5, but Unity and Mono aren't necessary to repro the problem I'm running into.) The D DLL and C# are both built as 64-bit. (C# is not set to AnyCPU). Using VS 2015 and Visual D, I can drive the D DLL from the C# EXE without any problems, but the debugger doesn't load the D DLL symbols. The DLL and PDB are in the same folder as the C# EXE. Everything behaves the same if I link to the DLL statically using P/Invoke or dynamically using LoadLibrary. Everything from the D DLL is exposed as extern(C), listed in the .def, etc. When I drive the DLL from a D EXE, I can break into the debugger easily, whether I attach at launch or attach to the process when it's already running. I'm building the DLL using: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus I haven't tried debugging a C# application, but you might have to disable "Just My Code" in the global debugger options. Also make sure to allow native debugging (JIT options). When debugging Visual D (a D DLL), I set VS (devenv.exe, a mixed C++/C# app) as the program to debug in the project debugger options. This ensures a native debugger engine is used and is the simplest way to use the mago debugger. With the "Mixed mode" engine, you can debug both C# and D/C++ in the same session.
Re: ldc application unable to start
On 21.02.2016 18:11, jmh530 wrote: The application was unable to start correctly (0xc7b). Click OK to close the application. This error code is often caused by a DLL being compiled for the wrong architecture, so I guess that you have some 32-bit DLL in your original folder that is found instead of the 64-bit DLL.
Re: Get memory usage report from GC
On 20.02.2016 07:22, tcak wrote: On Saturday, 20 February 2016 at 05:55:26 UTC, Jon D wrote: On Saturday, 20 February 2016 at 05:34:01 UTC, tcak wrote: On Saturday, 20 February 2016 at 05:33:00 UTC, tcak wrote: Is there any way (I checked core.memory already) to collect report about memory usage from garbage collector? So, I can see a list of pointer and length information. Since getting this information would require another memory area in heap, it could be like logging when report is asked. My long running but idle program starts using 41.7% of memory (that's close to 3GB), and it is not obvious whether the memory is allocated by a single variable, or many variables. My mistake, it is close to 512MB. Doesn't sounds like precisely what you want, but there are summary reports of GC activity available via the "--DRT-gcopt=profile:1" command line option. More info at: http://dlang.org/spec/garbage.html --Jon I checked it out now. Yes, it is not that much useful unfortunately. The process is a daemon. stdin, stdout, and stderr are forwarded to /dev/null, thus, there is nothing like getting a text report at the end of process. I am still looking for a way to at least hook up to GC, so when it allocates, or deallocates, I could log it myself. You can add path-to-druntime/src/gc/gc.d to your build command line and add option -debug=PRINTF_TO_FILE. This will redirect output to gcx.log. If you add option -debug=PRINTF, it will print some API calls. You might have to check gc.d whether the ones that interest you are commented out, though.
Re: Can't find windows' CreateThread function / concurrency.spawn crashes host application
On 02.01.2016 18:41, alkololl wrote: On Saturday, 2 January 2016 at 16:42:46 UTC, Rainer Schuetze wrote: On 02.01.2016 16:34, alkololl wrote: On Saturday, 2 January 2016 at 01:44:46 UTC, Adam D. Ruppe wrote: [...] Thanks for your reply. I replaced my switch statement with the one behind the link you left but the result (no result) stays the same. The Dll doesn't get unloaded. Not until I close the host application. D needs "implicite thread local storage" to implement thread local variables, but Windows XP and earlier versions do not support this for DLLs dynamically loaded through LoadLibrary. The D runtime implements the part necessary for loading, but does not support unloading. As a consequence it sets the DLL to never unload. If you are actually running XP, you can check https://github.com/denis-sh/hooking. IIRC Denis Shelomovskij implemented the missing parts. What? I'm actually running Windows 7. For me it's inevitable to not unload the D Dll dynamically. Isn't there some kind of workaround or a sneaky hack to solve this? If you run Windows 7, I guess the runtime patch is not the issue here. Have you tried to load the DLL explicitely (without injecting it)? Does it unload correctly in this case? If not, it should ease debugging the problem.
Re: GC configuration docs
On 05.01.2016 01:39, Dan Olson wrote: I haven't played with any of the new GC configuration options introduced in 2.067, but now need to. An application on watchOS currently has about 30 MB of RAM. Is there any more documentation than the web page https://dlang.org/spec/garbage.html or should I just browse druntime code? I don't think there is more than that. Also pointers (pun maybe) on finding who has the references keeping memory from being collected. There is a "leak detector" in the GC compiled into it the with -debug=LOGGING, but I guess noone has been using it the last couple of years (and it seems to me it doesn't really do anything more than printing allocations). I used -debug=PRINTF, -debug=PRINTF_COLLECT and -debug=PRINTF_TO_FILE in the past and grepped the resulting gcx.log. You might want to uncomment some printf in the mark function, too.
Re: Can't find windows' CreateThread function / concurrency.spawn crashes host application
On 02.01.2016 16:34, alkololl wrote: On Saturday, 2 January 2016 at 01:44:46 UTC, Adam D. Ruppe wrote: On Saturday, 2 January 2016 at 00:32:20 UTC, alkololl wrote: Why is that? I'm not sure, but in the switch you posted, you didn't handle the DLL_THREAD_ATTACH and DLL_THREAD_DETACH cases, the runtime might be incrementing the refcount there. Check this out: http://wiki.dlang.org/Win32_DLLs_in_D Thanks for your reply. I replaced my switch statement with the one behind the link you left but the result (no result) stays the same. The Dll doesn't get unloaded. Not until I close the host application. D needs "implicite thread local storage" to implement thread local variables, but Windows XP and earlier versions do not support this for DLLs dynamically loaded through LoadLibrary. The D runtime implements the part necessary for loading, but does not support unloading. As a consequence it sets the DLL to never unload. If you are actually running XP, you can check https://github.com/denis-sh/hooking. IIRC Denis Shelomovskij implemented the missing parts.
Re: What's wrong with my debugger?
On 24.12.2015 14:57, Chris wrote: On Thursday, 24 December 2015 at 09:30:24 UTC, Rainer Schuetze wrote: In the locals window, mago displays all instances of variables, but with the same value (which might be some uninitialized value of a different declaration than expected). The Visual Studio debug engine shows different values, though. Hi, thanks for the reply but not actually, no, if I change the debug engine to VS and rebuild I get the same behaviour. I suspect that the variables are part of a closure. There is bad and incomplete debug information emitted by dmd in this case.
Re: What's wrong with my debugger?
On 24.12.2015 03:14, Chris wrote: Please see the linked screenshot: http://i.imgur.com/SpkXu5m.png As you can see, the inside, outside and collision arrays don't seem to work with the debugger. They show a bogus lenght and a bogus memory address. Extracting the lenghts to separate variables outl, insl and coll show that the arrays actually behave properly, though. Is that a debugger bug? Or maybe something I can fix? Thanks in advance. DMD 2.069.2, Mago debugger, VisualD 3.43, compiling for 32 bits if that makes a difference (can't get either 64 bit compilation or LDC to work) One possible issue is that there are multiple variable declarations in the function with the names "outside, inside and collision". Dmd does not emit proper scope information for variables, so all variables show up anywhere in a function. (See for example https://github.com/D-Programming-Language/dmd/pull/2867). In the locals window, mago displays all instances of variables, but with the same value (which might be some uninitialized value of a different declaration than expected). The Visual Studio debug engine shows different values, though.
Re: VisualD building with GDC setting library path
On 18.07.2015 15:07, kerdemdemir wrote: Hi, I am tring to build Cristi Cobzarenco's fork of Scid which has LAPACK,BLAS dependency. I add all modules of Scid to my project and I am tring to build it within my project. I add LibraryFiles: liblapack.a libblas.a libtmglib.a libgfortran.a etc.. via menu configuration properties--Linker -- General --- LibraryFiles . Even though I set C:\Qt\Tools\mingw491_32\i686-w64-mingw32\lib path which has libgfortran.a from Visual D Settings --Library Paths; I am getting error : gdc: error: libgfortran.a: No such file or directory. Libraries only works if I copy and paste them to my project folder. And coping all libraries fortran.a , pthread.a etc... seems not logical to me. I read there is a known isssue with sc.ini but it should only be with DMD not with GDC. How can I set library path with visualD while building with GDC? GDC does not search libraries passed by filename on the command line. You either have to specify the full path or use option -l, i.e. - add -llapack -lblas -ltmglib -lgfortran etc to Library Files - set the search path either in the global or the project option Library Search Path
Re: DMD phobos built with contracts check for win?
On 05.05.2015 02:03, Dzugaru wrote: I have to compile it myself from sources or is it available somewhere? Was playing with fibers using VisualD + DMD and lack of contract checking (for example call() on fiber in state TERM) leads to bizarre crashes :( The latest (beta) version of Visual D comes with a new linker option build and use local phobos library that builds phobos with the options of the current project and links against it. https://github.com/D-Programming-Language/visuald/releases
Re: Unittest in a windows app
On 19.12.2014 22:39, Dan Nestor wrote:
Hello everybody, this is my first post on this forum.
I have a question about unit testing a Windows application. I
have slightly modified Visual D's default Windows application
stub to the following:
[...]
try
{
Runtime.initialize();
Runtime.initialize() no longer calls the unittests since a few versions.
You have to call runModuleUnitTests() explicitely, e.g.
try
{
Runtime.initialize();
if (runModuleUnittests())
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
nCmdShow);
Runtime.terminate();
}...
Re: COFF on Win32 how to try?
On 13.10.2014 10:12, Szymon Gatner wrote: On Saturday, 11 October 2014 at 13:35:55 UTC, Rainer Schuetze wrote: Yes, DMD git HEAD is required. Getting this when trying to build all with Digger: std\uri.d(872): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\uri.d(1166): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\concurrency.d(1352): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1354): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1348): Error: function std.concurrency.FiberScheduler.FiberCondition.wait no return exp; or assert(0); at end of function std\concurrency.d(1395): Error: function expected before (), not this.m_fibers[this.m_pos].state() of type State std\concurrency.d(1971): Error: function expected before (), not currSystemTick() of type TickDuration ... --- errorlevel 1 Fatal error: Command [make, -f, win32.mak, phobos.lib, MODEL=32] failed with status 1 Sorry for taking your time. I thin, I'll just wait for 2.067 and re-try then. I believe you have built the pull requests by choosing Make me one with everything from the web interface. That stops at the first failing one. Just hit Build. That worked for Win32 for me, but I got a ZipException when downloading the tools to build Win64.
Re: COFF on Win32 how to try?
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all neccessary repos
from GitHub. As my understanding is that I should not be doing Build
with Diggger I just opened Windows console, entered druntime dir and typed:
You have to build dmd, so it should be good starting point to succeed
in building the full chain for win64: dmd, druntime and win64.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will have to
specify the path to dmd too:
make -f win64.mak MODEL=32mscoff CC=\%VCINSTALLDIR%\bin\cl.exe\
DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the normal path
is ../dmd/src/dmd). You'll have to update sc.ini there, too.
Re: COFF on Win32 how to try?
On 11.10.2014 12:12, Szymon Gatner wrote:
On Saturday, 11 October 2014 at 09:21:18 UTC, Rainer Schuetze wrote:
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all neccessary repos
from GitHub. As my understanding is that I should not be doing Build
with Diggger I just opened Windows console, entered druntime dir and
typed:
You have to build dmd, so it should be good starting point to succeed
in building the full chain for win64: dmd, druntime and win64.
You mean for Win32? Beacause that is what I am after.
I meant Win64, because the tool chain is very much the same as for
win32mscoff (MS compiler and linker and C runtime). Win32 means dmc and
optlink. That's also why the win64.mak makefiles are abused for win32mscoff.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will have
to specify the path to dmd too:
make -f win64.mak MODEL=32mscoff CC=\%VCINSTALLDIR%\bin\cl.exe\
DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the normal
path is ../dmd/src/dmd). You'll have to update sc.ini there, too.
So to build HEAD druntime and Phobos I also need HEAD DMD, correct?
Installation of 2.066 I have now is not sufficent?
Yes, DMD git HEAD is required.
Re: COFF on Win32 how to try?
On 10.10.2014 10:37, Szymon Gatner wrote: I would like to try recently merged COFF support on Win32 for a hybrid D/C++ application. Until now I tried that (hybridizing) only with DMD from the official installer and in x64 mode. My question is: how to try the same in 32 bits? You need a recent version of dmd, druntime and phobos from github: https://github.com/D-Programming-Language If you have never built these yourself, Digger might be of great help: https://github.com/CyberShadow/Digger/releases. It will also fetch these from github and download tools needed for building. Digger doesn't know about COFF32 yet, though. Then build druntime inside its directory: make -f win64.mak MODEL=32mscoff CC=\%VCINSTALLDIR%\bin\cl.exe\ target unittest and phobos: make -f win64.mak MODEL=32mscoff CC=\%VCINSTALLDIR%\bin\cl.exe\ AR=\%VCINSTALLDIR%\bin\lib.exe\ Add a configuration section [Environment32mscoff] to your sc.ini and add options matching these: https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L84 Building is done with option -m32mscoff instead of -m32/-m64.
Re: Trouble linking to static library with Visual D
On 02.08.2014 04:43, quakkels wrote: Hello D'ers, I've been really impressed with Visual D and I've decided to undertake my first D project using Visual D in Visual Studio 2012. However, I've had trouble trying to figure out how to link a static library. I've outlined my situation in this Stack Overflow question. http://stackoverflow.com/questions/25071649/how-to-link-to-packages-in-static-libraries-using-visual-d I would very much appreciate any insight into what I can do to correct the described behavior. Thanks, quakkels Your request.d should declare the full module name including the package: module codecramlib.http.request; Then import it with this name from package.d: import codecramlib.http.request; When you get to the link stage, you'll probably run into undefined symbols: you'll have to add a dependency in the Project Dependencies dialog to add the static library to the linker command line of the executable.
Re: Help to find crash in simple stack type?
On 12.07.2014 16:24, anonymous wrote:
No explanation or solution, but a reduction:
import core.memory;
void main()
{
alias T = ubyte;
enum size1 = 2_049; /* 2_048 = 2^^11 */
enum size2 = 1_048_577; /* 1_048_576 = 2^^20 */
T* _data;
_data = cast(T*)GC.calloc(size1, GC.BlkAttr.NO_MOVE);
_data = cast(T*)GC.realloc(_data, size2, GC.BlkAttr.NO_MOVE);
T* _pointer = _data;
foreach(i; 0 .. size2)
{
*_pointer = 0; /* segfault at i = 1_048_576 */
_pointer++;
}
}
Thanks for the reduction. GC.realloc seems broken for reallocations to
sizes larger than the current GC pool.
Please file a bug report.
Re: Help to find crash in simple stack type?
On 12.07.2014 19:05, Rainer Schuetze wrote: Thanks for the reduction. GC.realloc seems broken for reallocations to sizes larger than the current GC pool. Please file a bug report. Actually done that myself: https://issues.dlang.org/show_bug.cgi?id=13111
Re: Visual D: Settings to Improve compil and link process
On 07.07.2014 12:46, ParticlePeter wrote: On Sunday, 6 July 2014 at 19:27:38 UTC, Rainer Schuetze wrote: These object files are in the library ;-) That means manual selection, though, as incremental builds to multiple object files don't work with dmd, and single file compilation is painfully slow. Not sure if I am getting this right, so when one object file has to be recompiled all other object files, even if up to date, would be recompiled ? That's how it is currently done if you don't use single file compilation. Compiling only modified and dependent modules in one step could work incrementally, but especially template instantiations make this hard to do correctly. The modules form MyProject do import the MyLib modules properly, I do not get compiler errors. However, the compiler should create Object files from MyLib modules, and the linker should link them. But he does not. On the other hand, when I add MyLib modules to MyProject ( Rightclick MyProject - add - existing item... MyLib source files ) then linking works. I do not understand why the later step is necessary. dmd does not compile imported modules, but rdmd does. Ähm ... not seeing the connection here either, why is this significant ? dmd just compiles the files given on the command line. rdmd makes two passes, one to collect imported files, and another to compile all the collected files. So rdmd works the way you want dmd to work (if I understand you correctly). I feel that I could not explain my problem properly, so one example: Importing phobos modules. I do not have to define any import path or lib file in the project settings, I just need to import std.somthing. That's because the import path for phobos modules are stored in the dmd sc.ini file. When I want to import my modules which are somewhere on my hard-drive and not added to my project I need to tell the compiler where these modules can be found, using the additional import path project setting. That's fine, doing this. But result is, std.somthing works, my modules in a path known by the compiler don't work, giving me linker errors. Why ? ( I do not create a lib, I just want to import the module. ) phobos is precompiled to a library and is automatically included in the link. If you want your custom modules to work the same way, you have to compile them to a library.
Re: Visual D: Settings to Improve compil and link process
On 05.07.2014 16:05, ParticlePeter wrote: Hello Community, I thought there's a separate forum for VisualD. It did exist when VisualD was on DSource, so why not add it here as well? Or am I to blind to see? The forum digitalmars.D.ide is probably the best fit. Anyway, this thread is an addition to my previous one in this forum: http://forum.dlang.org/thread/wkkuvzkzeupyfdpwe...@forum.dlang.org I noticed increasing compile times in my projects. As I use only VisualD I would like to understand how I would shorten compile time with this tool. Brief description to my setup, more details can be fond in the other post. I have one Lib, called MyLib consisting of around 15 modules, one class per module, zero to two template methods per class with one type parameter each. All my projects use MyLib, and call the template methods with different types. Most of the compile time of any of theses projects is spent in rebuilding MyLib. I am not sure why and where so much time is spent, but is there a way to profile my COMPILE time with VisualD? The longer compile time is very likely caused by the compiler. You could check Verbose compile (command line option -v) to see what templates are expanded and what functions are compiled. This might give you a hint where the compiler spends the time. There are several VisualD project properties which I do not understand fully, but hope that they might help, namely: Configuration Properties - General - Files to clean Configuration Properties - Compiler - Output - Multiple Object Files Configuration Properties - Compiler - Output - Keep Path From Source File Could not cleaning some files improve compilation ? No. Could Multiple Object Files be used to separately compile non-template and template code blocks ? No. This option exposes an undocumented command line option that splits a module into multiple object files as if dmd creates a library. Do not use it. What does Keep Path From Source File do at all ? This instructs dmd to not strip the path components from module source file name when generating the object file name. This avoids troubles if you build to multiple object files, but there are modules with identical names in different packages. It is possible to remove the template methods from my classes, create free functions instead and use them in a UFCS way. Unfortunately I have not figured out UFCS properly, as my approaches do not work ( guess due to UFCS restrictions ). That would not help, templates are instantiated and compiled when they are used, not when they are declared. Anyway, would it help ( and is it possible at all ) to put the template functions in a separate module so that only the corresponding object file requires a recompile ? I am asking in the context of the Multiple Object Files setting. Incremental building of single object files is not well supported by dmd, there are too many troubles with instantiating templates in different object files. I tried to not build MyLib at all, and use the sources directly, but the project setup is kind of confusing. Again, there is a setting which I seem to not understand fully. So one project, lets say MyProject, has only its own module files added to the VisualD project. I want the compiler to also use the MyLib source files, but do not want to add them to MyProject, reasoning bellow. There is one entry in the project properties, which should make this behavior possible, but it doses not. Why ? Configuration Properties - Compiler - General - Additional Imports As far as I understand this setting, I am supposed to enter module search paths. This is correct. But I do get linker errors when I do not add either MyLib.lib to the linker settings or all the source files of MyLib to MyProject. You should add a dependency in the Project - Project Dependencies dialog. This will ensure proper rebuilds and add the library to the command line of dependent projects. Reasoning why I do not want to do this: I have one solution file with the MyLib project and ten projects like MyProject using MyLib. I would need to add all the source files to all the projects, they would be reachable and editable at 11 different location within my solution file. This does not not seem to be a clean way to set it up. Any advice to any or all the thoughts and issues ? Thanks in advance. Cheers, ParticlePeter
Re: Visual D: Settings to Improve compil and link process
On 06.07.2014 19:51, ParticlePeter wrote: On Sunday, 6 July 2014 at 08:09:07 UTC, Rainer Schuetze wrote: On 05.07.2014 16:05, ParticlePeter wrote: ... It is possible to remove the template methods from my classes, create free functions instead and use them in a UFCS way. Unfortunately I have not figured out UFCS properly, as my approaches do not work ( guess due to UFCS restrictions ). That would not help, templates are instantiated and compiled when they are used, not when they are declared. Hence the idea of splitting the class. After the split, the class has only non-template methods and is part of MyLib. Template UFCS functions working with this class are in another module, and not part of the lib. With this approach MyLib does not need to recompile, only the UFCS functions module needs to recompile due to different instantiations. UFCS works now for me btw. Ok, that allows separate compilation of the class, but templates are still compiled with the rest of the program. I thought the templates were the part that cause the slow compilation. I tried to not build MyLib at all, and use the sources directly, but the project setup is kind of confusing. Again, there is a setting which I seem to not understand fully. So one project, lets say MyProject, has only its own module files added to the VisualD project. I want the compiler to also use the MyLib source files, but do not want to add them to MyProject, reasoning bellow. There is one entry in the project properties, which should make this behavior possible, but it doses not. Why ? Configuration Properties - Compiler - General - Additional Imports As far as I understand this setting, I am supposed to enter module search paths. This is correct. But I do get linker errors when I do not add either MyLib.lib to the linker settings or all the source files of MyLib to MyProject. You should add a dependency in the Project - Project Dependencies dialog. This will ensure proper rebuilds and add the library to the command line of dependent projects. The idea is to NOT create a lib, but just use the source code from MyLib in MyProject as additional includes. No project dependencies. I was hoping that some .obj files are still available from last builds, and do not need to recompile, as they are up to date ( reason for question about not cleaning files ). These object files are in the library ;-) That means manual selection, though, as incremental builds to multiple object files don't work with dmd, and single file compilation is painfully slow. The modules form MyProject do import the MyLib modules properly, I do not get compiler errors. However, the compiler should create Object files from MyLib modules, and the linker should link them. But he does not. On the other hand, when I add MyLib modules to MyProject ( Rightclick MyProject - add - existing item... MyLib source files ) then linking works. I do not understand why the later step is necessary. dmd does not compile imported modules, but rdmd does.
Re: Is GC.setAttr(p, GC.BlkAttr.NO_MOVE) guaranteed to work?
On 02.07.2014 08:17, Ali Çehreli wrote: There is an example in GC.addRoot() documentation where the programmer is trying to mark a memory block as NO_MOVE: http://dlang.org/phobos/core_memory.html#.GC.addRoot auto context = new Object; GC.addRoot(cast(void*)context); GC.setAttr(cast(void*)context, GC.BlkAttr.NO_MOVE); If I understand it correctly, as soon as addRoot() succeeds, the block may have already been moved perhaps due to the needs of another thread. Yes, but the local variable context also has been changed to the new location by a moving GC (also any temporaries on the stack). Will setAttr() still work if that happened? Perhaps the GC is supposed to track any previously used memory block reference like 'context' so that the call will succeed? (I doubt it.) If the example can indeed fail, will swapping the last two statements work as in the following code? auto context = new Object; GC.setAttr(cast(void*)context, GC.BlkAttr.NO_MOVE); GC.addRoot(cast(void*)context); How about the reverse operations: Can I still use 'ctx' to refer to potentially moved memory block in the following code? GC.removeRoot(ctx); GC.clrAttr(ctx, GC.BlkAttr.NO_MOVE); It seems to me that as a general rule, one cannot trust setting NO_MOVE on a GC-managed block at all. If that's true, addRoot() must have an overload that takes attributes as well and work atomically in that regard, right? Ali addRoot tells the GC that there are external references into GC managed memory. These references are not visible to the GC, so it cannot modify them when moving the referenced memory. As a consequence, addRoot implies NO_MOVE. I think the example is flawed. The issue raised does show a rule to follow, though: do not store a GC pointer to external memory before calling addRoot() or setAttr(NO_MOVE), it might get moved after the assignment, but before being fixed. BTW: The current GC has no support for moving, and the NO_MOVE flag isn't even stored anywhere (getAttr after setAttr will not report it being set).
Re: Down the VisualD0.3.38-1.exe ,found virus!
On 12.05.2014 08:36, FrankLike wrote: There are some quotes missing when building the Debug configuration. I have committed a fix and also added the missing file reported in your other message (IIRC it is not needed by every VS SDK). Sorry,Rainer Schuetze, Here is some error when compile the VisualD: --ERROR START Building Resources\pkgcmd.cto Command Line set PATH=D:\D\dmd2\windows\bin;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\\bin;%PATH% set DMD_LIB=D:\D\dmd2\windows\lib set VS9SDKBIN=c:\l\vs9SDK\VisualStudioIntegration\Tools\Bin set CTC=%VS9SDKBIN%\CTC.exe if not exist %CTC% goto no_CTC if not exist C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Common7\Tools\vsvars32.bat goto no_CTC set PATH=%PATH%;%VS9SDKBIN% call C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Common7\Tools\vsvars32.bat if errorlevel 1 goto reportError %CTC% Resources\pkgcmd.ctc Resources\pkgcmd.cto -Ccl -I. goto reportError :no_CTC echo Warning: CTC.exe not found in %VS9SDKBIN%. echo It is part of the VS2008 SDK and is needed to compile Resources\pkgcmd.ctc if not exist Resources\pkgcmd.cto exit 1 echo Resources\pkgcmd.cto exists, so it is assumed to be up to date. echo If the project rebuilt again and again with this message, touch Resources\pkgcmd.cto to make it newer than Resources\pkgcmd.ctc :reportError :reportError if errorlevel 1 echo Building Resources\pkgcmd.cto failed! Output Warning: CTC.exe not found in c:\l\vs9SDK\VisualStudioIntegration\Tools\Bin. It is part of the VS2008 SDK and is needed to compile Resources\pkgcmd.ctc -ERROR END- I found it always to overwite the file 'visuald\visuald\Resources\pkgcmd.cto.build.cmd',let the 'VS9SDKBIN=c:\l\vs9SDK\VisualStudioIntegration\Tools\Bin' not use '%VSSDK100Install%VisualStudioIntegration\Tools\Bin' . Then failed. ctc.exe is not distributed with the SDKs starting from VS2010, so mapping to a more recent version does not work. That's why there is a precompiled pkgcmd.cto file in the repository. You'll have to update its modification time to avoid the build process trying to generate it from pkgcmd.ctc every time. The explicitely used c:\l\vs9SDK is my installation, I should add a check for %VSSDK90Install% here.
Re: Down the VisualD0.3.38-1.exe ,found virus!
On 12.05.2014 08:38, FrankLike wrote: On Monday, 12 May 2014 at 06:36:10 UTC, FrankLike wrote: There are some quotes missing when building the Debug configuration. I have committed a fix and also added the missing file reported in your other message (IIRC it is not needed by every VS SDK). Sorry,Rainer Schuetze, And there is a little error in sdk.bat '(echo unexpected Visual Studio SDK installation at %VSISDKINC% exit /B 1)' %VSISDKINC% should be %VSISDKINC% I agree it is a bit clearer with quotes, but echo still works without, doesn't it?
Re: Down the VisualD0.3.38-1.exe ,found virus!
On 10.05.2014 10:42, FrankLike wrote: I've been using VisualD for a long time without problems. If it makes you nervous, you can get the source from Github and compile it yourself. Hello,Meta When I compile the Visual D projects: at first,I compile the 'build' project,then get some error: --START ALL BUILD: PROJECT: c2d, Debug Win32 -- Building ..\bin\Debug\c2d.lib... Build time: 1 s -- START ALL BUILD: PROJECT: vsi2d, Debug Win32 -- Building ..\bin\Debug\vsi2d.exe... Converting debug information... Build time: 1 s -- START ALL BUILD: PROJECT: build, Debug Win32 -- Building ..\bin\Debug\build.sdk... 'C:\Program' is not recognized as an internal or external command, operable program or batch file. Building ..\bin\Debug\dte_idl.success failed! Here is my VSSDK AND WINSDK: VSSDK100Install = C:\Program Files (x86)\Microsoft Visual Studio 2010 SDK SP1 WindowsSdkDir = C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A How can I do? Thank you. There are some quotes missing when building the Debug configuration. I have committed a fix and also added the missing file reported in your other message (IIRC it is not needed by every VS SDK).
