On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
> 2. I got an error that I don't get with dmd:
>
> Error: incompatible types for ((ScreenPainter) !is (null)): cannot use '!is' with types		
>
> and I have defined ScreenPainter in my code. It is also in arsd's simpledisplay. I do not import simpledisplay directly:

It's probably the difference of the recent import rules bug fix. gamehelpers public imports simpledisplay, so its ScreenPainter will be visible there too.

You can probably just exclude it from the import by doing selective:

import arsd.gamehelpers : create2dWindow;

and comma list anything else you use from there (probably just OpenGlTexture, it is a small module).


But yeah, weird that it is different, but this was REALLY recently changed so if the release differs by just one month in version it could account for the difference.

> Although, If I set the subsystem to windows I then get the error

There's another MSFT library needed there passing `-L/entry:mainCRTStartup` to the build should do it.

dmd 32 bit has its own library so it isn't needed there, but dmd 64 bit and ldc both I believe need the entry point.

On Sunday, 12 June 2016 at 05:08:12 UTC, Mike Parker wrote:
> On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
>
>>
>> 1. I had an older distro(I think) of ldc. The ldc2.exe is 18MB while the "new" one is 36MB. I copied the old ldc bin dir to the new one and didn't change anything and everything compiled EXCEPT
>
> That's just asking for problems. You may get lucky and find that it works, but in general you don't want to go around swapping compiler executables like that.
>
>
>>
>> 2. I got an error that I don't get with dmd:
>>
>> Error: incompatible types for ((ScreenPainter) !is (null)): cannot use '!is' with types		
>>
>> and I have defined ScreenPainter in my code. It is also in arsd's simpledisplay. I do not import simpledisplay directly:
>>
>> The code is
>>
>> 	import arsd.gamehelpers;
>> 	auto window = create2dWindow(cast(int)width, cast(int)height, cast(int)ViewportWidth, cast(int)ViewportHeight, title);
>>
>> 	// Let the gui handle painting the screen
>> 	window.redrawOpenGlScene = {
>> 		if (ScreenPainter !is null || !ScreenPainter()) <--- error
>> 			...
>> 	};
>>
>> I have defined ScreenPainter elsewhere in the module.
>
> So ScreenPainter is a *type* and not an instance of a type? That *should* be an error, no matter which compiler you use. You can't compare a type against null. What does that even mean? And if SimpleDisplay already defines the type, why have you redefined it?
>
> Assuming ScreenPainter is a class, then:
>
> if(ScreenPainter !is null) <-- Invalid
>
> auto sp = new ScreenPainter;
> if(sp !is null) <-- valid
>
>
>>
>> I can fix this by avoiding the import... but the point is that it's different than dmd.
>
> If ScreenPainter is defined as a type, it shouldn't ever compile. How have you defined it?
>
>>
>> So ldc parses things differently than dmd... I imagine this is a bug!
>
> LDC and DMD share the same front end, meaning they parse code the same. I really would like to see your code, particularly your definition of ScreenPainter.
>
>> Although, If I set the subsystem to windows I then get the error
>>
>>  error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)>
>> Which looks like it's not linking to runtime and/or phobos?
>
> No, this has nothing to do with DRuntime, Phobos, or even D. It's a Windows thing. By default, when you compile a D program, you are creating a console system executable so your primary entry point is an extern(C) main function that is generated by the compiler. This initializes DRuntime, which in turn calls your D main function.
>
> When using OPTLINK with DMD, the linker will ensure that the generated extern(C) main remains the entry point when you set the subsystem to Windows. When using the MS linker, this is not the case. The linker will expect WinMain to be the entry point when the subsystem is set to Windows. If you do not have a WinMain, you will see the error above. In order to keep the extern(C) main as your entry point, you have to pass the /ENTRY option to the linker (see[1]). LDC should provide a means for passing linker options. You can probably set in VisualD's project settings, but if there's no field for it then ldc2 --help may tell you what you need.
>
> Alternatively, you can create a WinMain, but then you need to initialize DRuntime yourself. See [2], but ignore the .def file requirement since you are already setting the subsystem.
>
>
>>
>> I seriously don't know how anyone gets anything done with all these problems ;/ The D community can't expect to get people interested in things don't work. If it wasn't because the D language was so awesome I wouldn't stick around! It's as if no one does any real testing on this stuff before it's released ;/
>
> Then I would ask you to stop and think. There are a number of people using D without problems every day, including several companies. Obviously, they aren't having the same difficulties you are, else they wouldn't be successfully using D. You seem to be very quick to blame the tools rather than considering you might not fully understand how to use them. I don't mean that in a disparaging way. I've been there myself, trying to get something I wanted to use working and failing, then getting frustrated and blaming the tools. These days, I always blame yourself first. Sure, the tools sometimes have bugs and other issues, but more often than not it's because I'm using them the wrong way.
>
> Right now, documentation on getting up to speed with LDC is sorely lacking. That's a valid criticism to make. For people who aren't familiar with it, or who aren't well versed in working with ahead of time compilers, whichever the case may be, it may not be the best choice for getting started with D. Since you seem to be having difficulties using LDC and since you've already told me that DMD is working for you, I strongly recommend that you use DMD instead for now. Once you are comfortable with D and the ecosystem, then look into using LDC.
>
>
>> 1. LDC has a bug in it. Simple as that. Replacing ldc2's bin dir with older ldc2 version essentially solved the problem(that being it not parsing paths correctly).
>>
>> 2. LDC has a discontinuity with dmd. Maybe fixed in the latest version... but I can't tell.
>
> LDC may have bugs, but I don't believe the problem you talked about above is one of them. I would really like to see all of the code you are trying to compile. The error you saw was what I would expect to see when trying to compare a type to null.
>
>
>> 3. LDC x64 cannot find "winmain" or whatever while DMD does. This is if the subsystem is set to windows. If set to console it works but then windows app has console that pops up, which is not acceptable. This too may have been fixed in the latest ldc.
>
> As I explained above, this is not a problem with LDC. The compile-link process in D is the same as it is in C and C++ and the generated Windows executables have the same requirements. As it is not D specific, there are a number of pages on the internet dealing with compiling and linking on Windows. Those will help you when using D compilers as well. You just have to adapt any compiler-specific command line arguments to the compiler you are using. I strongly recommend you familiarize yourself with the MS linker options, since it is prominent in the D toolchain on Windows now.
>
>
>
> [1] https://msdn.microsoft.com/en-us/library/f9t8842e.aspx
> [2] https://wiki.dlang.org/D_for_Win32


