I have installed all Dsharp Packages in Delphi XE. But when I run the example, I always get the following error message:
Exception: Patching : ObjAuto.GetTypeSize failed. Do you have set a breakpoint in the method?
Has anybody found a workaround for this error?
The library is trying to apply a runtime code patch to fix a defect in the ObjAuto.GetTypeSize RTL function. The code that does this can be seen here: https://bitbucket.org/sglienke/dsharp/src/ad7c5983505f0117f1347f92d2bb96c07bdfda94/Source/Core/ObjAutoPatch.pas?at=master&fileviewer=file-view-default
The call to FindMethodBytes fails. Because this function is about to modify the executing code to install the runtime patch, it first checks that the code is as it expects it to be. It searches through the code looking for a known signature for that function.
That signature cannot be found and the patch therefore cannot be installed. Hence the error message. Some possible reasons for the patch code failing in this way:
A breakpoint is set in this code. Breakpoints are implemented by temporarily modifying the code to contain breakpoint instructions.
You are compiling and linking against your own modified version of the RTL. Because of this, the function signature is different.
Another unit in your program is also patching this same function, and the second attempt to patch fails for obvious reasons.
You are using debug DCUs that have a different signature from the standard DCUs.
There is a defect in the DSharp code. Perhaps an erroneous signature, that was not tested on your version of the Delphi RTL. That's not very likely. Perhaps you have installed a hotfix or Delphi update that has not been tested by Stefan. Or perhaps you have not installed a hotfix or update that you are expected to have installed. Maybe the linker has stripped so much code (or so little) that the signature search fails.
And the issue could be due to some other reason that I've not yet thought of. Fundamentally, though, these are all variants on the same theme. The code encountered at runtime is not as expected. I do recommend that you try to find out why so that you can determine how best to proceed.
Given that there are so many possible causes for this message, I've simply tried to explain the conceptual reason for it, but now it's really over to you to debug the specifics in your environment.
Related
I am trying to use the Dafny-to-Python compiler that is suggested in Dafny's reference (25.7.7): http://dafny.org/dafny/DafnyRef/DafnyRef.html#2577-python
However, I cannot run the first step for it in the terminal: dafny build --target:py A.dfy, since I get the error: Dafny: Error: unknown switch: --target. I use Use /help for available options as they suggest, but have no idea on how to solve.
Just in case, I also attempted using the old version of the command (see 25.8.11. in the same reference): dafny Hello.dfy -compileTarget:py but then got message Dafny: Error: Invalid argument "py" to option compileTarget.
Any idea? Note that the authors themselves clearly state that The Dafny-to-Python compiler is still under development.
PS: I usually use Dafny in Visual Studio and not in the terminal, so maybe I lack some kind of library or something.
Neither the new CLI nor the Python compiler are supported by the very outdated version of Dafny you are using. You are presumably not using the correct VS Code extension, so I would start there. As of today, this should install 3.10.0 at /Users/$USER/.vscode/extensions/dafny-lang.ide-vscode-3.0.3/out/resources/3.10.0/github/dafny/Dafny.dll. To see how to use the dll, try hitting F5 with a Dafny file opened in VS Code. The Python compiler is complete and passes all tests these days.
I have a DPK project which sometimes shows errors ("out of memory") while compiling (into Delphi IDE), and sometime it compiles with success.
But, when I try compile it through the MSBUILD, it always throws this error message:
error F2084: Internal Error: AV004A784A-WFFFD3764-1
Someone have an idea to solve it?
An internal error like that is a compiler error. We cannot solve them, only the compiler developer can do so. You need to submit a bug report to Embarcadero. Given the antiquity of XE3 you are unlikely to ever receive a fix.
Modern versions of Delphi are less prone to out of memory failures so if upgrading is an option then doing so will likely side-step the problem.
If upgrading is not an option then you are probably going to have to keep muddling along and cursing every time you encounter one of these errors.
This is actual very common (at least i experienced these kind of errors very often). I did go with the approach to remove source code files step by step from the DPK until compiling works. This way you also see which file is causing these errors, then go ahead and outcomment source code parts in this file step by step until you find the offending line, then rewrite it (in what way you need to find out yourself).
As David Heffernan already said, there is no way you can really solve it, because the error is internal to the compiler or linker, and only the developers of these can remove that bug.
But often, there are some workarounds.
In my experience, such internal errors are often related to generics and anonymous methods, or to inlined code, especially if two or all of these are combined.
So find out what code change you made before the internal error occurred. If you use a versioning system, or Delphi's internal _history system, restore to a previous version until the error goes away. Then you can do a difference with your "offending" code and see which code caused the internal error.
Often, too complex expressions (especially for the types I mentioned above) cause internal errors. If that is the case, try to simplify the expressions by calculating subexpressions first. Also, instead of using ad-hoc generic declarations like
x := TList<SomeType<Integer>>.Create;
you should try to use pre-defined types:
type
SomeTypeInteger = SomeType<Integer>;
SometypeList = TList<SomeTypeInteger>;
...
x := SometypeList.Create;
In other words,
try to find the "offending" code by going back in your history until it goes away
once you have found it, try to simplify that piece of code. Disentangle expressions and predefine types
experiment with different ways to express the code until the error goes away
If you do that, you may be successful in avoiding the internal error. It has often taken me some time, but I have always found a way to achieve what I wanted. If you couldn't, ask about specific errors here (by posting the offending code, the exact error and if possible a Minimal, Complete, and Verifiable example).
Fortunately, these errors have become very rare in the newest compilers.
I build my project, and there are no errors:
That's because the build succeeded without any errors:
This is a good thing. The application runs and everything!
Except there are errors
What the compiler doesn't tell me is that there are errors:
I just happened to have this file open. And i just happened to have the Structure viewer open. And i just happened to see the errors.
Is there a way for Delphi to report all error it encounters during a build?
Is optimization on?
No
It's no big deal for a simple one-form test application, with one error. But when i have 200 forms, XE6 starts to look as bad a Visual Studio 2012. I then have to be sure to manually open every code file and check if there are any errors in it.
Is there a way to get XE6 to report all errors?
#xe6usability
The compiler is correct. Your code does not contain an error. You have two functions with the same name, but declared with the overload directive.
The IDE's Code Insight, or Error Insight, or whatever the feature is called, is mis-reporting this as an error. This is an age old phenomenon. The IDE uses a different code parser from the real compiler. Indeed, if I recall correctly, it uses multiple such fake parsers. They are not as good as the real one, and not infrequently get things like this wrong. It's considered to be a minor inconvenience and that's probably reasonable. I'd much rather the real compiler got it right than the other way around.
Short answer: Turn off ErrorInsight, it doesn't work.
Click Tools, Options, Find Editor Options item in the list, expand it, find Code Insight, click it. Then unclick Error insight.
We use Embarcadero Delphi 2010 and recently a change was made to one of the units of a medium-sized project, causing code completion to stop working completely -- but only inside this project, it still works fine in other projects. Puzzled, I searched the interwebs for clues on what exactly could make this happen, but my search wasn't too successful.
From what I gathered, it looks like IDE has a few parsers/compilers that work completely separated from one another, which makes it entirely possible that the faster code-completion compiler could fail where the main compiler would not. Which is exactly what's happening to my project.
My question: Is there a way to find out WHERE exactly the Code Insight/Code Completion compiler is failing? Does the IDE keep a log of on-the-fly parsing/compilations anywhere?
Is there a way to find out WHERE exactly the Code Insight/Code Completion compiler is failing?
Not readily, not without debugging the IDE.
Does the IDE keep a log of on-the-fly parsing/compilations anywhere?
No.
I suggest that you install Andy Hausladen's IDEFixPack. If that does not help then use your revision control to isolate the code change that causes the problem. And find a different way to write that code that happens not to bork code completion. Trial and error is likely to be the most productive method here, much as I hate to say that.
I recently had the same problem using Delphi 10.2. After a lot of research I found that I had inadvertently declared a variable in a type section with an end; following on the next line. Removing the errors restored the code completion function. So I would recommend combing the interface for an error or restoring a backup from the directory history.
I'm interested in playing around with the MaxSAT/MaxSMT c example (specifically, maxsat.c) provided on the z3 (Microsoft Research) website. Using Visual Studio 2010, I eventually got the example to compile (using a fresh install of z3 4.0). However, I can't get any of my (SMT 2.0) models to run using them. Further, I cannot get the example posted in this question to work either.
In the first case, my compiled program crashes when it tries to call Z3_get_smtlib_num_formulas in get_hard_constraints of the file. I don't know why, instead, I get the standard windows 7 "this program has stopped working" popup.
In the second case, it reports unsupported ;benchmark.
In order to help me to get this work, I was wondering if
(a) Has anyone had similar issues when compiling this code, and if so, how did you resolve them?
or
(b) How can I debug either compilation of the file (assuming it is correct)? Namely, can someone enumerate the correct libraries (and library versions - e.g., z3 4.0?) to include in the compiler options to get this example working?
In either case, information on the error reported in the second case would also be appreciated: what does it mean exactly? The keyword was not valid? That the SMT input is the wrong version? Or something else?
Thanks.
The MaxSAT example has not been updated to SMTLIB 2.0 yet. It uses the function Z3_parse_smtlib_file to parse the input, which means that it supports only SMTLIB 1.0 at the moment.
This example is distributed alongside Z3, i.e., you should have received a copy in Z3-4.0/examples/maxsat/, which also contains compilation and execution scripts.
Compilation should be straight-forward by running build.cmd in a Visual Studio Command Prompt, or build.sh on Linux.