View mode: basic / threaded / horizontal-split · Log in · Help
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

The import stuff has been part of C for a long time (in the form of 
#include), however I've never seen it used.  Maybe with string 
operations it will be useful, but otherwise I don't see the point.

=Joel
February 06, 2007
Re: DMD 1.005 release
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.

> 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.

maybe a mixin(string, filename) form would be nice. It would dump to 
given file as well as generate code.

> 
> 
> Sean
February 06, 2007
Re: DMD 1.005 release
janderson wrote:
> 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
> 
> 
> The import stuff has been part of C for a long time (in the form of 
> #include), however I've never seen it used.  Maybe with string 
> operations it will be useful, but otherwise I don't see the point.
> 
> =Joel

not quite, I don't think this works in c

char string[] = "#import<bigstring.txt>"

sting gets the value of "#import<bigstring.txt>", not the contents of 
"bigstring.txt"
February 06, 2007
Re: DMD 1.005 release
Sean Kelly wrote:
> If there were a way to emit the "expanded" source we could even use this as 
> a "standalone" code generation tool of sorts.

Now there's something that's missing.  At least with C compilers, they can usually be asked to spit out what things look 
like after the pre-processor is done with it.  Getting the same kind of results from DMD, after all templates are 
evaluated would be great for diagnostics and debugging.

-- 
- EricAnderton at yahoo
February 06, 2007
Re: DMD 1.005 release
BCS wrote:
> 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
>>
>>
> 
> This could do thing like this:
> 
> BuildBarserFromFileSpec!("foo.bnf")
> 
> that would import "foo.bnf", parser a BNF grammar, and build a parser 
> from it. It even avoids the need to use functions for callbacks.
> 
> 
> p.s.
> I'm going to have to try and re-implement dparse using this.
> 
> Darn you Walter!!! I don't have time for this (cool stuff)!!! <G>

BCS: I may be tempted to Enki-ize your work once you're done with that. I think a compile-time rendition is due. ;)

-- 
- EricAnderton at yahoo
February 06, 2007
Re: DMD 1.005 release
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>
February 06, 2007
Re: DMD 1.005 release
BLS wrote:
> Pragma schrieb:
>> 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
>>
>>
>> Just try to wrap your head around this: 
>> http://www.digitalmars.com/d/mixin.html
>>
>> template GenStruct(char[] Name, char[] M1)
>> {
>>     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
>> }
>>
>> mixin(GenStruct!("Foo", "bar"));
>>
>> //which generates:
>>
>> struct Foo { int bar; }
>>
>> In short this means that we can have *100%* arbitrary code generation 
>> at compile time, w/o need of a new grammar to support the capability.
>>
> 
> Hi Eric,
> I am able to read and understand the code. (not nessesarily the far 
> reaching implications)
> But the generated code is still D. So what does it mean :
> Walter Bright schrieb:
>  > The idea is to enable the creation of DSLs (Domain Specific Languages)
> How ?
> Bjoern


I think you answered your own question. :)

Take the compile-time regexp lib that Don and I wrote a while back.  Technically, Regular-expressions are a DSL of 
sorts.  This feature just makes the implementation of stuff like that easier.  The end result will still be D code.

auto widget = CreateNewWidget!("Some DSL Code");

I was confused too, since the wording could be interpreted as allowing you to just code in some other language, wherever 
you want.  This is not the case.  Ultimately, any DSL implemented in this fashion is going to have to operate on static 
strings.

> I can imagine the following scenario : D Compiler is calling a
> Translator, a modified Enki f.i. to translate a Domain Specific Language
> into D ... strange

I've thought about that too- much like BCS's work.  The only thing keeping me from doing this *was* that the code 
generated would be largely inferior to that created by an external program.  Thanks to the new syntax of mixin(), this 
is no longer the case.

-- 
- EricAnderton at yahoo
February 06, 2007
Re: DMD 1.005 release
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>

-- 
- EricAnderton at yahoo
February 06, 2007
Re: DMD 1.005 release
janderson wrote:
> The import stuff has been part of C for a long time (in the form of 
> #include), however I've never seen it used.  Maybe with string 
> operations it will be useful, but otherwise I don't see the point.

The fundamental difference is that #include inserts *program text*, 
while import inserts the contents as a *string literal*.

Some things that you can do with import that you cannot do with #include:

1) You can have tech writers write "help text" files, which can then be 
imported by the programmers as string literals. This means the tech 
writers do not have to be concerned in the slightest with string syntax.

2) It's an easy way to bind binary data into a program. For example, 
let's say one wants to embed an icon (.ico) file into your program 
binary. In C, one would have to write:

	static unsigned char icon[] = { 0x00, 0x10, 0x53, 0x29, ... };

meaning one must translate the binary data in foo.ico to the hex notation.

In D, one can write:

	static ubyte[] icon = cast(ubyte[])import("foo.ico");
February 06, 2007
Re: DMD 1.005 release - compile error
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

Am 06.02.2007, 05:54 Uhr, schrieb Walter Bright  
<newshound@digitalmars.com>:

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



-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home