abothe / mono-d Goto Github PK

When opening a brace that is not in the 1st column, it is snapped to the first indentation level. When closing a brace, it is snapped down to the zeroth indentation column. Code written inbetween is unaffected.

eg:

void main(string[] args)
{
    if(true)
    { 
        writeln("Hello, World!");
        for(int i=0; i<5;i++)
    {  
            i = i % 4;
            if(i == 3)
    {   
            i++;
}
}
}
}

MonoDevelop version: 2.8.5
Mono-D version: 0.2.4

When I make a new project, then type:

module main;

auto game = new Awesome.SpaceshipGame(Type.Shooter);

void main()
{
    game.play();
}

I get unexpected results (no game is built for me), and I get syntax errors all over the place.
This is a major productivity issue, please fix immediately!

There is currently no way to configure code formatting. The default formatting does not fit very well with the formatting rules used by most D projects (in particular, Phobos indents with 4 spaces, not 8).

It would be a good idea to highlight the currently valid identifiers that can be passed to __traits, as specified in: http://www.d-p-l.org/traits.html

This helps avoid typos/mistakes.

The parser can't handle code such as:

public interface Iterable(T)
{
    public int opApply(scope int delegate(ref T) dg)
    in
    {
        assert(dg);
    }
}

It will complain on line 7, saying it expects a {.

Example:

@safe UUID md5UUID(const(char[]) name, UUID namespace = nilUUID)
{
}

/**
 * ditto
 */
@trusted UUID md5UUID(const(ubyte[]) data, UUID namespace = nilUUID)
{
}

void test
{
    md5 /* --> md5UUID shows up twice*/
}

Well I can imagine this is quite big and not possible to implement over night but there wasn't any issues already up for it so thought it would be worth putting here to remind you ;)

You do have Debugging in D-IDE so I imagine it is possible so would just like it to be made available on Mono-D as well.

Maybe you already have it and I just missed how to get it working(since it's blocked out for me in the menu and pressing F5 does nothing).

Keep up the good work!

struct Vector(uint S, T) if (S > 1)
{
    T[S] data;

    private @property
    {
        auto _get(uint U)() { return data[U]; }
        void _set(uint U)(T value) { data[U] = value; }
    }

    alias _get!0 x;
    alias _set!0 x;

    alias _get!1 y;
    alias _set!1 y;
}


void main()
{
    auto vv = Vector!(2, float)();

    vv.x = 32; // 'x' shows up twice in code-completion list
    writeln(vv.y); // ditto for 'y'
}

It's a minor bug, and the example above isn't a realistic use-case-scenario, but gl3n makes use of "double aliases" for GLSL style vector property access (eg, vec1.xyz += vec2.yzz;) and I'm using them in some areas as well.

This is perhaps not the right forum, but I guess others might be interested too...

I see you are creating both Mono-D and D-IDE, and it also seems both are maintained. How does these projects relate to each other, and what are your plans for these projects? If someone were to contribute, how would you prefer this to be done? By working on D-IDE or Mono-D (I haven't tried D-IDE, and I've just installed Mono-D, but Mono-D seems really great!)

The latest version seems to have broken function completion.

void test()
{
}

void foo()
{
t // does not complete 'test'
}

It would be nice to have code completion of the three supported scope statement identifiers, exit/success/failure. I.e. when I type scope (, I want to be presented with those three. Also, highlighting them will help prevent typos/mistakes.

I wanted to use a variable to define the max size of an array and create it later by "new" statement. But it didn't work!
Codes:
int MaxLength = 50;
char[MaxLength][] chAll = new char[MaxLength][MaxLength];

Error: variable MaxLength cannot be read at compile time (CodingRaster)

Now, I have to do as: char[50][] chAll = new char[50][50];

The parser is missing support for some special tokens listed at: http://www.d-p-l.org/lex.html

Specifically:

• DATE
• TIME
• VENDOR
• VERSION
• TIMESTAMP

Same as with traits and scope. Currently supported linkages by various compilers includes: C, C++, D, Windows, System, Pascal, Java

With MonoDevelop on LinuxMint 12

On creating a new project (shared library), the compilation output is "Object reference not set to an instance of an object" until the IDE is restarted. Compilation then process normally.

When linking a shared library with dmd, mono-d create the following command line from "-gc -debug -of"$target" $objs $libs -L/IMPLIB:$relativeTargetDir "

dmd -gc -debug -of"/home/XXX/Projects/PROJECT/bin/Debug/PROJECT.so" "/home/XXX/Projects/PROJECT/obj/Debug/myclass.o" -L/IMPLIB:
/usr/bin/ld: cannot find /IMPLIB:: No such file or directory

$relativeTargetDir is not correctly replaced

Minor issue: The foreach_reverse code completion examples show the foreach keyword, instead of foreach_reverse.

When accessing properties of a value returned by a function statement, or after indexing a sequence, no completion is given

eg:

Factory.CreateObject().Foo();
VectorList[i].X;

In neither of those cases would there be completion.

It would be nice if Mono-D could include/exclude files in projects based on patterns. This makes it easier to use Mono-D alongside other build systems, as you don't have to add new files to the Mono-D project file when you're editing outside Mono-D.

I suggest highlighting the list of standardized version identifiers at: http://www.d-p-l.org/version.html

This helps people avoid typos/mistakes.

I'm not sure if this is possible with monodevelop at all, but it'd be cool to have systax highlighting for examples in tooltips.

It would also be nice to print section headers in the tooltips in bold or underlined. (and 'Bugs:', 'Deprecated:' probably in red, 'Throws:' could probably get a special color as well. I'm not sure about 'Todo:', it seems useful but it's not a standard ddoc header)

Attributes such as @Property seemingly get no color.

I'm not entirely sure this is an issue with Mono-D or Arch's DMD install. Building fails on ArchLinux due to "phobos.a" not being found. ArchLinux's DMD Phobos include directory is slightly different than the DMD Fedora rpm (Arch: "/usr/include/d", Fedora:"/usr/include/d/phobos"). I believe "libphobos.a" is stored in the same location on both (/usr/lib/libphobos2.a) so I'm not entirely sure why Mono-D is looking for "phobos.a" in the first place (I don't have Fedora installed on hand right now, but I'll verify this later).

Any idea what's going on?

Every few seconds an unhandled exception pops up:

System.NullReferenceException: Object reference not set to an instance of an object.

   at MonoDevelop.D.Refactoring.DReferenceFinder.ScanNodeReferencesInModule(IAbstractSyntaxTree scannedFileAST, IEnumerable`1 parseCache, IEnumerable`1 scannedFileImports, INode[] declarationsToCompareWith)

   at MonoDevelop.D.Gui.HighlightUsagesExtension.UpdateMarkers()

   at GLib.Timeout.TimeoutProxy.Handler()

The module imports another module that uses public imports for a bunch of libraries.

Hi! Just noticed, I have two different source files located in different packages but when compiled they are both compiled with the same filename for the object file which gives a conflict as one of them will be erased. Could you just not add a something like: ("packageNames" + "moduleName").obj to ensure that the object files are always unique?

The package names could of course be generated from the file hierarchy. Hope this is not impossible to solve ^^

To solve it right now for me I renamed one of the files to something else but keep the module name the same so usage is still the same but import changed. So there isn't a hurry to fix this.

I hope this isn't too difficult to fix ^^ It looks trivial from my point of view.

With this example code:

public struct UUID
{
    public:
        /**
         * These are the UUID formats supported by this module. It's
         * possible to read, compare and use all these Variants, but
         * UUIDs generated by this module will always be in rfc4122 format.
         */
        enum Variant
        {
            ncs, /// NCS backward compatibility
            rfc4122, /// defined in RFC 4122 document
            microsoft, /// Microsoft Corporation backward compatibility
            future ///reserved for future use
        }
}

Variant doesn't show up in the code completion popup if you type "UUID.", but it does show up if you type "UUID instance; instance.". It should behave exactly the opposite way. If Variant is written like this though "static enum Variant", it works correctly. This might make sense for nested classes(I'm not sure about structs, do nested structs have a reference to their parent class/struct?), but I think enums are always static.

BTW: Mono-D is really awesome. If only more distributions had recent monodevelop packages (I'm using debian testing and had to install all mono packages from unstable. Not nice, but everything works fine)

BTW2: The bug tracker could use some labels (enhancement, crash, featureRequest, bug, ...)

Hello again! Found another bug. The parser in the editor tells me that a specific line is invalid while the compiler itself allows it. The code is:

public struct Matrix( uint Dimension, Type ) if( Dimension >= 3 && Dimension <= 4 )
{
public:
    // ... code ...
private:
    Type elements[ Dimension * Dimension ]; // <- Fails in editor but compiler allows it
}

The error I get is: Parser Error: ] expected, < Identifier > found!

The version statement doesn't seem to get any color in syntax highlighting when using the IrBlack scheme.

.. It won't compile as it's an unknown linker flag

I know how much you love fixing number syntax highlighting ;-)

[EDIT]
auto v2 = new float[2]; // v2' and '[2' are colored like numbers
auto v23 = new float[23]; // 'v23' is colored correctly
auto vec = Vector2(0, 0); // '(0' is colored like a number

Note that when importing modules, no color syntax is applied to the import statements - except for in the case of std.string,
I think this is a small bug?

for example:

import std.file;
import std.string; // <-- this import is colored blue.
import core.thread;

For functions with excessive documentation tooltips can be too big.

Example:

/**
 * This function generates a name based (Version 3) uuid from a namespace UUID and a name.
 * If no namespace UUID was passed, the nilUUID is used.
 *
 * Note:
 * The default namespaces (dnsNamespace, ...) defined by
 * this module should be used when appropriate.
 *
 * RFC 4122 recommends to use Version 5 UUIDs instead of Version 3
 * UUIDs for new applications.
 *
 * CTFE:
 * CTFE is currently not supported as std.md5 doesn't work in CTFE.
 *
 * Examples:
 * ---------------------------------------
 * //Use default nilUUID namespace
 * auto simpleID = md5UUID("test.uuid.any.string");
 *
 * //use a name-based id as namespace
 * auto namespace = md5UUID("my.app");
 * auto id = md5UUID("some-description", namespace);
 * ---------------------------------------
 *
 * Note:
 * RFC 4122 isn't very clear on how UUIDs should be generated from names.
 * It is possible that different implementations return different UUIDs
 * for the same input, so be warned. The implementation for UTF8 strings
 * and byte arrays used by std.uuid is compatible with boost's implementation.
 * std.uuid guarantees that the same input to this function will generate
 * the same output at any time, on any system (this especially means endianness
 * doesn't matter).
 *
 * Note:
 * This function does not provide overloads for wstring and dstring, as
 * there's no clear answer on how that should be implemented. It could be
 * argued, that string, wstring and dstring input should have the same output,
 * but that wouldn't be compatible with boost, which generates different output
 * for strings and wstrings. It's always possible to pass wstrings and dstrings
 * by using the ubyte[] function overload (but be aware of endianness issues!).
 *
 * BUGS: Could be pure, but this depends on the MD5 hash code.
 */
@safe void md5UUID(const(char[]) name)
{}

screenshot:

When changing the program under Static Lib Linker for any compiler, the program used remains the same.

When implementing Ldc2 :with the following code,

public class Ldc2 :CompilerDefaultArgumentProvider
{
    public Ldc2(DCompilerConfiguration cfg):base(cfg){}

    public override void ResetCompilerConfiguration ()
    {
        Configuration.Vendor = DCompilerVendor.LDC2;
        Configuration.DefaultLibraries.Clear ();

        var ldc2 = "ldc2";

        if (OS.IsWindows)
            ldc2 += ".exe";

        Configuration.SetAllCompilerCommands (ldc2);
        Configuration.SetAllLinkerCommands (ldc2);

        Configuration.GetTargetConfiguration (DCompileTarget.SharedLibrary).Compiler = ldc2;

        Configuration.DefaultLibraries.Clear ();
        if (OS.IsWindows)
            Configuration.DefaultLibraries.Add ("phobos" + DCompiler.StaticLibraryExtension);
    }

    public override void ResetBuildArguments (DCompileTarget LinkTarget, bool IsDebug)
    {
        var args = Configuration.GetTargetConfiguration (LinkTarget).GetArguments (IsDebug);
        var debugAppendix = IsDebug ? "-g" : "-O3 -release";

        args.CompilerArguments = "-c \"$src\" -of=\"$obj\" $includes " + debugAppendix;
        args.LinkerArguments = "-of=\"$target\" " + debugAppendix + " $objs $libs";

        switch (LinkTarget) {
        case DCompileTarget.ConsolelessExecutable:
            if (Environment.OSVersion.Platform == PlatformID.MacOSX) {
            } else if (Environment.OSVersion.Platform == PlatformID.Unix) {
            } else
                args.LinkerArguments += " -L/su:windows -L/exet:nt";
            break;

        case DCompileTarget.SharedLibrary:
            args.CompilerArguments = "-relocation-model=pic " + args.CompilerArguments; 
            args.LinkerArguments += " -shared";
            break;

        case DCompileTarget.StaticLibrary:
            args.LinkerArguments += " -lib";
            break;
        }
    }
}

The command line for shared lib compilation (not linkage) doesn't include ldc2

I'm running this on Windows 7 X64 with administrator access.

I open the Debug/Release Build Argument dialogs, clicking Cancel or Ok does
not close the dialog as expected - then if i try to open it again I just get a blank dialog.

struct Vector2(T)
{
    T x, y;
    @property static auto Zero() { return Vector2(0, 0); }
}

void main()
{
    auto v1 = Vector2!float(0, 0);
    auto v2 = Vector2!float.Zero; // 'Zero' does not show up in code-completion list

    v1.x = 1; // 'x' does show up
    v2.x = 1; // 'x' does  not show up
}

@Property makes not difference.
Every once in awhile 'Zero' will show up in the code-completion, but I'm not sure what causes this to happen.

Common types such as size_t, sizediff_t, Object, AssociativeArray, etc should probably be highlighted as core types.

Autocompletion doesn't recognize a declaration, and tries to complete the name being typed. Nor does it limit the options to the members of an object while using dot syntax.

eg.

// Issue 1
auto a = 1;
// Issue 2
this.X = 5;

I've imported the entire SDL enums/constants, so in the first issue, it'd try to complete "a" as SDLKey_a. Similar things happen in class and function declarations too

. In the second issue it tries to give me this.SDLKey_x instead of just letting me type.

Stack trace:

System.ArgumentNullException: Argument cannot be null.
Parameter name: path1
at System.IO.Path.Combine (System.String path1, System.String path2) [0x00000] in :0
at MonoDevelop.Core.FilePath.Combine (System.String[] paths) [0x00000] in :0
at MonoDevelop.Projects.ProjectCreateInformation.get_BinPath () [0x00000] in :0
at MonoDevelop.D.DProject..ctor (MonoDevelop.Projects.ProjectCreateInformation info, System.Xml.XmlElement projectOptions) [0x00000] in :0
at MonoDevelop.D.DProjectBinding.CreateProject (MonoDevelop.Projects.ProjectCreateInformation info, System.Xml.XmlElement projectOptions) [0x00000] in :0
at MonoDevelop.Projects.ProjectService.CreateProject (System.String type, MonoDevelop.Projects.ProjectCreateInformation info, System.Xml.XmlElement projectOptions) [0x00000] in :0
at MonoDevelop.Ide.Templates.ProjectDescriptor.CreateItem (MonoDevelop.Projects.ProjectCreateInformation projectCreateInformation, System.String defaultLanguage) [0x00000] in :0
at MonoDevelop.Ide.Templates.ProjectTemplate.HasItemFeatures (MonoDevelop.Projects.SolutionFolder parentFolder, MonoDevelop.Projects.ProjectCreateInformation cinfo) [0x00000] in :0
at MonoDevelop.Ide.Projects.NewProjectDialog.SelectedIndexChange (System.Object sender, System.EventArgs e) [0x00000] in :0

In MonoDevelop under D -> Compilers -> DMD -> Compiler, GUI app Linker, etc
it has "dmd" which is ok for Linux, but it should be "dmd.exe" for windows.

Also the exstension ".exe" for GDC, LDC for Windows will probably also need adding - not tested.

__ctfe should be highlighted as a keyword.

When copying and pasting (regardless of ctrl+c/ctrl+v or through interface) - whole document is copied and pasted. Moreover, if one copies something from another application - it is still the same. Paste has the following pattern:

1. part of current source document BEFORE the place of pasting
2. copied content (either from the current source document itself or another application)
3. part of current source document AFTER the place of pasting

Therefore, we end up with the following document structure:
1
1
2
3
3

Please, consider investigating this issue with priority, because (1) I'm sure it pretty easy to fix, (2) is extremely annoying - almost ruins development ;)

Windows 7 / MonoDevelop 2.8.5.1

Often if I'm testing stuff, that's all I'll use for notification. Having to drop to the terminal for that is less than ideal.

typedef /*struct LLVMOpaqueGenericValue*/ void* LLVMGenericValueRef;

The above is folded away so you can't see the typedef without expanding.

Don't know if this is something you can fix, or a flaw with MonoDevelop. Just thought I'd put it out there in case of the former.

enum nice = 10000; // number colored correctly
enum ugly = 10_000; // everything from the underscore is colored like regular text.

ps. It looks like a lot of the previous bugs i've run into have disappeared already. I'll keep looking though

Example:

struct UUID
{
    enum Version
    {
        blah,
        blub
    }

    Version uuidVersion;
}
void main()
{
    UUID test;
    if(test.uuidVersion == /*Code Completion should suggest UUID.Version*/
    if(test == /*Code Completion should suggest UUID*/
}

I'm not sure about the second suggestion, but in D it's common to check against .init if(blah == Type.init) and often static members are used for special values if(blah == Type.specialStaticType)

Or only show up if the default compiler is GDC or LDC, I guess. Point is, DMD doesn't do shared on Linux.

At the top of the class is a static immutable string with escaped single and double quotes in it. In the remainder of the file, everything other than keywords and number literals are highlighted as strings.