1. Your mixing up my problems(maybe my fault, but that's not the point). The phobo's errors are

simpledisplay.obj : error LNK2001: unresolved external symbol __D10TypeInfo_w6__initZ
winmain.obj : error LNK2019: unresolved external symbol __D4core6memory2GC7collectFNbZv (nothrow void core.memory.GC.collect()) referenced in function __Dmain
winmain.obj : error LNK2019: unresolved external symbol __d_run_main referenced in function _main
winmain.obj : error LNK2001: unresolved external symbol __D4core7runtime12__ModuleInfoZ
LINK : error LNK2001: unresolved external symbol __load_config_used
../ldc2/bin/../lib64\phobos2-ldc.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'X86'
.../ldc2/bin/../lib64\druntime-ldc.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'X86'

This happens only when I compile to x86. X64 works fine. The dir is the ldc dir, not mine. This suggests druntim-ldc.lib is x64 and not x86. (As one can see from lib64, why it is being used instead of lib32 is beyond me... but I don't see that in any of my configurable settings)

The best I can tell is that ldc:

// This configuration file uses libconfig.
// See http://www.hyperrealm.com/libconfig/ for syntax details.

// The default group is required
default:
{
    // 'switches' holds array of string that are appends to the command line
    // arguments before they are parsed.
    switches = [
        "-I%%ldcbinarypath%%/../include/d/ldc",
        "-I%%ldcbinarypath%%/../include/d",
        "-L-L%%ldcbinarypath%%/../lib64",
        "-defaultlib=phobos2-ldc,druntime-ldc",
        "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
    ];
};

i686-pc-windows-msvc:
{
    // 'switches' holds array of string that are appends to the command line
    // arguments before they are parsed.
    switches = [
        "-I%%ldcbinarypath%%/../include/d/ldc",
        "-I%%ldcbinarypath%%/../include/d",
        "-L-L%%ldcbinarypath%%/../lib32",
        "-defaultlib=phobos2-ldc,druntime-ldc",
        "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
    ];
};

is defaulting to x64 and not using the lib32 dir like it should. Getting it to should lib32 should fix the compilation problem.

The -L/Entry thing did fix the x64 windows subsystem problem... so everything is working now for x64.

2. The type bug seems to be a change in dmd/ldc. It is an import issue. I used the same name as Adam and for some reason ldc imports his into my project and dmd does not. See his post for that.

3. There is definitely a bug in the latest ldc... Swapping binaries may be a bad thing to you but it's the only way I could quickly diagnose the problem. I'd rather pack a wound with mud then let someone bleed out and die because mud is unsanitary. It proves there is a problem with ldc since the "correct" installation doesn't work in the first place and simply swapping the binaries makes it work. (basic math here)

On Sunday, 12 June 2016 at 12:38:25 UTC, Adam D. Ruppe wrote:
> On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
>> 2. I got an error that I don't get with dmd:
>>
>> Error: incompatible types for ((ScreenPainter) !is (null)): cannot use '!is' with types		
>>
>> and I have defined ScreenPainter in my code. It is also in arsd's simpledisplay. I do not import simpledisplay directly:
>
> It's probably the difference of the recent import rules bug fix. gamehelpers public imports simpledisplay, so its ScreenPainter will be visible there too.
>
> You can probably just exclude it from the import by doing selective:
>
> import arsd.gamehelpers : create2dWindow;
>
> and comma list anything else you use from there (probably just OpenGlTexture, it is a small module).
>
>
> But yeah, weird that it is different, but this was REALLY recently changed so if the release differs by just one month in version it could account for the difference.
>
>> Although, If I set the subsystem to windows I then get the error
>
> There's another MSFT library needed there passing `-L/entry:mainCRTStartup` to the build should do it.
>
> dmd 32 bit has its own library so it isn't needed there, but dmd 64 bit and ldc both I believe need the entry point.


Thanks. It worked! BTW, when I compile a simple project with your simpledisplay it takes up around 300MB(for ldc, 400 for dmd) and uses about 15% cpu. Basically just a modified example that draws some images which maybe take up 20MB total. Any ideas why it's taking up so much space and cpu? What's it doing on your machine?

On Sunday, 12 June 2016 at 09:11:09 UTC, Johan Engelen wrote:
> On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
>> 
>> Here are the versions
>>
>> The one that isn't working:
>> LDC - the LLVM D compiler (30b1ed):
>>   based on DMD v2.071.1 and LLVM 3.9.0git-d06ea8a
>>   built with LDC - the LLVM D compiler (1.0.0)
>>   Default target: x86_64-pc-windows-msvc
>>   Host CPU: skylake
>>   http://dlang.org - http://wiki.dlang.org/LDC
>>
>> The one that is:
>> B:\DLang\ldc2\bin>ldc2 -version
>> LDC - the LLVM D compiler (1.0.0):
>>   based on DMD v2.070.2 and LLVM 3.9.0git
>>   built with LDC - the LLVM D compiler (1.0.0)
>>   Default target: i686-pc-windows-msvc
>>   Host CPU: skylake
>>   http://dlang.org - http://wiki.dlang.org/LDC
>
> The first one is a pre-alpha (!) version.
> The second one is our latest released version, which is the one I recommend you to use.
>
> If you want your bugs to be noted and fixed, you should try that test version and report bugs. That's kind of what you are doing now, so thanks ;)  Of course, clarity in reporting is important to get bugs fixed...

Ok. Well, I didn't know I was using an alpha version. Two bugs I have:

1. Paths(imports to subdirs as explained in my other posts) are not correct. It seems to be dropping the last '\'. Probably a simple substring range bug. (e.g., 1..$-2 instead of 1..$-1). Since it works in the previous version, it shouldn't be too hard to diff on the modules path resolution code.

2. There seems to be an issue with the x86 libs not being correctly resolved. The default is to choose x64. When I compile for x86 it still uses them. Maybe a compiler switch is needed, but regardless this isn't good practice. -m32 is being passed, maybe this should select the 32-bit configuration?

If these are regressions then someone needs to be fired!!! If not, someone still needs to be fired! Or at least be forced to buy me a ham burger or something!

On Sunday, 12 June 2016 at 13:05:48 UTC, Joerg Joergonson wrote:
> BTW, when I compile a simple project with your simpledisplay it takes up around 300MB(for ldc, 400 for dmd) and uses about 15% cpu.

What's your code? The library itself does fairly little so the time probably depends on your draw loop or timer settings (though it did have a memory leak until recently, it wasn't apparent until something had been running for a really long time - I use it in my day-to-day terminal emulator, so I have like 40 copies of the process running for months on end here...)


I'm leaving in 2 minutes for church btw so I might not answer you for about 5 hours when I'm back at the computer.

On Sunday, 12 June 2016 at 13:23:26 UTC, Adam D. Ruppe wrote:
> On Sunday, 12 June 2016 at 13:05:48 UTC, Joerg Joergonson wrote:
>> BTW, when I compile a simple project with your simpledisplay it takes up around 300MB(for ldc, 400 for dmd) and uses about 15% cpu.
>
> What's your code? The library itself does fairly little so the time probably depends on your draw loop or timer settings (though it did have a memory leak until recently, it wasn't apparent until something had been running for a really long time - I use it in my day-to-day terminal emulator, so I have like 40 copies of the process running for months on end here...)
>
>
> I'm leaving in 2 minutes for church btw so I might not answer you for about 5 hours when I'm back at the computer.

