Had another 48hr game jam this weekend...

Kapps opantm2+spam at gmail.com
Sat Aug 31 21:45:48 PDT 2013


On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> The only compiler you can realistically use productively in 
> windows is
> DMD-Win64, and that doesn't work out of the box.
> We needed to mess with sc.ini for quite some time to get the 
> stars aligned
> such that it would actually compile and find the linker+libs.

I also spent a decent bit of effort getting Win64 to work, and I 
agree that this is something that DMD should attempt to bundle. 
It may not need to go as far as downloading VC express for you, 
but it should allow integration of an existing install during 
installation (and ideally post-installation as well). This is a 
pretty big deal IMO. When I was a newbie, issues with COFF vs 
OMF, coffimplib confusion, etc, were almost deal-breakers to me. 
I just couldn't get things easily working, and I'm sure many 
others see it the same way. Having Win64 gives us a chance to fix 
that, but it *has* to be integrated into the installer. The 
compiler should ideally detect that the VS linker / libraries are 
missing when you use -m64, and tell you how to download VS 
Express as well as directing you to a batch file bundled with DMD 
to update sc.ini. Going a step further, it'd be even nicer if 
-m64 was default but that's not feasible with external 
dependencies. However when it detects a library in an invalid 
format, it should inform you about the existence of coffimplib 
and a download link, as well as how this is necessary only when 
compiling 32-bit executables. I don't think that the core 
contributors realize how incredibly frustrating these issues are 
to beginners, and thus feel as if it's not something that needs 
to be solved.

> Getting a workable environment:
>
> Unsurprisingly, the Linux user was the only person happy work 
> with a
> makefile. Everybody else wanted a comfortable IDE solution (and 
> the linux
> user would prefer it too).
>
> !!!!!!!!!
> This has to be given first-class attention!
> I am completely and utterly sick of this problem. Don made a 
> massive point
> of it in his DConf talk, and I want to 
> re-re-re-re-re-re-re-stress how
> absolutely important this is.
> !!!!!!!!!

I have to say, I don't see why you find this to be such a large 
issue. DMD is unique in the sense that it's the only thing I've 
ever been able to compile on Windows without running into many 
issues. So long as you have DMC installed, it just works. I've 
never had any makefile related issues on any platform. This is a 
big deal, as DMD evolves so rapidly that users should be able to 
get the git version with minimal effort, without having to 
download an IDE for it.

> Overwhelmingly, the biggest complaint was a lack of symbolic 
> information to
> assist with auto-completion. Visual-D tries valiantly, but it 
> falls quite
> short of the mark.
> This goes back to the threads where the IDE guys are writing 
> their own
> parsers, when really, DMD should be able to be built as a lib, 
> with an API
> designed for using DMD as a lib/plugin.
> I think continuous code compilation for auto-completion and 
> syntax
> highlighting purposes should be a service offered and 
> maintained by DMD.
> That way it will evolve with the language, and anyone can use 
> it without
> reinventing the wheel.

While yes, it would be wonderful if we could get DMD to do this 
(again, I don't think a lot of the core contributors realize just 
how incredibly important IDEs and perfect auto-completion are), 
it doesn't seem to be something likely in the short-term. That 
being said, I've actually found Mono-D to be excellent recently. 
It doesn't handle things like CTFE properly and other similar 
issues, but for my purposes it's worked rather well (that being 
said, I avoid mixins for the most part, largely due to this). 
Despite all this, I'm actually quite happy with Mono-D lately.

One thing I've toyed with is the idea of using reflection for 
getting auto-complete information. I made a runtime reflection 
module (has a fair few issues still), and I wonder if it would be 
possible to use something similar for this purpose. Most modules 
could be cached, allowing us to build only the module you're 
altering. On top of that, some real-time parsing could be done 
for code modified since the last recompile (really it would need 
to primarily handle scanning for methods and variables). History 
completion from the current file, such as what editors like 
Sublime Text do, could perhaps be integrated to completely 
eliminate the issue of not being able to find a symbol in your 
auto-complete list. That would likely only kick in when it finds 
no results for anything else. Plus since you're recompiling 
frequently in the background, you would get early notifications 
of errors/warnings like you would in C#/Java. Ultimately though, 
I'm not sure if this would be updated fast enough (depends how 
long compiles take) to be feasible.


> Debugging:
>
> Poor debugging experience wastes your time every 5 minutes.
> I can only speak for the Windows experience (since we failed to 
> get OSX
> working); there are lots of problems with the debugging 
> experience under
> visual studio...
> I haven't logged bugs yet, but I intend to.
> There were many instances of people wasting their time chasing 
> bugs in
> random places when it was simply a case of the debugger lying 
> about the
> value of variables to them, and many more cases where the 
> debugger simply
> refused to produce values for some variables at all.
> This is an unacceptable waste of programmers time, and again, 
> really burned
> us in a 48hour context.

Agreed, debugging is currently lacking thoroughly. Using Linux, 
Mono-D's works okay but it still jumps around a lot (even in 
debug mode) and hovering over variables isn't great yet. I really 
miss the Immediate Window from C# / Visual Studio, and it would 
be nice to have that. This is something that runtime reflection 
could handle.

> Containers:
>
> The question came up multiple times; "I don't think this should 
> be an
> array... what containers can I use, and where are they?"...
> Also, nobody could work out how to remove an arbitrary item 
> from an array,
> or an item from an AA by reference/value (only by key).
>
> This code:
>   foreach(i, item; array)
>     if(item == itemToRemove)
>       array = array[0..i] ~ array[i+1..$];
> Got a rather 'negative' reaction from the audience to put it 
> lightly...

Completely agreed. Containers are another huge problem which 
needs to be solved as soon as possible, yet is constantly getting 
pushed back. The idea that a language like D doesn't even have 
anything but the most basic containers in it's standard library 
is laughable. I shudder to think at how many different 
implementations exist of common containers right now in user code.

>
> Bugs:
> Yes, we hit DMD bugs, like the one with opaque structs which 
> required
> extensive work-arounds.
>   struct MyStruct;
>   MyStruct*[] = new MyStruct*[n];
>
> We also ran into some completely nonsense error messages, but I 
> forgot to
> log them, since we were working against the clock.

I used to hit compiler bugs very frequently, yet this is 
something that D has improved incredibly on. It's wonderful to 
not have to worry with every compile if there will be bugs. It's 
also wonderful to not have to worry about changing your code with 
every single compiler release. D has made *huge* headway in these 
two issues. Sure, there are still many bugs, but they're becoming 
less frequent for me and I find that workarounds are easier than 
before.

> One more thing:
> I'll just pick one language complaint from the weekend.
> It is how quickly classes became disorganised and difficult to 
> navigate
> (like Java and C#).
> We all wanted to ability to define class member functions 
> outside the class
> definition:
>   class MyClass
>   {
>     void method();
>   }
>
>   void MyClass.method()
>   {
>     //...
>   }
>
> It definitely cost us time simply trying to understand the 
> class layout
> visually (ie, when IDE support is barely available).
> You don't need to see the function bodies in the class 
> definition, you want
> to quickly see what a class has and does.

This isn't something I've found to be an issue personally, but I 
suppose it's a matter of what you're used to. Since I'm used to 
C#, I haven't had problems with this. I've always felt that this 
was the IDE's job, personally. That being said, perhaps .di files 
could help with this?


More information about the Digitalmars-d mailing list