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.
Visual D 1.3.0 released
Hi, happy to announce the release of Visaul D 1.3.0. The most important change is the update of semantic analysis for highlighting, browsing and code completion to the frontend of dmd 2.100.0. See the list of further changes and bug fixes at https://rainers.github.io/visuald/visuald/VersionHistory.html Visual D is a Visual Studio extension providing project management, language services and debugger integration for the D language. You can install it from the Visual Studio Marketplace or download it from https://rainers.github.io/visuald/visuald/StartPage.html Best, Rainer
Re: Global variables not accessible with Visual Studio debugger
On 23/04/2022 15:41, pdgr wrote: On Saturday, 23 April 2022 at 13:29:16 UTC, pdgr wrote: Thanks for the suggestions, the extern(C) thing doesn't work.. but in the disassembly I can see the mangled name and I can inspect the value in the watch window using that mangled name. Kinda annoying but it works. Scratch that.. it doesn't actually work: the disassembly doesn't not contain any mangled names, I mistook a hex value for the mangled name. I suspect you are trying to watch a thread local variable that uses indirect addressing. With shared or __gshared variables, you see the symbol being used as debug information, but the debugger cannot handle that as a C++ expression. You can see the mangled symbol with "pragma(msg, var.mangleof)" at compile time. Using this in the watch window shows it as a "void*", which you can then cast to your type using C++-Syntax, e.g. "*(int*)_D3mod3tlsi". I'd recommend installing Visual D including the debugger extension mago instead, though ;-)
Re: Global variables not accessible with Visual Studio debugger
On 21/04/2022 21:37, pdgr wrote:
Hello,
I have a program that I want to debug on Windows 10 using Visual Studio
2022. I'm debugging the built .exe directly (not using VisualD or
anything).
Without Visual D (or to be more precise: without the mago debugger
extension that comes with Visual D), you are rather limited when
debugging D code.
The program is compiled with dmd ver v2.099.0 using the following flags:
dmd main.d -debug -g -gf -gs -m64
In Visual Studio when I type the name of my global variable in the watch
window it can't find it.. any way to solve this? I found some old thread
that suggested using {module-name}.{global-var-name} but that doesn't
work either.
It might work to use the mangled name, e.g. _D3mod4namei. You can find
the exact speelling in the disassembly of an access to the variable.
An alternative might be to use extern(C) when declaring the variable.
Re: Beta 2.099.0
On 16/02/2022 06:53, forkit wrote: On Wednesday, 16 February 2022 at 04:14:01 UTC, max haughton wrote: On Wednesday, 16 February 2022 at 01:38:08 UTC, forkit wrote: On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: I was so hoping I could now begin using -betterC on Windows... but no .. :-( i.e. stdout, stdin, stderr ...still cannot link... Can you not define them yourself in the meantime? err.. howdy doody dat? The PR was too late for the beta, but this is the basic change: https://github.com/dlang/druntime/pull/3740/files#diff-5cbe9748431681a766784b1bd997444d58d436a26a345b32397daae478f85c5dR907 Please note that this only supports the C runtimes for VS 2015 or later. If you are using the mingw import libraries, you'll have to switch to the corresponding version, too. Without a VS environment, -mscrtlib=vcruntime140 should do, but the tests had to add -Lvcruntime140.lib -Llegacy_stdio_definitions.lib -L/NODEFAULTLIB:msvcrt120.lib on the command line to do that.
Re: -checkaction=C - Debugger out of sync?
On 27/01/2022 18:32, frame wrote: @Rainer Schuetze I quote this (you have sent me somehow a private email) Sorry, I still screw this up too often since the default/button order has changed in Thunderbird. If your invariant is called from the GC during finalization, it might have to do with the debugger executing code to show structs or ranges. Are you using the visualizer methods __debugOverView, __debugExpanded, etc.? Are ranges displayed in your Auto/Local/Watch windows? No, I don't. You can try to disable implicit code execution by the debugger in Tools->Options->Debugging->Mago by unchecking options "Call struct/class..." and "Call range methods". Yes, the option `Call range methods` causes the problem! Is that still experimental in VisualD 1.2.0? Please do not enable it by default then. It's a bit dangerous because executing code automatically can mutate your program state. The default has been changed quite some time ago (https://github.com/rainers/mago/commit/8ce1bb37818ea38e88ec8ecf2439383b592fca46), so you probably picked up the enabled state as an early adopter.
Re: Are there any debugger functions?
On 06/01/2022 19:04, frame wrote: If a pointer has an invalid target a debugger in VS shows the error `D0001: Error: Expression couldn't be evaluated` when I try to access it. Is there a debugger function to trigger this access which can be used inside an invariant? I can assert it by checking if the pointer address is far to low, but this doesn't always work. Are you looking for something like IsBadReadPtr? See https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-isbadreadptr
Visual D 1.2.0 supports Visual Studio 2022
Hi, Visual D 1.2.0 has just been released. Visual D is a Visual Studio package providing project management, language services and debugger integration for the D language. You download it from https://rainers.github.io/visuald/visuald/StartPage.html Major new features: * added support for Visual Studio 2022 * semantic engine updated to frontend of dmd 2.098.1 * added option to restart the semantic analysis if memory usage goes above a given threshold See the list of further changes at https://rainers.github.io/visuald/visuald/VersionHistory.html Known issues: * the signing certificate of the D Language Foundation has recently expired, so the installer cannot be signed digitally ATM (the same as the dmd installer). * Visual Studio 2022 is the first VS version running as a 64-bit process which means all extensions had to be ported to 64-bit aswell. Please consider support for it experimental and report issues to bugzilla. Best, Rainer
Re: On the D Blog -- Teaching D from Scratch: Is it a viable first language?
On 24/12/2021 16:24, rumbu wrote: On Thursday, 23 December 2021 at 12:44:04 UTC, Mike Parker wrote: Steven Schveighoffer has been using D to teach a group of children to program. He wrote about his experience for the D blog. Is D a viable first language? See what Steve has to say about it :-) The blog: https://dlang.org/blog/2021/12/23/teaching-d-from-scratch-is-it-a-viable-first-language/ I have read that Visual D has a better debugging experience, but I need dub support for these projects, and Visual D focuses on Visual Studio integration, something I don’t necessarily want to deal with in teaching these kids This is truly an understatement about Visual D, the debugging experience is at par with the native C++ one in VS. If I was a kid from that group, I would feel tormented by the dub/vscode experience :) Rainer Schuetze deserves a statue. Thanks, but no statue please ;-) BTW: the mago debug engine was originally written by Aldo Nunez. I adopted it and made it work as an extension to the VS Concord debugger. Please note that the native debug engine for VS Code is the same as for Visual Studio, and it only took some changes to make the former load extensions, too: https://github.com/microsoft/vscode-cpptools/issues/2932#issuecomment-853774543 Integrating it with code-d is just some installation issues away, see https://github.com/WebFreak001/code-debug/issues/271
Re: first chance exception in VisualD
On 28/07/2021 11:37, frame wrote: > Are first chance exception breakpoints throwing by assert() working in > VisualD? I have core.exceptions.AssertError enabled but it slips > through. I fancied that it worked some time ago. Not sure what happend. Dealing with exceptions in the debugger is a bit tricky: - a 64-bit executable built with dmd only generates a "priveleged instruction exception" for unhandled exceptions as dmd generated code that does not use standard exception handling - a 32-bit executable built with dmd has regular exception handling code, but uses exception code 0xe0440001 for all exceptions - the standard VS debugger with or without the mago extension cannot filter on the actual exception - only the "mago debug engine" as selected in the "Debugging" project configuration can evaluate the "D Exceptions" settings, but it might have bitrotten... - when compiling with LDC, standard C++ exceptions are generated, and you can setup exception filters in the "C++ exceptions" group tl;dr: use LDC :-)
Re: Breakpoint for EXE to DLL debugging in VisualD (all D)
On 08/05/2021 21:44, frame wrote: > On Saturday, 8 May 2021 at 14:26:18 UTC, Rainer Schuetze wrote: > >> In case you load the DLL dynamically, maybe it helps if you preload >> the DLL and it's symbols, e.g. by loading it as a direct dependency of >> the executable. > > I can see in the module window that all symbols are already loaded, but > still no luck. > It also fails to step-by-step debugging into the exported function. > > It highly depends in which editor tab the breakpoint is set. If I select > the wrong one, only the main application gets the breakpoint. The main > problem is to open this tab in the right context in the first place. > > It's a arbitrary behavior, for some functions it works better than > others. Maybe simple functions work better than those which are created > by static type variants. > > Also weird that the debugger even opens the same code tab for different > stacks but doesn't title it. This seems to be a problem with VS too. It > would be great if VisualD could provide a debugger breakpoint list too > which allows to select the module if needed because the standard > debugger window is not very sophisticated anyway. Opening the same file twice is probably hinting at the problem: the source file references in the debug information are different, and VS thinks they are referring to different files. This probably also affects break point location resolution. What compiler are you using? What command line options? Looking at a hex listing of binary object files might reveal if source file names are represented differently.
Re: Breakpoint for EXE to DLL debugging in VisualD (all D)
On 06/05/2021 16:21, frame wrote: > Some code of my framework is reused in my DLL too because it has it's > own logic as a plugin system. > > I want to seamlessly debug from EXE to DLL inspection by running the > main application. > > If I set a breakpoint for a method in the VS debugger it generates > breakpoints for all method overloads for the main EXE and also sometimes > for the DLL too - but in most cases only for the EXE. I have tried to reproduce the issue with a simple pair of exe and DLL sharing a template in a common module, but that worked as expected (showing both function locations in the list of breakpoints). > > The breakpoint will be hit if the function name matches the process, so > it seems. > > eg.: > ```main.exe!mylib.func.get!bool.get(...)``` > ```some.dll!mylib.func.get!bool.get(...)``` > > I tried to manually insert the breakpoint as modified function name, but > that doesn't work. > I tried to export the breakpoint xml data and edit it, but I am afraid I > also need the correct function address to get this working. The mago debug extensions deals with D expressions, but not breakpoint locations. There seems to be an interface to support function name resolution, but it is not implemented yet. > > The only way it works so far is when the debugger catches an error in > loaded DLL and opens the right editor tab for it. If I set a breakpoint > then it also generates breakpoints for functions in the DLL too. > > Is there are way to select the loaded DLL when setting a breakpoint I > don't know? > In case you load the DLL dynamically, maybe it helps if you preload the DLL and it's symbols, e.g. by loading it as a direct dependency of the executable.
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: Catching excecptions in the MSVC debugger when running Win64
On 27/04/2021 07:43, Lewis wrote:
> Okay, I was able to get the VS debugger to catch exceptions in win64 by
> adding a hack to deh_win64_posix.d so that it mimics deh_win32.d.
>
> I added the following code above the definition of _d_throwc():
>
> ```
> import core.sys.windows.windef : DWORD;
> extern(Windows)
> {
> void RaiseException(DWORD, DWORD, DWORD, void*);
> }
> ```
>
> ...and I added the following to _d_throwc() itself, right after it calls
> _d_createTrace():
>
> ```
> template MAKE_EXCEPTION_CODE(int severity, int facility, int exception)
> {
> enum int MAKE_EXCEPTION_CODE = (((severity) << 30) | (1 << 29) | (0 <<
> 28) | ((facility) << 16) | (exception));
> }
> enum int STATUS_DIGITAL_MARS_D_EXCEPTION = MAKE_EXCEPTION_CODE!(3,'D',1);
> enum DWORD EXCEPTION_NONCONTINUABLE = 1;
> RaiseException(STATUS_DIGITAL_MARS_D_EXCEPTION,
> EXCEPTION_NONCONTINUABLE, 1, cast(void*));
> ```
>
> With this, the debugger catches exceptions again.
>
> This feels like a total hack though. Presumably I'm missing an obvious
> better solution?
Unfortunately, the dmd backend does not use the standard exception
mechanism for win64, but some homegrown one adapted from the linux
exception handling. That's why the debugger does not recognize the
exceptions.
Your solution works for catching exceptions, but catch statements will
not work with RaiseException. I guess the best option is to set a
breakpoint in _d_throwc.
LDC uses C++ exceptions, so your debugger should behave as expected when
building with LDC.
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: Visual D 1.1.0 released
On 06/03/2021 12:55, Imperatorn wrote: > On Saturday, 6 March 2021 at 06:59:28 UTC, Rainer Schuetze wrote: >> >> >> On 05/03/2021 12:26, Imperatorn wrote: >>> On Friday, 5 March 2021 at 10:57:05 UTC, Kagamin wrote: On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote: > https://filebin.net/19gupoeedfdjx5tx > > One GIF is the behaviour in C# I would like to have in D as well > with static if, and the other is displaying typeid on hover. The second is a debug session. Visual Studio doesn't show type information in debug session for C# either, only variable name and value. >>> >>> True, but could it? >> >> Visual D already does that with the help of the semantic highlighting: >> if an identifier is classified as a type or compile time value, it >> suppresses the debugger data tool tip and presents the usual one. > > Oh, I see. What about dub integration. How much effort would it be to > have something similar to what code-d has in vsc? Guesstimation? I'm not much of a dub user. Last time I checked, using it as a package manager was fine, but not as a build tool. Dependency checks were incomplete and rather slow. The visuald project generation is pretty dated and doesn't support multiple configurations which kind of breaks the usual VS workflow. I think for better integration dub project generation needs to be improved (and extended to vcxproj files), or Visual D has to do it itself from "dub describe" (if that's possible). The latter would also allow seamless updates of the project in the background. Then, integration of package management can be considered.
Re: Visual D 1.1.0 released
On 05/03/2021 12:26, Imperatorn wrote: > On Friday, 5 March 2021 at 10:57:05 UTC, Kagamin wrote: >> On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote: >>> https://filebin.net/19gupoeedfdjx5tx >>> >>> One GIF is the behaviour in C# I would like to have in D as well with >>> static if, and the other is displaying typeid on hover. >> >> The second is a debug session. Visual Studio doesn't show type >> information in debug session for C# either, only variable name and value. > > True, but could it? Visual D already does that with the help of the semantic highlighting: if an identifier is classified as a type or compile time value, it suppresses the debugger data tool tip and presents the usual one.
Re: Visual D 1.1.0 released
On 04/03/2021 14:43, James Lu wrote: > On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: >> Hi, >> >> development on Visual D, the Visual Studio extension that adds D >> language support to VS 2008-2019, has been rather slow recently, but >> finally the results of recent months have been released. >> >> Some highlights of this new version: >> >> - semantic engine updated to frontend 2.095.1 >> >> - adds "adornments" (Visual Studio terminology) to the call >> site of parameters that are passed by (mutable) ref, out or lazy. See >> https://rainers.github.io/visuald/visuald/images/parameterstorage.png >> for some examples. >> >> - integrates dfmt for command "Format Document" >> >> See https://rainers.github.io/visuald/visuald/VersionHistory.html for >> a full list of changes. >> >> You can find the update installer or a full installer bundled with >> latest versions of DMD and LDC here: >> >> https://rainers.github.io/visuald/visuald/StartPage.html >> >> Cheers, >> Rainer > > Hi, > > I've gotten D articles to the frontpage of Hacker News 4 times. > > I think this would be a good candidate to get to the frontpage of Hacker > News again. > > I want you to submit it to Hacker News, then add a comment saying: > > * Explain why you made this > * Explain what's interesting about Visual D > * Offer to explain questions > > Use the title: "Visual Studio Code for D Language 1.1.0" Thanks for the suggestion. I'm not a user of these social news sites, though, and even don't have time to keep track of discussions on the D forums lately. BTW: Visual D is not an extension for VS Code, but plain ol' Visual Studio.
Re: Visual D 1.1.0 released
On 04/03/2021 14:29, Imperatorn wrote: > A few questions. > > How hard would the following be: > > 1. Highlight code as dead or alive in static if > > 2. Show typeid when hovering over a variable > Adding to what Bastiaan said: "Lowlighting" disabled code in static if() similar to debug/version conditions is on my list of things to implement, but indeed, it might get confusing in templates because a random instantiation is currently used to show semantic information for its members. Hovering a variable should show its type in the tool tip (note that you can click the type in the tip to jump to its definition). But your example shows that there is a problem with the expression "typeid(T)", as no information is shown when hovering T inside the parenthesis. Probably an omission in the visitor.
Re: Visual D 1.1.0 released
On 04/03/2021 00:07, Bastiaan Veelo wrote: > On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: >> You can find the update installer or a full installer bundled with >> latest versions of DMD and LDC here: >> >> https://rainers.github.io/visuald/visuald/StartPage.html > > For clarity, the converse is not true. If you use the official dmd > installer (.exe) and select "Download Visual D" in it then you end up > with only version 0.50 of VisualD. Version 0.50 was the first to include automatic checks for updates, so it is hopefully not that much of a problem. But point taken, the DMD installer should be updated from time to time, too. Or just check for the latest version...
Visual D 1.1.0 released
Hi, development on Visual D, the Visual Studio extension that adds D language support to VS 2008-2019, has been rather slow recently, but finally the results of recent months have been released. Some highlights of this new version: - semantic engine updated to frontend 2.095.1 - adds "adornments" (Visual Studio terminology) to the call site of parameters that are passed by (mutable) ref, out or lazy. See https://rainers.github.io/visuald/visuald/images/parameterstorage.png for some examples. - integrates dfmt for command "Format Document" See https://rainers.github.io/visuald/visuald/VersionHistory.html for a full list of changes. You can find the update installer or a full installer bundled with latest versions of DMD and LDC here: https://rainers.github.io/visuald/visuald/StartPage.html Cheers, Rainer
Re: Visual D 1.0.1 released
On 25/08/2020 22:37, Per Nordlöw wrote: > On Sunday, 23 August 2020 at 07:33:01 UTC, Rainer Schuetze wrote: >> The most important part of the update is that the semantic engine is >> now based on the latest compiler release 2.093.1. > > - Does the engine have a feature list? Unfortunately the feature list in the documentation has bitrotten a bit. You can get an idea of the functionality from the interface file: https://github.com/dlang/visuald/blob/master/vdc/ivdserver.d > - Is the engine relatively independent of Windows? Mostly, but the interface to the IDE, which is a Local COM server. > - Does engine integrate with language server (in a platform independent > way)? The concept is similar, but predates the Language Server protocol. Last time I tried, LSP based language services don't work well together with other services for the same language in Visual Studio. > - Are there any plans for cross-platform (Linux) support? Not really. I think most of the code could be integrated with the dmd code base (changeset is https://github.com/dlang/dmd/compare/stable...rainers:dmdserver), but I currently don't have too much time for that. That way an LSP based service could be adopted to provide similar functionality. > > I'm dying to get a semantic engine that supports code navigation to (and > completion of) overloaded functions at their call site including > UFCS-calls. DCD doesn't support these two features. Navigation should be fine, but completion is usually on non-compilable code, so it's not always perfect. IMO it has improved in comparison to the DParser based engine, though.
Re: Visual D 1.0.1 released
On 25/08/2020 07:25, mw wrote: > On Sunday, 23 August 2020 at 07:33:01 UTC, Rainer Schuetze wrote: >> Hi, >> >> an update for Visual D has just been made available. Visual D is a >> Visual Studio extension that adds D language support to VS 2008-2019. >> >> The most important part of the update is that the semantic engine is >> now based on the latest compiler release 2.093.1. There are a few >> other improvements and bug fixes, e.g. support for navigation with >> forward/backward mouse buttons and fixed documentation tool tips for >> template functions. >> >> See the full version history here: >> https://rainers.github.io/visuald/visuald/VersionHistory.html >> >> You can download the update installer or the full installer bundled >> with DMD 2.093.1 and LDC 1.23.0 from >> >> https://rainers.github.io/visuald/visuald/StartPage.html >> > > > Thanks for the update. > > I just tried, and found two issues: > > https://issues.dlang.org/show_bug.cgi?id=21193 > https://issues.dlang.org/show_bug.cgi?id=21194 > > Basically, I cannot build unit-threaded_property.lib (saying corrupt MS > Coff object) with VisualD, but I can build on Windows using command line: > > C:\project\dlang\dmd-2.093.1\windows\bin64\dub.exe test --build=unittest > I responded in the bug reports, I suspect some issue with dub's project generation.
Re: Release D 2.093.1
On 24/08/2020 10:09, Martin Nowak wrote: > Glad to announce D 2.093.1, ♥ to the 13 contributors. > > http://dlang.org/download.html Thanks, Martin. The Visual D update mechanism notified about this release about a week ago, even earlier than the usual 1 or 2 days. This probably happens because the LATEST link in the release archive had already been updated at the time. Did the release binaries change after the link has been updated? In that case I might have to update the Visual D full installers, too.
Visual D 1.0.1 released
Hi, an update for Visual D has just been made available. Visual D is a Visual Studio extension that adds D language support to VS 2008-2019. The most important part of the update is that the semantic engine is now based on the latest compiler release 2.093.1. There are a few other improvements and bug fixes, e.g. support for navigation with forward/backward mouse buttons and fixed documentation tool tips for template functions. See the full version history here: https://rainers.github.io/visuald/visuald/VersionHistory.html You can download the update installer or the full installer bundled with DMD 2.093.1 and LDC 1.23.0 from https://rainers.github.io/visuald/visuald/StartPage.html Cheers, Rainer
Re: Visual D 1.0.0 released
On 12/07/2020 23:35, Rainer Schuetze wrote: > > > On 12/07/2020 11:11, greatsam4sure wrote: > [...] >> 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 > [...] >> echo legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files >> (x86)\Microsoft Visual >> Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86" >> /LIBPATH:"C:\Program Files (x86)\Windows >> Kits\10\Lib\10.0.18362.0\ucrt\x86" > [...] >> >> LINK : fatal error LNK1181: cannot open input file 'user32.lib' >> Building Win32\Debug\WindowsApp2.exe failed! > > > I suspect you don't have the Windows SDK installed with Visual Studio. > user32.lib is usually found in "C:\Program Files (x86)\Windows > Kits\10\lib\10.0.18362.0\um\x86", but that path is not passed on the > command line with /LIBPATH. > On second thought: if you installed the SDK after Visual D, the settings in "Tools -> Options -> Projects and Solutions -> Visual D Settings -> DMD directories -> Win32 COFF32 -> Library Paths" might not reflect that (it should contain something like $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86). You can also click "Reset Settings" on the Visual D settings page to correct that.
Re: Visual D 1.0.0 released
On 12/07/2020 11:11, greatsam4sure wrote: [...] > 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 [...] > echo legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files > (x86)\Microsoft Visual > Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86" > /LIBPATH:"C:\Program Files (x86)\Windows > Kits\10\Lib\10.0.18362.0\ucrt\x86" [...] > > LINK : fatal error LNK1181: cannot open input file 'user32.lib' > Building Win32\Debug\WindowsApp2.exe failed! I suspect you don't have the Windows SDK installed with Visual Studio. user32.lib is usually found in "C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x86", but that path is not passed on the command line with /LIBPATH.
Re: Visual D 1.0.0 released
On 10/07/2020 09:14, Jacob Carlborg wrote: > On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote: > >> There is an extension using DLS as an LSP: >> https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang >> >> >> It's been some time, but when I tried to use that along side Visual D, >> it caused problems because both are trying to be a language service >> for the same language. > > I was more hoping for the engine in VisualD to be the new DCD or DLS, > since it's already using the DMD frontend for some things. Then it can > be used by other editors and IDEs, hint hint, wink wink ;) The semantic engine shouldn't be too hard to extract, as it is already running as a separate process. It just uses a protocol that predates LSP.
Re: Visual D 1.0.0 released
On 09/07/2020 14:14, Jacob Carlborg wrote: > On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote: > >> What I really wish is we had a single shared codebase for dlang editor >> support, that could be shared among editor extension writers, instead >> of having many community members working on competing solutions. > > That would be really nice. Doesn't Visual Studio (not VSCode) supports > LSP these days? > There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language.
Re: Visual D 1.0.0 released
On 10/07/2020 07:07, Petar Kirov [ZombineDev] wrote: > I don't care about the VS debug engine since it's Windows only. Some of > the UX may be nice to replicate, but think this falls outside big the > scope of a dlang editor extension, if said editor already has general > native code debugging functionality. Actually the Microsoft C++ extension for VS Code also uses the Concord debug engine, but unfortunately it is not extendible as in VS (yet), see https://github.com/microsoft/vscode-cpptools/issues/2932 > Also some people even disagree that VS is better than GDB in general: > https://www.quora.com/Why-is-the-Visual-Studio-C%2B%2B-debugger-much-better-than-GDB-LLDB-or-any-other-debugger-for-C%2B%2B?ch=10=b4f38907=3E2D0 > > > Even if if I agree that VS provides a better debugging experience than > VS Code, GDB is more powerful tool overall, so I don't miss Concorde on > Linux. I think gdb can be compared with windbg. They both have great in-depth functionality. UX wise both are not so well, but it all depends on the front-end built on top of them. The usual downside is that remoting the text-interface can be incredibly slow.
Re: Visual D 1.0.0 released
On 08/07/2020 10:11, Walter Bright wrote: > On 7/7/2020 6:26 PM, Manu wrote: >> The difference is night vs day... VisualD is, by far, like REALLY FAR, >> the most mature and useful IDE and debug environment for D. >> TL;DR: if you are a D dev, and you use Windows, you should definitely >> try Visual Studio + VisualD. I for one couldn't work without it! > > One great thing about Rainer doing VisualD is he has leveraged that to > make crucial changes to dmd's output to better work with the Visual > debugger. My first open source project was cv2pdb, a tool that converts old-style CodeView debug information generated by optlink to a PDB file. Now that this functionality is more or less available in dmd itself when compiling to COFF object files, cv2pdb seems to be more popular among C++ people using gcc on Windows, because it also allows to convert DWARF to PDB.
Re: VisualD Can now execute class/struct methods __debugOverview, __debugExpaanded, __debugTextView to customize display in the debugger
On 05/07/2020 22:25, FunkyD wrote: > On Sunday, 5 July 2020 at 18:58:50 UTC, Rainer Schuetze wrote: [...] I could not reproduce crashes with your code. > > Also, in the general options it has debug[Overview|Expanded|Visualizer]. > The help seems inconsistent with the various _debug functions. > The __debugVisualizer was an intermediate version of the name, I'll fix that. > There seems to be a bug somewhere. > > I started a different project and copied that code and it works! I > originally had it in another project. The new project has Visual Studio > x86 mixed mode set for the debugger! I thought I read that it must be mago. > > So it seems to work but there seems to be a bug that causes a crash and > does not properly handle. > > > Ok, I changed the old project back from mago to VSx86MM and it works. So > this seems to be an issue with mago. The mago debug *engine* is considered legacy for Visual Studio versions that don't have a recent "Concord" debugger, i.e. 2013 or earlier. Most of its code is shared with the mago debugger *extension*, though, but only the latter supports function execution. > > mago debugger > > can now evaluate class/struct methods/fields __debugOverview, > __debugExpanded, __debugTextView to customize display in the debugger > experimental: can now display ranges similar to arrays > some performance improvements by caching some data while the > debuggee is stopped > > > I assumed mago debugger meant for mago debugger. In any case, the crash > is not good(happens when I go from locals to watch). Might be that some of the new functionality is not properly disabled with the debug engine.
Re: Visual D 1.0.0 released
On 04/07/2020 15:00, Rainer Schuetze wrote: > - debugger extension mago will now evaluate struct or class properties > (methods or fields) __debugOverview, __debugExpanded and __debugTextView > to customize the debugger display. mago can even display forward ranges > as a list, but that is currently rather slow, so it is disabled by > default (see debugger options). > I have added some documentation and screenshots here: https://rainers.github.io/visuald/visuald/Debugging.html#customization
Re: VisualD Can now execute class/struct methods __debugOverview, __debugExpaanded, __debugTextView to customize display in the debugger
On 05/07/2020 14:10, FunkyD wrote: > Can now execute class/struct methods __debugOverview, __debugExpaanded, > __debugTextView > to customize display in the debugger > > ? How does one use these I can't find anything else about them, not in > the source code. > I have added some documentation here: https://rainers.github.io/visuald/visuald/Debugging.html#customization
Re: Visual D 1.0.0 released
On 04/07/2020 17:16, Arafel wrote: > On 4/7/20 15:00, Rainer Schuetze wrote: >> Hello, >> >> after having passed the 10 year anniversary of public availability >> recently, it is finally time to release version 1.0 of Visual D, the >> Visual Studio extension that adds D language support to VS 2008-2019. >> >> You can find the installer at >> http://rainers.github.io/visuald/visuald/StartPage.html >> >> Highlights from this release: >> >> - semantic engine based on dmd front end now enabled by default and >> updated to 2.092. If you are low on memory or run a 32-bit Windows, you >> should switch back to the legacy engine. >> >> - debugger extension mago will now evaluate struct or class properties >> (methods or fields) __debugOverview, __debugExpanded and __debugTextView >> to customize the debugger display. mago can even display forward ranges >> as a list, but that is currently rather slow, so it is disabled by >> default (see debugger options). >> >> - the bar on the top of the edit window now displays the current edit >> scope and allows faster navigation within a source file (needs the dmd >> based engine) >> >> - ever wondered how to navigate to the type of a variable declared by >> `auto` inference? clicking an identifier in a tool tip from intellisense >> will now jump to its definition (only with the dmd based engine) >> >> See https://rainers.github.io/visuald/visuald/VersionHistory.html for >> the complete list of changes. >> >> Cheers, >> Rainer >> > > Looks great! > > I could only see windows installers though, and at first sight it seems > to be Win only... is there any chance it would work with VSCode for > linux / VSCodium (even if built manually)? > Indeed, this is Windows only. Visual Studio Code is a different platform than Visual Studio. Not sure why Microsoft named them so that they are easily confused.
Visual D 1.0.0 released
Hello, after having passed the 10 year anniversary of public availability recently, it is finally time to release version 1.0 of Visual D, the Visual Studio extension that adds D language support to VS 2008-2019. You can find the installer at http://rainers.github.io/visuald/visuald/StartPage.html Highlights from this release: - semantic engine based on dmd front end now enabled by default and updated to 2.092. If you are low on memory or run a 32-bit Windows, you should switch back to the legacy engine. - debugger extension mago will now evaluate struct or class properties (methods or fields) __debugOverview, __debugExpanded and __debugTextView to customize the debugger display. mago can even display forward ranges as a list, but that is currently rather slow, so it is disabled by default (see debugger options). - the bar on the top of the edit window now displays the current edit scope and allows faster navigation within a source file (needs the dmd based engine) - ever wondered how to navigate to the type of a variable declared by `auto` inference? clicking an identifier in a tool tip from intellisense will now jump to its definition (only with the dmd based engine) See https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete list of changes. Cheers, Rainer
Re: VisualD DParserComServer madness(100+)
On 14/05/2020 11:53, Guillaume Piolat wrote: > On Sunday, 23 February 2020 at 17:24:19 UTC, Rainer Schuetze wrote: >> >> >> On 22/02/2020 14:11, BetaDamnit wrote: >>> https://ibb.co/7R8wsXG >>> >>> I have no idea where they come from... I closed down VS hours ago and >>> just now opened the task manager and saw all of them. >>> >>> Taskkill /IM DParserCOMServer.exe /F >>> >>> does work but it is not a solution. >> >> I suspect that these are remainders of Visual Studio crashing for some >> reason. The server used to terminate itself after a minute of not >> being connected to any instance of Visual D, but that seems to no >> longer work... > > Hi, I have the same problem unfortunately. It makes Visual D barely > usable, and need computer reboot after a while (didn't know about > Taskkill). Does it happen with the dmd-based engine, too?
Re: Visual D 0.52.0 released
On 24/03/2020 12:01, ShadoLight wrote: > On Tuesday, 24 March 2020 at 10:55:28 UTC, ShadoLight wrote: >> On Monday, 23 March 2020 at 09:54:46 UTC, Rainer Schuetze wrote: >>> Hi, >>> >>> a new version of Visual D, the Visual Studio extension that adds D >>> language support to VS2008-2019, is available at >>> >> [snip] >> >> As always - VisualD is highly appreciated Rainer! >> >> A minor issue (typo probably), the installer shows "Install in VS2005" >> as the 1st option, not "Install in VS2008". >> >> In fact, there is no option for installation to target VS2008, so I >> suspect this is just a typo since, AFAIK, you don't support VS2005 >> anymore. >> >> This does not affect me, so no need to fix this on my behalf. Don't >> know about others, but I suspect VS2008 usage is sufficiently rare >> that this is not urgent. > > Hmm, I re-checked and it doesn't show VS2010 either... maybe it is > picking up that I had to install VS2005 recently to repair some old > project that had to remain in VS2005 project format? > > In my case VisualD installer only shows VS2005, and then all options > from vS2013 onwards (even if not installed). Versions before VS2013 are no longer shown, if they are not detected to be installed (the installer already does this for a couple of releases). This is to avoid a long list of ancient versions that very few use and that are only partly supported anyway. The installer even detects VS.NET 2003.
Re: Visual D 0.52.0 released
On 24/03/2020 03:31, Dylan Graham wrote: > On Monday, 23 March 2020 at 09:54:46 UTC, Rainer Schuetze wrote: >> Hi, >> >> a new version of Visual D, the Visual Studio extension that adds D >> language support to VS2008-2019, is available at >> >> [...] > > Nvm it didn't hang. Just took a very long time to complete semantic > highlighting. I guess dmd doesn't take as long to compile the file, does it? Does it happen on specific code? Are you able to share it? I usually try the engine on Visual D and dmd, and semantic highlighting can take a couple of seconds, but it doesn't feel very different from C++.
Re: Visual D 0.52.0 released
On 24/03/2020 03:30, Dylan Graham wrote: > Restarting Visual Studio and terminating the server seems to fix the > issue, until it happens again 15 minutes later. BTW: you don't need to restart Visual Studio, killing dmdserver.exe is enough, it will be automatically restarted and reconnected.
Visual D 0.52.0 released
Hi, a new version of Visual D, the Visual Studio extension that adds D language support to VS2008-2019, is available at https://rainers.github.io/visuald/visuald/StartPage.html Major highlights of this release are - improvements to the DMD based semantic engine: it has been updated to the frontend version 2.091, and code-completion has improved quite a bit, so much that I would recommend everyone to actually try it (unless you have too little RAM installed to cope with the frontends hunger for memory). Use "Visual D -> Open Language options..." from the menu to enable the "DMD parsing engine" as well as "Colorize identifiers from semantic analysis" on the "Editor" options page. - the debugger expression evaluation now has support for tuples and simpler display of global variables (it's no longer necessary to specify the fully qualified name) - updated support for all language options (e.g. -preview), these are also forwarded to the DMD based code analysis The full version history can be found at https://rainers.github.io/visuald/visuald/VersionHistory.html Cheers, Rainer
Re: Beta 2.091.0
On 05/03/2020 06:15, Andre Pany wrote: >>> Small remark: To get dub working you need to copy it from bin folder >>> to bin64 folder manually. Just adding folders `bin64` and `bin` to >>> PATH does not work because Dub will you `dmd` from current folder. >> [...] > > Yes, adding a64 bit version of dub to bin64 would solve the issue. > I also agree with you, there is no need to make the 64 version the default. > It should just be possible, by extracting the DMD zip archive and setting > environment variable PATH to bin64 to have a working dmd & dub integration. > > Another solution would also be to have 2 dmd windows zip archives like > you have it > for FreeBSD: > dmd.2.090.0.freebsd-32.zip > dmd.2.090.0.freebsd-64.zip > But this requires more effort I assume, maybe this is a solution for the > long ran The 64-bit binaries only add a couple of MB to the installer exe/7z, so it's probably not required to split them up. > and the low hanging fruit for the moment is to add a 64 dub executable > to the dmd zip archive. https://github.com/dlang/installer/pull/445 > > Kind regards > André
Re: Beta 2.091.0
On 26/02/2020 15:23, Andre Pany wrote: > On Wednesday, 26 February 2020 at 14:11:58 UTC, Andre Pany wrote: >> On Wednesday, 26 February 2020 at 12:17:43 UTC, Martin Nowak wrote: >> >> Thank you so much Rainer for adding the 64 bit dmd compiler to the >> windows installation package. Also building DMD with LDC is such a >> huge improvement. Thank you Sebastian. >> This is really great news! >> >> Kind regards >> André > > Small remark: To get dub working you need to copy it from bin folder to > bin64 folder manually. Just adding folders `bin64` and `bin` to PATH > does not work because Dub will you `dmd` from current folder. I guess by "working" you mean that dub uses the 64-bit version of dmd. We could add a 64-bit version of dub to the bin64 folder, too, but I'm not sure the bin64 version of the compiler has to be the default. It uses almost twice as much memory and hence is a bit slower: dmd.exe -m64 -c -unittest std\regex\internal\tests.d 32-bit dmd: 853 MB, 3.280 sec 64-bit dmd: 1445 MB, 3.740 sec > > I just tested the performance improvement and it feels twice as fast as > before! dmd 2.090.0: 879 MB, 10.230 sec (released without optimizations) dmd 2.090.1: 873 MB, 5.300 sec
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: DIP 1027---String Interpolation---Format Assessment
On 27/02/2020 01:20, Walter Bright wrote: > On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote: >> In all other languages with string interpolation that I'm familiar >> with, `a` is not passed to the `i` parameter. > > All rely on a garbage collected string being generated as an > intermediate variable. The string buffer could also be stack allocated or manually managed with malloc/free by the string interpolation type.
Re: Visual D debugger tuple _expand_field
On 20/02/2020 23:03, BetaDamnit wrote: > _expand_field > > takes up a huge amount of space for no reason. I think tuple scan be > safely listed like arrays. We know they are tuples, no need to display > _expand_field=, it just takes up a lot of space in the display for no > reason, specially if there are several elements in the tuple. > This is the result of the compiler lowering the tuple to a number of variables ___field_. No info is generated about this being a structure-like compound. I have added support to the debugger to recombine these variables to an expandable array, but it wasn't actually trivial: https://github.com/rainers/mago/commit/451f856fd70a311460af1153ce1a1647059b5d89 It will be in the next release.
Re: VisualD DParserComServer madness(100+)
On 22/02/2020 14:11, BetaDamnit wrote: > https://ibb.co/7R8wsXG > > I have no idea where they come from... I closed down VS hours ago and > just now opened the task manager and saw all of them. > > Taskkill /IM DParserCOMServer.exe /F > > does work but it is not a solution. I suspect that these are remainders of Visual Studio crashing for some reason. The server used to terminate itself after a minute of not being connected to any instance of Visual D, but that seems to no longer work...
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: Visual D 0.51.0 - semantic engine based on dmd frontend
On 21/01/2020 00:07, kinke wrote: > On Monday, 20 January 2020 at 22:10:58 UTC, Rainer Schuetze wrote: >> That can happen when the semantic analysis asserts and crashes the >> background process. >> >> It works better if you also configure the LDCshared project to define >> version identifiers MARS and IN_LLVM (separated by a ';' as in >> "MARS;IN_LLVM"), set the string import path "../ldc/res" and disable >> warnings for deprecations. > > Thx again, now I'm finally getting somewhere! Wrt. earlier, > dmdserver.exe was still running in the background (but had only consumed > 3 secs of CPU time and didn't seem to do anything anymore). Btw nice > that that's a 64-bit executable, lots of memory for huge projects... I could avoid the crashes with this change to dmd: https://github.com/rainers/dmd/commit/2b3fc197bd86fc358f349182798d8142f1564177 BTW: Don't miss to enable "Colorize identifiers from semantic analysis" for more colorful editing. This also helps the debugger a bit by identifying compile time entities that should not be displayed in a data tooltip, but the regular one which can show aliases and enum values not found in the debug information.
Re: Visual D 0.51.0 - semantic engine based on dmd frontend
On 20/01/2020 14:48, kinke wrote: > On Sunday, 19 January 2020 at 07:04:35 UTC, Rainer Schuetze wrote: >> If you switch "Item Type" of one of the D files to use the "D >> Compiler", you can set the import path to "..\ldc" so the engine can >> find imported files. > > After figuring that one has to open the file properties via right-click > (i.e., not available in the quick properties or however they are > called), that worked, thx. > > It doesn't get past the 'Analyzing...' stage though (in tooltips), no > [IntelliSense] errors show up in the errors pane. That can happen when the semantic analysis asserts and crashes the background process. It works better if you also configure the LDCshared project to define version identifiers MARS and IN_LLVM (separated by a ';' as in "MARS;IN_LLVM"), set the string import path "../ldc/res" and disable warnings for deprecations.
Re: Visual D 0.51.0 - semantic engine based on dmd frontend
On 19/01/2020 04:32, kinke wrote: > On Saturday, 18 January 2020 at 22:32:00 UTC, Rainer Schuetze wrote: >> It's not in the project configuration, but the global options >> "Tools->Options->Text Editor->D->Intellisense" > > Thx! I've immediately stumbled on an apparent missing import dir with > the LDC solution, i.e., the project's src dir root doesn't seem to get > added - no problem with the old engine. > > To reproduce: > * cmake -G "Visual Studio 16 2019" -A x64 -DLLVM_ROOT_DIR=... > -DD_COMPILER=...\ldmd2 ...\ldc-src > * Open solution > * Open any .d file in the LDCShared project and notice that all imports > fail with the new engine It seems the problem is that LDC doesn't use the Visual D integration into msbuild, but custom build rules. That hides the import settings. If you switch "Item Type" of one of the D files to use the "D Compiler", you can set the import path to "..\ldc" so the engine can find imported files. The old engine scans the source folder for any D files, but that can also cause problems if there are multiple versions of the same module in some subdirectory.
Re: Visual D 0.51.0 - semantic engine based on dmd frontend
On 18/01/2020 22:25, kinke wrote: > On Saturday, 18 January 2020 at 14:22:41 UTC, Rainer Schuetze wrote: >> It is still considered experimental and has to be enabled on the >> respective language options page. > > Is there a way to enforce it, e.g., via registry or by hacking the > project files, for regular VS projects (such as the VS solution for LDC > generated by CMake)? I can't find any such options page. > It's not in the project configuration, but the global options "Tools->Options->Text Editor->D->Intellisense" or via the Visual D menu "Open Language Options...".
Re: Visual D 0.51.0 - semantic engine based on dmd frontend
On 18/01/2020 17:43, Sebastiaan Koppe wrote: > On Saturday, 18 January 2020 at 14:22:41 UTC, Rainer Schuetze wrote: >> This version features a first version of an intellisense engine that >> is based on the DMD frontend (as of version 2.090) for semantic >> analysis. It is still considered experimental and has to be enabled on >> the respective language options page. >> >> Cheers, >> Rainer > > Nice, that is awesome. Could the engine also be re-used for in e.g. the > D lsp server? Sure, this should be possible. This is the used dmd fork: https://github.com/rainers/dmd/tree/dmdserver and most of the client code is here: https://github.com/dlang/visuald/tree/master/vdc/dmdserver The frontend doesn't make it easy to implement other functionality like refactoring and formatting, though. On the other hand, running both libdparse and another engine in parallel doesn't seem desirable, too. So it is not easy to get the best of both engines (it is currently similar with DParser and dmdserver).
Visual D 0.51.0 - semantic engine based on dmd frontend
Hello, I'm happy to announce the release of Visual D 0.51.0. Visual D is a Visual Studio extension that adds D language support to VS2008-2019. The installers can be found at http://rainers.github.io/visuald/visuald/StartPage.html This version features a first version of an intellisense engine that is based on the DMD frontend (as of version 2.090) for semantic analysis. It is still considered experimental and has to be enabled on the respective language options page. When comparing this new engine to the regular engine which is based on DParser that used to power Mono-D: - it does a full semantic analysis and shows the same errors as dmd would do. DParser only marks parser issues. - browsing compilable code works quite well (e.g. inference of auto types is not an issue anymore). - semantic highlighting is faster and more accurate. - completion is yet not very good, especially while the currently edited code has parsing errors. - as dmd itself it can require quite a bit of memory, though a variety of false and stale pointer issues have been fixed to help the precise GC. Other highlights of this release: - Ctrl+Click goto definition added for VS2017+ - visualdproj projects: basic DUB support: upgrade and refresh if project contains dub.json or dub.sdl See https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete list of changes Cheers, Rainer
Re: DIP 1024---Shared Atomics---Accepted
On 02/01/2020 09:01, Manu wrote: > On Thu, Jan 2, 2020 at 4:45 PM Walter Bright via > Digitalmars-d-announce wrote: >> >> On 1/1/2020 9:53 PM, Manu wrote: >>> On Thu, Jan 2, 2020 at 3:40 PM Mike Parker via Digitalmars-d-announce >>> wrote: DIP 1024, "Shared Atomics", was accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1024.md >>> >>> This has been a long time coming! >> >> A New Year's present for all of us! > > Quick quick, we need a PR to issue deprecation messages for those > invalid read/writes! :) > Before making the new semantics the default, the next step should be to make druntime and phobos compile with the preview-switch. That didn't seem like a no-brainer to me when I recently tried that (but only for a couple of minutes), especially with shared being applied to class/struct declarations.
Re: On the Blog: Recent D Compiler Releases
On 08/01/2020 09:50, Mike Parker wrote: > I've posted an overview of LDC 1.19.0 and DMD 2.090.0 on the blog, and a > reminder that GDC is available as part of the GCC 9 series. > > The blog: > https://dlang.org/blog/2020/01/08/recent-d-compiler-releases/ > > Reddit: > https://www.reddit.com/r/programming/comments/elq5yx/recent_d_compiler_releases_ldc_dmd_and_gdc/ > Thanks Mike! >With the current GC implementation, it’s illegal to perform any GC operations during finalization. There are some exceptions, namely addRoot/addRange and removeRoot/removeRange and the iterators over roots or ranges. I guess it might be possible to support some querying functions during finalization, too.
Re: Release Candidate [was: Re: Beta 2.090.0]
On 30/12/2019 12:07, Martin Nowak wrote: > On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote: >> Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 >> contributors. >> >> http://dlang.org/download.html#dmd_beta >> http://dlang.org/changelog/2.090.0.html >> >> As usual please report any bugs at >> https://issues.dlang.org >> >> -Martin > > Release candidate is live now. The windows build is still considered "dirty", i.e.it reports version DMD32 D Compiler v2.090.0-rc.1-dirty. Is there something that can be done about that?
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: Visual D can't debug programs
On 01/12/2019 20:19, SkyCloud wrote: > Hi! Thank you so much for the answer. Platform is Windows 7 x64. I > checked all the settings you said but unfortunately nothing works. > > I recorded a short video with my attempts to debug a program. There are > two projects (VisualD and D/C++) with each type and one pure Visual C++ > project. Debugging works only in Visual C++ as I mentioned before. > https://1drv.ms/v/s!Ar5BCn3roz_ahSoJMf5pVZTdHYGY > > I will be glad if you see it and find anything that can help me. As you can step into C main (the function calling _d_run_main), it seems that the debugger is setup correctly and is working, but doesn't accept the breakpoint set in D's main function. I suspect that it doesn't work correctly because your user folder contains non-ascii characters that might be encoded badly in the generated debug info. Try moving the project to a different folder.
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: Visual D seems to have a new bug
On 04/10/2019 01:48, Brett wrote:
> On Thursday, 3 October 2019 at 12:04:50 UTC, Rainer Schuetze wrote:
>>
>> On 01/10/2019 17:41, Brett wrote:
>>> this 0x016ff0f6b588 {0x0001} P**
>>> + 0x0001 P*
>>> - This {x=131071} P
>>>
>>> auto This = this;
>>>
>>> This is not showing as a pointer, this is a double pointer and seems
>>> to be referring to the first value.
>>
>> The double indirection looks bad. I don't think that mago adds
>> indirections, it only removes some to reduce clutter.
>>
>> I suspect that the debug info is broken. The best tool for dumping it
>> is
>> https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe
>
>
> That may very well be because I did just recently update dmd and this is
> when I noticed it... I'm not sure if I updated visual d around that time
> or not.
Could also be due to updates of Visual Studio 2019: I just noticed that
a function wasn't showing any locals. These reappear when setting the VC
linker debug option to "FULL". If you are using a visualdproj project
you currently have to add -L/DEBUG:FULL to the additional command line
options to get the same result.
Re: Visual D seems to have a new bug
On 01/10/2019 17:41, Brett wrote:
> this 0x016ff0f6b588 {0x0001} P**
> + 0x0001 P*
> - This {x=131071} P
>
> auto This = this;
>
> This is not showing as a pointer, this is a double pointer and seems to
> be referring to the first value.
The double indirection looks bad. I don't think that mago adds
indirections, it only removes some to reduce clutter.
I suspect that the debug info is broken. The best tool for dumping it is
https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe
Re: Visual D seems to have a new bug
On 02/10/2019 18:04, Brett wrote: > I was able to build and copy the file and all that but when I attach and > add a BP on, say line 345 below the BP is missing and says symbols are > not loaded. I took all the pdb's and put them in a directory and added > the dir too the symbols dir in the VS options but it is still missing. > Also the "modules" are not showing any symbols for mago... all visual > studio stuff(mainly .net, not sure why they would be showing). > > "This breakpoints will not currently be hit. Symbols not loaded"... > > I use attach to process then find devenv.exe of the target D app(not the > app itself but the visual studio process running it since I imagine that > is the one running the mago dll). > Copying the pdb should not be necessary because it is referenced by the absolute path. I suspect that you have selected "Managed code" only when attaching to the process. You have to select/add "Native code".
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: Visual D seems to have a new bug
On 02/10/2019 07:46, Brett wrote:
> On Tuesday, 1 October 2019 at 18:44:37 UTC, Rainer Schuetze wrote:
>>
>>
>> On 01/10/2019 17:41, Brett wrote:
>>> On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote:
On 01/10/2019 06:05, Brett wrote:
> Variables are not showing properly. Specifically the trouble I'm
> having is with this pointers.
>
> I have a simple struct and toString and this shows in the
> watches/locals but it expands to not found:
>
> - this 0x028d3a7d12c8 {0x5da0e220}
> - 0x5da0e220
> x D0001: Error: Expression couldn't be evaluated
>
> simply doing auto This = this;
>
> This works.
>
> I've noticed other weird issues in the watches and locals not
> showing variables.
>
A test case would be helpful...
I can only suspect that 'this' is stored in some register, but that
it is not reflected in the debug information. It looks like your
struct contains a pointer, maybe the value shown doesn't point to
existing memory? Does `This` show the same pointer values, but
proper fields?
>>>
>>> - this 0x016ff0f6b588 {0x0001} P**
>>> + 0x0001 P*
>>> - This {x=131071} P
>>>
>>> auto This = this;
>>>
>>> This is not showing as a pointer, this is a double pointer and seems
>>> to be referring to the first value.
>>>
>>> Not sure if the address is right, probably is, seems the problem is
>>> that this is being treating as a **.
>>>
>>> I don't have any reduced test case now but it should be simple to do
>>> or find the bug I imagine.
>>>
>>> It literally is just
>>>
>>> struct P { long x; auto foo() { auto This = this; } }
>>>
>>> type of thing with a bunch of other stuff that is irrelevant to the
>>> problem.
>>>
>>> It shouldn't matter how P is being used(I am using pointers to P in
>>> arrays P*[] in some cases that may be throwing something off that is
>>> malformed already).
>>>
>>> But clearly since `auto This = this` is correct, this is either 1. A
>>> debugging map error(when it displays this automatically it screws up
>>> and dereferences it twice) or 2. Or most likely 1.
>>>
>>> The reason being is that the code uses this and works fine so it is
>>> no actually dereferencing junk.
>>>
>>> Recently you modified the code to fix a pointer bug with variables in
>>> the watch(null values I believe) and so chances are that screwed up
>>> this. It used to work fine so is a relatively new thing and the bug
>>> is clearly an extra dereferencing issue and only a "visual" problem.
>>>
>>>
>>
>> I cannot easily reproduce the issue, but it might already be fixed by
>> the same patch as the one avoiding crashes with pointers to empty arrays.
>>
>> You can try to replace "c:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or
>> similar path depending on the VS version) with the
>> Appveyor artifact here:
>> https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts
>>
>> This version also contains some of your recent suggestions.
>
> This did not fix it ;/ I'm not 100% sure I updated correctly but it
> seemed correct(The browser remembered the saved dir from last time and I
> just used it and overwrote the dll).
>
> Surely this should be a simple bug to find? Somewhere in the code this
> is automatically watched and for some reason it's type is off.
>
> Do you know the location of that code that you could paste a reference
> to? I'll look at it and see if I can see anything.
>
> I wonder if you could easily modify Visual D so that one could "break"
> in to it to do some debugging. It might be much easier. If, for example,
> I could run a piece of code that somehow triggers debugging of Visual D
> around the code being debugged(a BP of a BP in some sense) then it might
> be easier. I realize that it doesn't quite work this way but if I could
> just get some VisualD code to pop up in another debugger running
> parallel then I could debug some of these problems myself. I have had no
> success building visual D myself so if there was a debug build that
> worked I could download that and use it.
You don't have to compile Visual D, but mago:
https://github.com/rainers/mago
Ignore the readme, load MagoDbg_2010.sln into VS2013 or newer, and build
Expression/MagoNatCC for configuration "Debug Static DE|Win32". Then
replace the DLL in the VS debugger folder with
bin\Win32\Debug\MagoNatCC.dll.
If you hit an issue, you can start a new instance of VS with the mago
solution and attach its debugger to the other running VS (devenv.exe).
There is actually some automatic dereferencing going on (avoiding extra
nesting in watches) here
https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L213,
https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L315 and
Re: Visual D seems to have a new bug
On 01/10/2019 17:41, Brett wrote:
> On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote:
>>
>>
>> On 01/10/2019 06:05, Brett wrote:
>>> Variables are not showing properly. Specifically the trouble I'm
>>> having is with this pointers.
>>>
>>> I have a simple struct and toString and this shows in the
>>> watches/locals but it expands to not found:
>>>
>>> - this 0x028d3a7d12c8 {0x5da0e220}
>>> - 0x5da0e220
>>> x D0001: Error: Expression couldn't be evaluated
>>>
>>> simply doing auto This = this;
>>>
>>> This works.
>>>
>>> I've noticed other weird issues in the watches and locals not showing
>>> variables.
>>>
>>
>> A test case would be helpful...
>>
>> I can only suspect that 'this' is stored in some register, but that it
>> is not reflected in the debug information. It looks like your struct
>> contains a pointer, maybe the value shown doesn't point to existing
>> memory? Does `This` show the same pointer values, but proper fields?
>
> - this 0x016ff0f6b588 {0x0001} P**
> + 0x0001 P*
> - This {x=131071} P
>
> auto This = this;
>
> This is not showing as a pointer, this is a double pointer and seems to
> be referring to the first value.
>
> Not sure if the address is right, probably is, seems the problem is that
> this is being treating as a **.
>
> I don't have any reduced test case now but it should be simple to do or
> find the bug I imagine.
>
> It literally is just
>
> struct P { long x; auto foo() { auto This = this; } }
>
> type of thing with a bunch of other stuff that is irrelevant to the
> problem.
>
> It shouldn't matter how P is being used(I am using pointers to P in
> arrays P*[] in some cases that may be throwing something off that is
> malformed already).
>
> But clearly since `auto This = this` is correct, this is either 1. A
> debugging map error(when it displays this automatically it screws up and
> dereferences it twice) or 2. Or most likely 1.
>
> The reason being is that the code uses this and works fine so it is no
> actually dereferencing junk.
>
> Recently you modified the code to fix a pointer bug with variables in
> the watch(null values I believe) and so chances are that screwed up
> this. It used to work fine so is a relatively new thing and the bug is
> clearly an extra dereferencing issue and only a "visual" problem.
>
>
I cannot easily reproduce the issue, but it might already be fixed by
the same patch as the one avoiding crashes with pointers to empty arrays.
You can try to replace "c:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or
similar path depending on the VS version) with the
Appveyor artifact here:
https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts
This version also contains some of your recent suggestions.
Re: Visual D seems to have a new bug
On 01/10/2019 06:05, Brett wrote:
> Variables are not showing properly. Specifically the trouble I'm having
> is with this pointers.
>
> I have a simple struct and toString and this shows in the watches/locals
> but it expands to not found:
>
> - this 0x028d3a7d12c8 {0x5da0e220}
> - 0x5da0e220
> x D0001: Error: Expression couldn't be evaluated
>
> simply doing auto This = this;
>
> This works.
>
> I've noticed other weird issues in the watches and locals not showing
> variables.
>
A test case would be helpful...
I can only suspect that 'this' is stored in some register, but that it
is not reflected in the debug information. It looks like your struct
contains a pointer, maybe the value shown doesn't point to existing
memory? Does `This` show the same pointer values, but proper fields?
Re: Visual D values and pointers taking lots of space
On 30/09/2019 22:09, Brett wrote: > In the debugger windows, pointers and values in hex take a lot of space. > In 64-bit this can take up a lot of room. Can there be an option to > remove the extra zero's? That's how the values are displayed for C++, too. That way you can see the size of the data type, too. > Basically any leading zeros on any numerical values should be removed. I agree, an option might be good. > > Also maybe hex values could use h instead of 0x, saving an extra char. I > realize it might cause problems with copying values but it could be > optional too. Although a h suffix is also supported when entering values, 0x is the way the language expects the values to be specified, so I'd rather stick with that.
Re: Visual D not showing variables
On 30/09/2019 22:09, Brett wrote: > I have quite a few variables and some are not showing up in the locals. > If I "alias" them they show up. Also alias do not show up. The variables > I'm using that do not show up are seem outer variables. I had to create > a function to do some multiple processing and some variables became > outer and now I do not see them in local. I thought this was fixed? > Only variables actually used in a nested function are captured and can be displayed as part of the locals. You can see the captures by unchecking "hide compiler generated symbols" on the mago options page.
Re: Visual D Debugger long array expansion indexing fix
On 17/09/2019 22:04, Brett wrote: > On Tuesday, 17 September 2019 at 17:19:22 UTC, Brett wrote: >> On Tuesday, 17 September 2019 at 13:48:33 UTC, Brett wrote: >>> does things like [1000...2000] >>> >>> but then lists the values as [0], [1], ... >>> >>> Could it use the absolute values [1000], [1001], etc? >>> >>> That way one doesn't have to do mental arithmetic? >>> >>> Obviously not difficult but I see no reason to not do it. The nice thing about the current implementation is that there is no extra state but the expression to be passed around by the evaluation (a[1001] == a[1000..2000][1]), but I agree that it is a bit confusing. Maybe there is some other solution... >> >> Also, can AA arrays have their keys sorted? Lexicographical should >> work. I see no reason not to sort them, specially when the keys are >> integers, helps locate values in large arrays much easier. This can be a bit expensive for large arrays as all elements need to be read and cached before displaying the first. This is usually done incrementally by the debugger. > > And maybe add a linear index on AA's so it is easier to locate > values(and/or show length). > This would be easier, but probably not so interesting if not also sorted.
Re: Thread names in Visual Studio and Mago
On 18/09/2019 19:55, Random D user wrote: > On Wednesday, 18 September 2019 at 07:30:21 UTC, Rainer Schuetze wrote: >> >> >> On 15/09/2019 20:11, Random D user wrote: >>> I've been trying to set thread names for debugging, but it seems Mago >>> just ignores all names. >> >> SetThreadDescription works for me (in VS2019). >> >> If you are using the visualdproj project, do not use "Mago" as the >> debugger, the "Visual Studio" debugger work better and have D support >> through a mago based expression evaluator extension. > > Yes, I'm using VS2019. > Interesting. I indeed have been using Mago (pretty old project files too). > I did not know that "Mago" was the wrong debugger to use. I think it > used to be so that it was the preferred and more feature complete (i.e. > correct) debugger. It was preferred before the debugger extension existed (2017), and the latter only works for VS2012 and later (unlikely to be an issue now). I guess I should add that info to the combo box somehow. > > Thanks. > And what it's worth, I think you're doing high value work with Visual D, > much appreciated. > Thanks.
Re: Thread names in Visual Studio and Mago
On 15/09/2019 20:11, Random D user wrote: > I've been trying to set thread names for debugging, but it seems Mago > just ignores all names. > > Using WinAPI function SetThreadDescription() I can get thread name to > show up in other programs (such as the very sleepy profiler), but not in > Visual Studio and Mago debugger. I also tried the exception method as > described here: > https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019 SetThreadDescription works for me (in VS2019). If you are using the visualdproj project, do not use "Mago" as the debugger, the "Visual Studio" debugger work better and have D support through a mago based expression evaluator extension. > > > core.thread.Thread also seems broken in terms of thread name. It seems > to just set a local name for the thread, but not communicate that to the > os. I suppose threads in Windows are nameless outside of debugging, so > perhaps that was just a poor d-runtime design choice. > Anyway, Mago doesn't seem to look up the d-runtime name either. > > Is there a way to show thread names in Visual Studio Mago? or is it just > unsupported. > > Also it would be cool if the d runtime would name it's threads, so that > it would be easier and faster to pick the correct one. > Please report to https://issues.dlang.org/
Re: Visual D debugger crashes when expanding empty array
On 14/09/2019 21:40, Bert wrote: > Creating pointers to dynamic arrays, when the array length is 0 and the > ptr is 0 expanding it's elements will crash Visual Studio. That's the automatic dereferencing for pointers going wrong. Fixed for the next version.
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: Visual D 0.50.0 released
On 23/06/2019 19:58, Rainer Schuetze wrote: > Hi, > > today a new version of Visual D has been released. Its main new features are > > - additional installer available that includes DMD and LDC > > - now checks for updates for Visual D, DMD and LDC, assisted download > and install > > - debugger improvements: better support for dynamic type of classes, > show exception messages, conditional breakpoints > > - highlight references to symbol at caret (experimental) > > See https://rainers.github.io/visuald/visuald/VersionHistory.html for > the complete list of changes > > Visual D is a Visual Studio extension that adds D language support to > VS2008-2019. It is written in D, its source code can be found on github: > https://github.com/D-Programming-Language/visuald, pull requests welcome. > > The installers can be found at > http://rainers.github.io/visuald/visuald/StartPage.html > > Visual D is now also available in the Visual Studio Marketplace: > https://marketplace.visualstudio.com/items?itemName=RainerSchuetze.visuald > > Happy coding, > Rainer > I just released a bug fix version 0.50.1 with a few enhancements: - fixes some integration issues with VS 2019 16.2 - mago: improve function call in watch window - better version highlighting for files not in project Full list of changes as usual here: https://rainers.github.io/visuald/visuald/VersionHistory.html
Re: Release Candidate [was: Re: Beta 2.087.0]
On 30/06/2019 00:21, Martin Nowak wrote: > On Sunday, 16 June 2019 at 22:47:57 UTC, Martin Nowak wrote: >> Glad to announce the first beta for the 2.087.0 release, ♥ to the 66 >> contributors. > > Release Candidate is live. > >> http://dlang.org/download.html#dmd_beta >> http://dlang.org/changelog/2.087.0.html >> >> As usual please report any bugs at >> https://issues.dlang.org >> >> -Martin Thanks. It seems https://github.com/dlang/druntime/pull/2620 hasn't made it into the RC although it was merged into stable 2 days ago. I guess that coincided with preparations for the release candidate. Will it still be included in the release?
Re: Visual D 0.50.0 released
On 26/06/2019 04:35, Bart wrote: > On Tuesday, 25 June 2019 at 19:47:40 UTC, Rainer Schuetze wrote: >> >> >> On 25/06/2019 15:53, a11e99z wrote: >>> On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote: On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote: > today a new version of Visual D has been released. and now I have some issues with new VD 0.50: and now main troubles: I cant build any D project any more from VS. - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link. >>> >>> I deinstalled Build Tools, installed VC++ from VS-Installer to Community >>> folder as 99% does. >>> same problems. >>> deinstalled VD0.50, install it again, all settings restored from olds (I >>> want to do clean installation) >>> deinstalled VD0.50, installed 0.49.2, same problems and same old >>> settings. >>> pic of LDC x64 w OPTLINK https://pasteboard.co/Il3uc0E.png >>> well, now i can not compile D projects at all with any version of VD. >> >> "Image not found" for the link. >> >> I suspect that there is something wrong with the order of folders in >> the PATH environment variable. You can check the generated batch >> (*.cmd) in the output folder. > > > Maybe what might help is for VD to output all relevant information such > as the locations of the compiler, linker, library imports, etc... all in > an easily one per line file. > > I tend to have trouble parsing the logs and such because the information > is not easily readable unless one knows exactly what they are looking > for. Specially with large projects. > > This may not help with the compiler and linker itself unless you were to > monitor the file system for changes(like process monitor) and then > report what it is using but that would be a bit of work. > > On my comp LDC does not work and I just get a crash but I don't know > why. I simply don't use LDC for now. > > For example, if you could override all the file commends in VD (e.g., if > you use std.file you could hijack it) and then output all open files to > a log along with VD's __FILE__ and __LINE__ info to get the source where > they are being used at. Would also require doing it with the shell but > you basically already do it... just maybe pretty print the info so it is > more readable. E.g., > > VD Options > --- > > Paths: > Libraries: C:\Lib > Imports: C:\Imports > Compiler: C:\dmd\bin > > Import libraries: > C:\libraries\ > D:\foxtrot\tango.m > ... > Command line options: > -m64 > -g > -IC:\libraries\ > ... > ... > > Opened Files: > C:\project\happy.m > D:\projects\dance.m > > > The point is to be as verbose as possible to provide as much contextual > information for figuring out problems. > > > > or whatever... > > > If you setup the framework you could slowly convert everything over time > by simply logging stuff and as you come across old usage you can update > it. Maybe get the most relevant first and then the rest of the stuff > could follow. > > There are dll injection libraries that can be used to inject in to a > process to monitor file system access... could be used on the compiler > and linker and all the files it uses could be stored(the log file would > be very large but it would be helpful). > > You can already find all this information in the output/intermediate folder, e.g. the dep/lnkdep files are from monitoring compiler and linker, respectively. The logs are not as verbose as the ones generated by msbuild, but that makes them easier to digest.
Re: Visual D 0.50.0 released
On 25/06/2019 15:53, a11e99z wrote: > On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote: >> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote: >>> today a new version of Visual D has been released. >> >> and now I have some issues with new VD 0.50: >> and now main troubles: I cant build any D project any more from VS. >> - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link. > > I deinstalled Build Tools, installed VC++ from VS-Installer to Community > folder as 99% does. > same problems. > deinstalled VD0.50, install it again, all settings restored from olds (I > want to do clean installation) > deinstalled VD0.50, installed 0.49.2, same problems and same old settings. > pic of LDC x64 w OPTLINK https://pasteboard.co/Il3uc0E.png > well, now i can not compile D projects at all with any version of VD. "Image not found" for the link. I suspect that there is something wrong with the order of folders in the PATH environment variable. You can check the generated batch (*.cmd) in the output folder.
Re: Visual D 0.50.0 released
On 25/06/2019 15:38, a11e99z wrote: > On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote: > and should exists total uninstallation with removing ALL setting and > folders. > probably its good for updating to new version but should exist > possibility to make clean new installation with removing all old settings. > for now uninstall & new install restore all old settings. dunno where it > stores. I remove folder in program files, appdata\roaming and > some keys from registry but it doesnt helps. probably I missed something. The problem is that Visual Studio keeps the settings in a private registry that is only mounted when you run VS. This private registry is not accessible by the installer. Adding a "Reset all settings to default" sounds like a good idea, though. I'll see if it can be added in the next release. You could try running "devenv /ResetSettings" for a global reset.
Re: Visual D 0.50.0 released
On 25/06/2019 14:24, a11e99z wrote: > On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote: >> today a new version of Visual D has been released. > > before I used VS2017 with VD 0.49. was ok. then I uninstalled it both. > then installed VS2019 (.NET only), installed VD 0.50, installed Build > Tools for 2019 (C++), installed DMD & LDC as unpack distros to some > folder and added PATH to their bin dirs That's where your troubles start. > - CLI is working now. > > and now I have some issues with new VD 0.50: > - (weird but can live with it) mode "betterC" looks in settings like > "remove some runtime info and helper functions" That's the description given by dmd in the CLI help. - not clear too much coz > I thoughts that this option decrease compiled EXE size. please give to > it more clear text like "betterC" I can add betterC/worseD to the description if that helps. The VC++ integration already calls the option "Better C". > - (in concert) Visual D Settings\Updates\Base directory > for what needed that directory? for D projects? (oh, we are in tab > "Updates") then what I should point here DMD directory (that can be in > ProgramFiles if i used DMD installer)? LDC directory (that can be in any > other user dir)? or I should point just "C:\"? weird name and option. There is not a lot of space for verbose descriptions in this dialog, the installer explains it a bit less terse. But I'll try to cover it in a line above or below the option. > - Path to VS Linker exists only in DMD Directories tab for x64. What for > GDC and LDC in case I dont install DMD at all? GDC uses ld and LDC the Microsoft linker, nothing from the dmd installation. > > and now main troubles: I cant build any D project any more from VS. > - compiling as "DMD x64": OPTLINK can not build EXE coz VD gives to it > probably weird option. OPTLINK points to "/OUT:.." option and I dont > used any nonASCII chars. dunno whats wrong. DMD still can build EXE from > CLI. That's probably because link.exe cannot be found in the standard locations (Build tools not supported, as probably C++ integration doesn't do aswell). Then PATH is searched, but the dmd folder contains some badly named executables, link.exe being the worst. > - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link. > - ok. remove DMD from VS options and from PATH var. LDC tried to use > link.exe. why? it has own lld-link again. see next point. lld-link is pretty new, and is unlikely to work well enough in combination with C++. For example, Microsoft keeps adding new debug information records. > - coz I installed Build Tools(C++) separate form VS my folder to libs > and tools located at "C:\Program Files (x86)\Microsoft Visual > Studio\2019\BuildTools" not in the "..\Community". Probably its MS > problem but I have what I have. so using VCINSTALLDIR is not good option > for all cases. Try to check folder BuildTools too and VCINSTALLDIR for > lastest build tools and libs. I can point VD settings manually but VD > can do it automatically - just to check two folders instead one. Sorry, can't support all possible combinations of installations. I think it's not too bad if you can still configure the odd cases.
Re: Visual D 0.50.0 released
On 25/06/2019 08:49, Bart wrote: > On Tuesday, 25 June 2019 at 05:32:37 UTC, Rainer Schuetze wrote: >> >> >> On 24/06/2019 21:58, Bart wrote: >>> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote: Hi, today a new version of Visual D has been released. Its main new features are [...] >>> >>> >>> Did you break showing interfaces in the debug window? None of my >>> interfaces are able to be expanded as the objects they are after >>> updating. Was working fine right before. >> >> I think the bug has been in there since beta1, but doesn't always show >> up (never in a debug build). The class name is cached for a >> vtbl-pointer, but that cached value can be overwritten if there are >> uninitialized references evaluated afterwards. Fixed for the next >> release. > > Never in a debug build? I'm using debug build ;/ Before sometimes it > woudln't show up but after the update no interface was expandable(well, > at least when I noticed it I could not expand any) I was talking about the debug build of the debugger extension.
Re: Visual D 0.50.0 released
On 24/06/2019 21:58, Bart wrote: > On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote: >> Hi, >> >> today a new version of Visual D has been released. Its main new >> features are >> >> [...] > > > Did you break showing interfaces in the debug window? None of my > interfaces are able to be expanded as the objects they are after > updating. Was working fine right before. I think the bug has been in there since beta1, but doesn't always show up (never in a debug build). The class name is cached for a vtbl-pointer, but that cached value can be overwritten if there are uninitialized references evaluated afterwards. Fixed for the next release.
Re: Visual D 0.50.0 released
On 24/06/2019 00:25, Greatsam4sure wrote: >> >> Visual D works for VS 2008 up to VS 2019. The new project dialog in VS >> 2019 makes it hard to discover the new projects because the categories >> are hardcoded and cannot be extended. You have to scroll down the list >> of "All" project templates. Once used the project types appear in the >> recently used projects list. > > > Thanks, I just installed the package with DMD and LDC but my old version > of DMD was not replaced. Is there a reason for this? I now have two > versions of DMD on my laptop now-dmd 2.086 and 2.086.1 It doesn't (yet) delete old versions of the compilers because I didn't want to break existing setups. In case something fails to compile for your code with the new compiler release, you can easily go back to the previous one. The compiler update also doesn't change your environment as the DMD installer (optionally) does, so you have to set PATH yourself.
Re: Visual D 0.50.0 released
On 23/06/2019 21:06, Greatsam4sure wrote: > On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote: >> Hi, >> >> today a new version of Visual D has been released. Its main new >> features are >> >> - additional installer available that includes DMD and LDC >> >> - now checks for updates for Visual D, DMD and LDC, assisted download >> and install >> >> - debugger improvements: better support for dynamic type of classes, >> show exception messages, conditional breakpoints >> >> - highlight references to symbol at caret (experimental) >> >> See https://rainers.github.io/visuald/visuald/VersionHistory.html for >> the complete list of changes >> >> Visual D is a Visual Studio extension that adds D language support to >> VS2008-2019. It is written in D, its source code can be found on >> github: https://github.com/D-Programming-Language/visuald, pull >> requests welcome. >> >> The installers can be found at >> http://rainers.github.io/visuald/visuald/StartPage.html >> >> Visual D is now also available in the Visual Studio Marketplace: >> https://marketplace.visualstudio.com/items?itemName=RainerSchuetze.visuald >> >> >> Happy coding, >> Rainer > > > Thanks to all, who make this possible. > > Which version of dmd and ldc is bundle with visual-D 0.50 and which > version of visual studio 2019 does it support. dmd 2.086.1 and ldc 1.16.0 are bundled. These are mentioned in the filename of the download, but that isn't obvious on the front page. I guess this should be shown there, too. > The latest version studio > 2019 I have does not support previous version of visual D. I could not > create a Dlang project with it > Visual D works for VS 2008 up to VS 2019. The new project dialog in VS 2019 makes it hard to discover the new projects because the categories are hardcoded and cannot be extended. You have to scroll down the list of "All" project templates. Once used the project types appear in the recently used projects list.
Visual D 0.50.0 released
Hi, today a new version of Visual D has been released. Its main new features are - additional installer available that includes DMD and LDC - now checks for updates for Visual D, DMD and LDC, assisted download and install - debugger improvements: better support for dynamic type of classes, show exception messages, conditional breakpoints - highlight references to symbol at caret (experimental) See https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete list of changes Visual D is a Visual Studio extension that adds D language support to VS2008-2019. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. The installers can be found at http://rainers.github.io/visuald/visuald/StartPage.html Visual D is now also available in the Visual Studio Marketplace: https://marketplace.visualstudio.com/items?itemName=RainerSchuetze.visuald Happy coding, Rainer
Re: Visual D 0.49.0 released
On 22/04/2019 00:57, Alex wrote: > On Sunday, 7 April 2019 at 19:41:43 UTC, Rainer Schuetze wrote: >> Hello, >> >> the new release of Visual D has just been uploaded. Some major >> improvements of 0.49.0: >> >> * support for Visual Studio 2019 >> * parallel compilation supported by VC projects >> * catch up with recent language changes >> * new "Language" configuration page for -transition=/-preview=/-revert= >> options >> >> See http://rainers.github.io/visuald/visuald/VersionHistory.html for >> the full list of changes. >> >> Visual D is a Visual Studio extension that adds D language support to >> VS2008-2019. It is written in D, its source code can be found on >> github: https://github.com/D-Programming-Language/visuald, pull >> requests welcome. >> >> The installer can be found at >> http://rainers.github.io/visuald/visuald/StartPage.html >> >> Rainer > > Thanks, do you know of any reason to upgrade to VS 2019? Does VD make > any use of it? Unfortunately, "historical debugging" doesn't (yet) work with Visual D/mago. Other than that new workflow features should work just fine if they are not specific to some other language. The new project dialog makes it a bit difficult to discover D projects as the "Language" selector is not extensible.
Re: Visual D 0.49.0 released
On 21/04/2019 10:40, Rainer Schuetze wrote: > > > On 07/04/2019 21:41, Rainer Schuetze wrote: >> Hello, >> >> the new release of Visual D has just been uploaded. Some major >> improvements of 0.49.0: >> >> * support for Visual Studio 2019 >> * parallel compilation supported by VC projects >> * catch up with recent language changes >> * new "Language" configuration page for -transition=/-preview=/-revert= >> options >> >> See http://rainers.github.io/visuald/visuald/VersionHistory.html for the >> full list of changes. >> >> Visual D is a Visual Studio extension that adds D language support to >> VS2008-2019. It is written in D, its source code can be found on github: >> https://github.com/D-Programming-Language/visuald, pull requests welcome. >> >> The installer can be found at >> http://rainers.github.io/visuald/visuald/StartPage.html >> >> Rainer >> > > In case you are having some troubles with the semantic analysis (with > LDC or with VC2017 projects), there is a new version available now: > > https://github.com/dlang/visuald/releases/tag/v0.49.1 > And if you are still using VS 2015/2013, 0.49.1 is likely to be causing trouble, so this one's for you: https://github.com/dlang/visuald/releases/tag/v0.49.2
Re: Visual D 0.49.0 released
On 07/04/2019 21:41, Rainer Schuetze wrote: > Hello, > > the new release of Visual D has just been uploaded. Some major > improvements of 0.49.0: > > * support for Visual Studio 2019 > * parallel compilation supported by VC projects > * catch up with recent language changes > * new "Language" configuration page for -transition=/-preview=/-revert= > options > > See http://rainers.github.io/visuald/visuald/VersionHistory.html for the > full list of changes. > > Visual D is a Visual Studio extension that adds D language support to > VS2008-2019. It is written in D, its source code can be found on github: > https://github.com/D-Programming-Language/visuald, pull requests welcome. > > The installer can be found at > http://rainers.github.io/visuald/visuald/StartPage.html > > Rainer > In case you are having some troubles with the semantic analysis (with LDC or with VC2017 projects), there is a new version available now: https://github.com/dlang/visuald/releases/tag/v0.49.1
Re: Visual D 0.49.0 released
On 09/04/2019 22:34, Crayo List wrote: > On Sunday, 7 April 2019 at 19:41:43 UTC, Rainer Schuetze wrote: >> Hello, >> >> the new release of Visual D has just been uploaded. Some major >> improvements of 0.49.0: >> >> * support for Visual Studio 2019 >> * parallel compilation supported by VC projects >> * catch up with recent language changes >> * new "Language" configuration page for -transition=/-preview=/-revert= >> options >> >> See http://rainers.github.io/visuald/visuald/VersionHistory.html for >> the full list of changes. >> >> Visual D is a Visual Studio extension that adds D language support to >> VS2008-2019. It is written in D, its source code can be found on >> github: https://github.com/D-Programming-Language/visuald, pull >> requests welcome. >> >> The installer can be found at >> http://rainers.github.io/visuald/visuald/StartPage.html >> >> Rainer > > Is there a way to donate to this project? Thanks for considering a donation, but there is nothing setup to do so. > Or maybe buy you a beer or a six-pack? Maybe at DConf, though I'm not yet sure I can make it.
Visual D 0.49.0 released
Hello, the new release of Visual D has just been uploaded. Some major improvements of 0.49.0: * support for Visual Studio 2019 * parallel compilation supported by VC projects * catch up with recent language changes * new "Language" configuration page for -transition=/-preview=/-revert= options See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full list of changes. Visual D is a Visual Studio extension that adds D language support to VS2008-2019. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. The installer can be found at http://rainers.github.io/visuald/visuald/StartPage.html Rainer
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: Beta 2.085.0
On 16/02/2019 22:03, Per Nordlöw wrote: > On Saturday, 16 February 2019 at 15:06:51 UTC, Martin Nowak wrote: >> Glad to announce the first beta for the 2.085.0 release, ♥ to the 49 >> contributors. >> >> http://dlang.org/download.html#dmd_beta >> http://dlang.org/changelog/2.085.0.html > > I can't find any mentioning of Rainer Schützes work on memory reductions > of the GC for non-power-of-two sizes. Was it reverted? It is listed as "Bugzilla 19455: GC wastes too much memory". What's not found in the changelog is an optimization sweeping large allocations that is inspired by your report https://forum.dlang.org/thread/zrouxhbkssrncyinh...@forum.dlang.org: https://github.com/dlang/druntime/pull/2430
Re: Beta 2.085.0
On 16/02/2019 19:53, JN wrote: > On Saturday, 16 February 2019 at 15:06:51 UTC, Martin Nowak wrote: >> Glad to announce the first beta for the 2.085.0 release, ♥ to the 49 >> contributors. >> >> http://dlang.org/download.html#dmd_beta >> http://dlang.org/changelog/2.085.0.html >> >> As usual please report any bugs at >> https://issues.dlang.org >> >> -Martin > > What is the precise scanning GC? I only see how to enable it, but don't > really see why would I want to enable it. It's purpose is to avoid not collecting memory due to false pointers. Here are some related bug reports: https://issues.dlang.org/show_bug.cgi?id=3463 https://issues.dlang.org/show_bug.cgi?id=4358 https://issues.dlang.org/show_bug.cgi?id=9094 https://issues.dlang.org/show_bug.cgi?id=13801 https://issues.dlang.org/show_bug.cgi?id=18900 Precise heap and data segment scanning isn't the complete solution, though, The stack and registers might still contain false pointers.
Re: Beta 2.084.1
On 05/02/2019 11:53, Andre Pany wrote: > On Tuesday, 5 February 2019 at 04:18:55 UTC, Martin Nowak wrote: >> Glad to announce the first beta for the 2.084.1 point release, ♥ to >> the 6 contributors. >> >> http://dlang.org/download.html#dmd_beta >> http://dlang.org/changelog/2.084.1.html >> >> As usual please report any bugs at >> https://issues.dlang.org >> >> -Martin > > This beta again has this issue: > lld-link.exe: error: could not open msvcrt100.lib: no such file or > directory > lld-link.exe: error: could not open OLDNAMES.lib: no such file or directory > > (It is caused if you have a visual studio / build tools installation, then > lld gets confused). > > It was already solved in the nightly build, I downloaded some days ago. > > Kind regards > André I think this happens because the Windows SDK is detected, but VC is not. As the replacement import libraries for both are in the dmd\windows\lib64\mingw folder, adding it to the library search path would be causing some bad mixture of libraries. VC is probably no longer detected because recent versions of the VS installations do not write an expected registry key, but assume the COM API to be used for detection (as added by https://github.com/dlang/dmd/pull/9243). So pedantically, this is not a regression in dmd, but a changed environment. You should still be able to link when running the vcvarsall.bat to setup the VS/VC environment variables.
Re: Which debugger can explain InvalidMemoryOperationError?
On 17/01/2019 23:12, Victor Porton wrote: > On Thursday, 17 January 2019 at 16:37:55 UTC, Victor Porton wrote: >> After main() of my program finishes, I have this error message: >> >> core.exception.InvalidMemoryOperationError@core/exception.d(700): >> Invalid memory operation >> >> Which debugger (preferably with a GUI interface) do you suggest to >> investigate this error? >> >> I tried DDD and KDbg. >> >> In DDD when I set `catch throw InvalidMemoryOperationError` or `catch >> throw core.exception.InvalidMemoryOperationError`, the exception is >> not called nevertheless. >> >> In KDbg, I don't see any way to set an exception breakpoint, at all. >> >> I use LDC2. > > I've tried it with plain GDB 8.2. > > The following does not work: > > catch throw InvalidMemoryOperationError > catch throw core.exception.InvalidMemoryOperationError > > Despite of the above commands, the exception is not caught and so I am > unable to see the callstack which has led to the exception. > > Please help me to find a way to see the callstack in order to be able to > debug my software! You might want to set a breakpoint on function onInvalidMemoryOperationError. Probably this is the function that is throwing the error. Debugging experience will likely improve if you build the runtime library with debug information. (see https://wiki.dlang.org/Building_under_Posix).
