February 06, 2007
mike wrote:

> Updated DMD to 1.005 from 1.0 today and now I get this error:
> 
> ' C:\dmd\src\ext\derelict\sdl\ttf.d(79): struct derelict.sdl.ttf._TTF_Font
> unknown
> '  size
> ' C:\dmd\src\ext\derelict\sdl\ttf.d(79): struct derelict.sdl.ttf._TTF_Font
> no size
> '  yet for forward reference
> 
> Does anybody know how to fix that? I've already searched the NG, the derelict forum, upgraded to the latest trunk ... nothing helped so far.
> 
> -Mike
> 

It should read: struct _TTF_Font {} http://dsource.org/projects/derelict/browser/trunk/DerelictSDLttf/derelict/sdl/ttf.d

- Brix

February 06, 2007
Pragma wrote:
> BCS wrote:
> 
>> Pragma wrote:
>>
>>> BCS wrote:
>>>
>>>> p.s.
>>>> I'm going to have to try and re-implement dparse using this.
>>>>
>>>
>>> BCS: I may be tempted to Enki-ize your work once you're done with that. I think a compile-time rendition is due. ;)
>>>
>>
>> Done? What is that? I haven't heard the term before. <g>
> 
> 
> BCS, you're not working at 3D-realms by any chance, are you? <eg>
> 

no, I'm an Mechanical engineering undergraduate student working in declarative code/system generation (professionally) and secure software systems (academically)
February 06, 2007

Walter Bright wrote:
> Fixes many bugs, some serious.
> 
> Some new goodies.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.1.005.zip

Wow, this is no small change .. this should've ben dmd 1.2 or something.

Now, there's already been alot of talk about what new doors this might open, so I'm not gonna talk about that.

What concerns me is that this will make semantic analysis more difficult to implement.

Just think about "build/bud" for example, now the author will have to worry about things like:
mixin("import x.y.z");

or even worse:
mixin(templ1!(something, templ2!(somethingelse), "x.y"));

I don't see how it's possible to interpret that without implementing a full compiler.

P.S. I know that for "build" all we need is a list of import files, and dmd already has a switch to do that.



February 06, 2007
Hasan Aljudy wrote:
> I don't see how it's possible to interpret that without implementing a full compiler.

You're right, it isn't possible.

> P.S. I know that for "build" all we need is a list of import files, and dmd already has a switch to do that.

DMD will also output a list of files that are textually imported, so bud can pick them up at least the second time around.
February 06, 2007
Hasan Aljudy escribió:
> 
> 
> Walter Bright wrote:
>> Fixes many bugs, some serious.
>>
>> Some new goodies.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.1.005.zip
> 
> Wow, this is no small change .. this should've ben dmd 1.2 or something.
> 
> Now, there's already been alot of talk about what new doors this might open, so I'm not gonna talk about that.
> 
> What concerns me is that this will make semantic analysis more difficult to implement.
> 
> Just think about "build/bud" for example, now the author will have to worry about things like:
> mixin("import x.y.z");
> 
> or even worse:
> mixin(templ1!(something, templ2!(somethingelse), "x.y"));
> 
> I don't see how it's possible to interpret that without implementing a full compiler.
> 
> P.S. I know that for "build" all we need is a list of import files, and dmd already has a switch to do that.

I also like the new features and think the same as you.

First, I don't know what is the real beneffit of this features. I mean, I want to see a real world example using mixins before thinking they are great (BTW, the first time I saw them PHP inmediately came into my head... even more after the post about """ @msg """).

Second, this makes even harder to get good IDE support for D. You can have syntax coloring, and that's it. Autocompletion is going to be a very though part: the IDE must act as a compiler, as you say it, to figure out what the program will look like so that it can know what are the declarations available to the programmer.

