View mode: basic / threaded / horizontal-split · Log in · Help
February 06, 2007
Re: DMD 1.005 release
Reply to Ary,

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

Cool thought:

build a compiler / IDE where the would front end short of code-gen is ued 
to read in code and the editor actually edits the parsed code tree. Say goodbye 
to syntax errors, maybe even semantic ones as well because you can't edit 
code to something that isn't correct... Er, maybe that wouldn't be such a 
good idea. Anyway, what is on the screen is actually a rendering of the parsed 
stuff. Talk about fast compile times:

codetree.CodeGen(); // no parsing etc.

Also the same functions that do name scopeing can do auto-compleat (or the 
other way around).
February 06, 2007
Re: DMD 1.005 release
Pragma 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
> 
> 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.
> 

Combine that with the ever increasing power of Tuples, some of the slowly improving type 
info, and compile-time string manipulation.... and you've got programs that write programs 
for writing programs that generate the original program automatically.  o_O

I like it.  Might even scrap some old code in favor of it.

-- Chris Nicholson-Sauls
February 06, 2007
Re: DMD 1.005 release
Pragma wrote:
> 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");

You just showed something that I've been pondering attempting with this.  Namely a GUI 
library that builds all forms/controls/etc from some sort of markup (probably modified XML 
or JSON), either at runtime /or/ compile-time.

-- Chris Nicholson-Sauls
February 06, 2007
Re: DMD 1.005 release - compile error
Thanks! That worked :)

Am 06.02.2007, 19:28 Uhr, schrieb Thomas Brix Larsen <brix@brix-verden.dk>:

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



-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
February 06, 2007
Re: DMD 1.005 release
Sean Kelly wrote:
> 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

When you inherit code or start to code on an existing project, the 
ability to 'ctrl+click' to jump to that variables definition is a huge 
time saver, otherwise you have to grep through tons of files , and in 
large libraries the classes may be nested very deep, you might have to 
ctrl+click 5 times before you get to what you're looking for.

I've actually gone the opposite way, drifting towards IDE's over time, 
even though for 'one-moduler's it remains <insert favorite editor here>.

I am really looking forward to descent, I hope you can devote enough 
time to Ary.


Charlie
February 06, 2007
Re: DMD 1.005 release
On Tue, 06 Feb 2007 11:55:18 -0800, Walter Bright wrote:

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

Thanks Walter! :-(

Bud is no longer a useful tool because it can no longer do what it was
trying to do - namely find out which files needed recompiling and get only
that done. Because in order to do that now, it first has to recursively
compile each command line file and imported file using the -c -v switches
to get a list of the potential files needing to be checked for
recompilation. But seeing I've just compiled them to get this list, there
is not much point now in /recompiling/ them. Also, mixin-imported files are
not necessarily modules but must be treated as code fragments, so they
can't be compiled to see if they in-turn effectively import other files!

My work here is (un)done.

It seems that DMD now needs to be enhanced to do what Rebuild and Bud were
trying to do. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
7/02/2007 10:18:52 AM
February 06, 2007
Re: DMD 1.005 release
Reply to Derek,

> Thanks Walter! :-(
> 
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get
> only that done. Because in order to do that now, it first has to
> recursively compile each command line file and imported file using the
> -c -v switches to get a list of the potential files needing to be
> checked for recompilation. But seeing I've just compiled them to get
> this list, there is not much point now in /recompiling/ them. Also,
> mixin-imported files are not necessarily modules but must be treated
> as code fragments, so they can't be compiled to see if they in-turn
> effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud
> were trying to do.
> 

If bud keep around meta data about what happened last time (building N required 
A, B, C) then if none of those changed, the set of files that can be used 
can't change. Having that kind of tree would let you do a minimal rebuild 
even with the new import stuff.

Once you go that direction (DMD would have to report the files used) why 
not have DMD report the public interface of each module? that would let bud 
notice when a change in a module doesn't demands a rebuild of the modules 
that import it. Some of this might be possible by watching for actual changes 
in .di file, not just checking modification dates.
February 07, 2007
Re: DMD 1.005 release
Derek Parnell wrote:
> On Tue, 06 Feb 2007 11:55:18 -0800, Walter Bright wrote:
> 
>> 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.
> 
> Thanks Walter! :-(
> 
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get only
> that done. Because in order to do that now, it first has to recursively
> compile each command line file and imported file using the -c -v switches
> to get a list of the potential files needing to be checked for
> recompilation. But seeing I've just compiled them to get this list, there
> is not much point now in /recompiling/ them. Also, mixin-imported files are
> not necessarily modules but must be treated as code fragments, so they
> can't be compiled to see if they in-turn effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud were
> trying to do. 
> 

Perhaps it would be feasible to turn bud (and perhaps rebuild) into 
Makefile generators.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
February 07, 2007
Re: DMD 1.005 release
Derek Parnell wrote:
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get only
> that done. Because in order to do that now, it first has to recursively
> compile each command line file and imported file using the -c -v switches
> to get a list of the potential files needing to be checked for
> recompilation. But seeing I've just compiled them to get this list, there
> is not much point now in /recompiling/ them. Also, mixin-imported files are
> not necessarily modules but must be treated as code fragments, so they
> can't be compiled to see if they in-turn effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud were
> trying to do. 

The compiler cannot tell what file it'll need to textually import 
without compiling either, so cannot do a 'make' on textual imports.

No tool is perfect; I recommend just ignoring the problem with textual 
imports. Such shouldn't be used outside of specialized modules.
February 07, 2007
Re: DMD 1.005 release
Ary Manzana wrote:
> Walter Bright escribió:
>> True, but on the other hand, specifically not supporting it in the IDE 
>> may act as a needed brake on evil uses of it.
> But... I'm wondering which are the evil uses of it.

From my point of view, evil uses of it are things like version control:

	mixin(import("versions.txt"));

where versions.txt contains:

	version = FOO;
	version = BAR;

etc., or other uses that subvert the right way to do things. One should 
think long and hard about using textual import to import D code.

What it's for is to:

1) import data for a string constant
2) import code that's in DSL (Domain Specific Language), not D, form.
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home