View mode: basic / threaded / horizontal-split · Log in · Help
February 06, 2007
Re: DMD 1.005 release - compile error
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home