Anyway, I'm still working on Descent, and when I get to that part (which I plan to implement because it's all there, in DMD... I guess?), I'll tell you. :-)
February 06, 2007
BCS wrote:
> Sean Kelly wrote:
>>
>>
>> The most obvious danger is simply being able to eyeball what the source code for a module actually is, but that's been an issue for any sufficiently complex template code anyway.  
> 
> How are #line directives handled? is their any way to tell the debugger to look at another file:
> 
> mixin(MixInThisFile("foo"));
> 
> // results in this
> 
> // stuff
> #line foo, 127
> // stuff from foo:127
> 
> #line ... // revert back to original file:line
> 
> Then, in the debugger, it would start stepping you through foo in the correct place.

I suspect that generating debug info will require the mixed-in code to be expanded in place with the proper #line directives, etc, in the object file.

>> If there were a way to emit the "expanded" source we could even use this as a "standalone" code generation tool of sorts.  Nice work!
> 
> Put in a pragma msg in place of the mixin and you get the code.

Yup.  I think for a standalone code generator, it would probably be better to generate the output file completely through pragma(msg) so as to omit the template code used for processing the mixins.  For example, I figure it shouldn't be terribly difficult to do D codegen from a UML file in template code, etc.


Sean
February 06, 2007
Ary Manzana wrote:
> Second, this makes even harder to get good IDE support for D. You can have syntax coloring, and that's it. Autocompletion is going to be a very though part: the IDE must act as a compiler, as you say it, to figure out what the program will look like so that it can know what are the declarations available to the programmer.

True, but on the other hand, specifically not supporting it in the IDE may act as a needed brake on evil uses of it.
February 06, 2007
Walter Bright escribió:
> Ary Manzana wrote:
>> Second, this makes even harder to get good IDE support for D. You can have syntax coloring, and that's it. Autocompletion is going to be a very though part: the IDE must act as a compiler, as you say it, to figure out what the program will look like so that it can know what are the declarations available to the programmer.
> 
> True, but on the other hand, specifically not supporting it in the IDE may act as a needed brake on evil uses of it.

I didn't say an IDE won't support it, I said it'll be very hard to get there :-)

But... I'm wondering which are the evil uses of it. For me it's now almost impossible not to program with an IDE (big projects, I mean). At least in Java. Maybe compile time stuff will make it such that an IDE won't be needed anymore. But it's very hard for me to see that happening.
February 06, 2007
BLS wrote:
> I guess here is a need for further explaination.
> 
> Either I am an complete idiot (not completely unrealistic) and missunderstood something, or a new, quit radical, programming paradigmn change is on it s way.  I mean it is difficult to realize the implications.
> Bjoern

I am not a D programmer (yet) only observing what is happening.

I compare the new "code generation at compile-time" stuff in D with Forth. Forth also has a built-in interpreter & compiler which extends the language and can also execute macros at compile-time through EVALUATE. Of course Forth is much more low-level than D. But IMO the new mixins are not a "radical programming paradigm change".

Perhaps I just did misunderstand something?

Andreas
February 06, 2007
Ary Manzana wrote:
> Walter Bright escribió:
>> Ary Manzana wrote:
>>> Second, this makes even harder to get good IDE support for D. You can have syntax coloring, and that's it. Autocompletion is going to be a very though part: the IDE must act as a compiler, as you say it, to figure out what the program will look like so that it can know what are the declarations available to the programmer.
>>
>> True, but on the other hand, specifically not supporting it in the IDE may act as a needed brake on evil uses of it.
> 
> I didn't say an IDE won't support it, I said it'll be very hard to get there :-)
> 
> But... I'm wondering which are the evil uses of it. For me it's now almost impossible not to program with an IDE (big projects, I mean). At least in Java. Maybe compile time stuff will make it such that an IDE won't be needed anymore. But it's very hard for me to see that happening.

Oddly, I've found myself moving away from IDEs over the years, perhaps partially because the editors I like to use aren't IDEs.  About the only time I use an IDE any more is for debugging... coding happens elsewhere.


Sean