- Had to fix a couple of really bad issues – there were massive leaks and infinite loops occurring when unfinished code like
if(...) {was parsed - Implemented semantics of the with() statement
- Fixed further concurrency bugs
- Error messages are suppressed now when include directories could not be found.
Anyway, thanks for your constructive feedback!
Loading ...
4 Comments
Another issue that I found with Mono-D.
If you have two projects in a solution, 1 solution is the console app and other is a D library. Now if in the library project (project name firstlibd) we have following two files:
1. myclass.d
2. parameter.d
so if I declare the module name in both files as
module firstlibd.myclass;
&
module firstlibd.parameter;
respectively then the intellisense won’t work in “myclass.d” if it imports:
import firstlibd.parameter;
if I access any enum value from parameter.d then code will compile without any issue but IDE won’t show the intellisense.
I tried this module naming convention to solve the following issue:
“I have two “library” project with something similar to following:
AppFolder (AppFolder is solution folder and contains the below two folders for
individual project)
Lib1
|
—— TestFile1.d
|
—— TestFile2.d (import TestFile1;) // TestFile2 is importing
TestFile1 in same library project.
Lib2 (Lib2 has linker path to “lib1.a” and include path to
“AppFolder”)
|
—— TestFile3.d (import Lib1.TestFile2).
If I compile the Lib1 folder alone then it will work fine but now
if I compile the Lib2 folder then the error will be in
“TestFile2.d” of Lib1 project that “TestFile1″ is not found. If I
change the “Import” in TestFile2 to
import Lib1.TestFile1;
Then the compilation of Lib2 starts to work. Now, if I try to
compile the Lib1 project alone in Mono-D (I also tried same on
D-IDE) then it will not compile.
I was ok with compiling only the Lib2 but now the next issue is
that the code completion won’t work in “Lib1.TestFile2″ after
changing the import statement (simply because Lib1.TestFile1 is
not valid path for it any more).
“
There’s (at least) one ‘trick’ to handle this:
Create a subdirectory inside the lib project called “firstlibd” so you’ll be able to name all modules like firstlibd.module1 – and everything wil be fine, even in the executable project.
One problem could be now that it’s not updating the include paths all the time – and I also better add dedicated project includes or something like that to handle such (typical) situations… I never really thought that this could be a problem or something.. but now it seems that it actually is.. let me try to handle this
I think there is another bug that crashes the Mono-D on Linux. The steps are:
“If you create a function that uses a Class as parameter (or some wrong Enum name) then the IDE crashes with memory overflow or something. My assumption is that it tries to keep looking for that symbol and gets stuck in some recursive loop or something.”
Thx, I guess I got to play around with it for a while to figure out what obstruct kinds of syntaxes crashes it