Well, it's about the same when I comment all my code out! It drops about 30 megs and a percent or two but still quite large.

When I remove all code, it is 2MB in size and 0 cpu(I just use Sleep to keep it from terminating).

When I try to use a sleep before the event loop to and just call create2dWindow, I get

Error: undefined identifier 'Sleep' in module 'core.thread', did you mean function 'Sleep'?		

Which godly in it's descriptive powers, right?

The code added is

		import core.thread;
		core.thread.Sleep(10000);

which is the same code I use in main() which works(worked)

		import core.thread : Sleep;
		Sleep(10000);

works though. Basically keeping the event loop uses around 12% cpu and 12MB of memory. Adding in my code, which simply uses your png to load some images and display them balloons it to 400MB. The exe is only 7MB in size.

So, I believe it is your code. The event loop is using quite a bit of cpu even when not "doing" anything(haven't look at it behind the scenes though).

The memory is probably from loading the images, possibly doubling all the images to powers of 2 might explain some of the bloat. I have a few large images that when uncompressed might be 20-40MB total and several smaller ones, probably insignificant. Shouldn't add up to 300MB though.

Once I get further in I'll try to see whats going on. I haven't noticed it leaking memory though.

Do you know if there is a way to get the largest used memory chunks and what is using them? That might tell the story!

On Sunday, 12 June 2016 at 14:22:54 UTC, Joerg Joergonson wrote:
> Error: undefined identifier 'Sleep' in module 'core.thread', did you mean function 'Sleep'?

It is supposed to be `Thread.sleep(10000.seconds);`

I'm pretty sure the capital Sleep() is supposed to be private (that is the OS-specific Windows api call).


> Basically keeping the event loop uses around 12% cpu and 12MB of memory.

That's weird, it just sleeps until a message comes in from the OS. On my computer, programs sit at 0% like you'd expect, and my guitest program (which has text areas, buttons, menu, etc) eats ~1.7 MB, both 32 and 64 bit versions.

Are you running some other program that might be sending a lot of broadcast messages?

> Do you know if there is a way to get the largest used memory chunks and what is using them? That might tell the story!

idk

On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote:
> BTW I make your code a bit better with resizing
>
> case WM_SIZING:
>     goto size_changed;
> break;

I left that out intentionally because it lagged on my computer... so I wanted it to stay blank.

Maybe it can be made more efficient though.

On Monday, 13 June 2016 at 16:46:38 UTC, Adam D. Ruppe wrote:
> On Sunday, 12 June 2016 at 14:22:54 UTC, Joerg Joergonson wrote:
>> Error: undefined identifier 'Sleep' in module 'core.thread', did you mean function 'Sleep'?
>
> It is supposed to be `Thread.sleep(10000.seconds);`
>
> I'm pretty sure the capital Sleep() is supposed to be private (that is the OS-specific Windows api call).
>

Ok, I tried both and Sleep was the one that worked for some odd ball reason.  Then it seemed to stop working I think(I tried it in a different spot)... maybe user error.

>> Basically keeping the event loop uses around 12% cpu and 12MB of memory.
>
> That's weird, it just sleeps until a message comes in from the OS. On my computer, programs sit at 0% like you'd expect, and my guitest program (which has text areas, buttons, menu, etc) eats ~1.7 MB, both 32 and 64 bit versions.
>
> Are you running some other program that might be sending a lot of broadcast messages?
>

Not that I know of. I haven't tried running it outside VS though so it might be doing something weird. I'll investigate further when I get a chance and get further down the road.

About the WM size thing, I haven't had a problem with it except for the weird vertical shifting. It doesn't use any more cpu when constantly resizing.

On Monday, 13 June 2016 at 20:21:28 UTC, Joerg Joergonson wrote:
>> Are you running some other program that might be sending a lot of broadcast messages?
>>
>
> Not that I know of. I haven't tried running it outside VS though so it might be doing something weird. I'll investigate further when I get a chance and get further down the road.

It's often useful to attach a sampling profiler when the process is eating CPU. It should tell you what's going on at a glance.

I believe VS has a sampling profiler built in, but it most likely won't demangle D symbols, so the function names will be a bit hard to read.