Re: Just one more thing...
Frits van Bommel wrote:
> Sean Kelly wrote:
>> Daniel Keep wrote:
>>> extern(C) void __identifier("blah$UNIX2003")(int);
>>
>> That would be awesome.
>>
>>> A beneficial side-effect is that I can finally get rid of all those
>>> mixins that are just doing this:
>>>
>>> mixin(`void `~name_of_fn~`(int a)
>>> {
>>> // ... rest of function ...
>>> }`);
>>
>> I had absolutely no idea that this could be used to generate symbol
>> names that are illegal in D.
>
> I don't think he's generating illegal symbol names. He's just sick of
> having to specify the whole function in a string when all he wants to
> change from instantiation to instantiation is the name...
/cookie fvbommel
-- Daniel
Re: Profiling with DMD on Windows
On Mon, 02 Mar 2009 05:12:28 +0300, Sergey Gromov wrote: > I've just finished a two-part blog/article/tutorial on profiling. > Anybody interested, welcome. > > http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on- windows/ > http://snakecoder.wordpress.com/2009/03/02/profiling-with-dmd-on- windows-getting-hands-dirty/ > > Walter also posted the first one on Reddit some time ago: > > http://www.reddit.com/r/d_language/comments/80lpm/ profiling_with_digital_mars_d_compiler_on_windows/ Thanks!
Profiling with DMD on Windows
I've just finished a two-part blog/article/tutorial on profiling. Anybody interested, welcome. http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on-windows/ http://snakecoder.wordpress.com/2009/03/02/profiling-with-dmd-on-windows-getting-hands-dirty/ Walter also posted the first one on Reddit some time ago: http://www.reddit.com/r/d_language/comments/80lpm/profiling_with_digital_mars_d_compiler_on_windows/
Re: Just one more thing...
Sean Kelly wrote:
Daniel Keep wrote:
extern(C) void __identifier("blah$UNIX2003")(int);
That would be awesome.
A beneficial side-effect is that I can finally get rid of all those
mixins that are just doing this:
mixin(`void `~name_of_fn~`(int a)
{
// ... rest of function ...
}`);
I had absolutely no idea that this could be used to generate symbol
names that are illegal in D.
I don't think he's generating illegal symbol names. He's just sick of
having to specify the whole function in a string when all he wants to
change from instantiation to instantiation is the name...
Re: Metaprogramming in D tonight at the NWCPP
Hello Walter, Robert Fraser wrote: Walter Bright wrote: http://www.nwcpp.org/ !!! I had a lab or I would have gone ;-( Any chance of a video...? Bartosz videotaped it, I imagine he'll put it up on the nwcpp.org web site soon. Bump ?
Re: Just one more thing...
Daniel Keep wrote:
Sean Kelly wrote:
One somewhat weird issue that we may have to face at some point is that
Posix functions whose behavior was changed have had the symbol for the
new function changed to _blah$UNIX2003, with the old function left in
place. Since D can't declare symbols like this, we may end up having to
add shims in C or post-process object files if it turns out that the old
implementation of a function isn't sufficient. I'd love to hear of a
better solution here.
extern(C) void __identifier("blah$UNIX2003")(int);
That would be awesome.
A beneficial side-effect is that I can finally get rid of all those
mixins that are just doing this:
mixin(`void `~name_of_fn~`(int a)
{
// ... rest of function ...
}`);
I had absolutely no idea that this could be used to generate symbol
names that are illegal in D.
Re: Compiler Construction seminar, Sep 20-22
On Sun, 01 Mar 2009 13:16:43 -0800, Walter Bright wrote: > (With the recession and low fuel prices, tickets ought to be more > reasonable.) LOL -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: QtD 0.1 is out!
Frits van Bommel wrote: Not even on a best-effort basis? It doesn't have to catch every possible case; I for one would be perfectly fine with it if it didn't catch the "I omitted a private import from my .di file" case... Doing so would require full blown data flow analysis, which the front end is not equipped to do.
Re: Compiler Construction seminar, Sep 20-22
Nick Sabalausky wrote: The ability to actually get there. Which rules me out. Darnit! (And I can't swim through the rockies!) That's why god invented airplanes! (With the recession and low fuel prices, tickets ought to be more reasonable.)
Re: QtD 0.1 is out!
Walter Bright wrote: Frits van Bommel wrote: Walter Bright wrote: The problem if it detects it in an implementation-defined manner is the source code is no longer portable. ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error? Nothing, it's just that the compiler cannot prove it is an error. Not even on a best-effort basis? It doesn't have to catch every possible case; I for one would be perfectly fine with it if it didn't catch the "I omitted a private import from my .di file" case...
Re: Compiler Construction seminar, Sep 20-22
"Bill Baxter" wrote in message news:mailman.888.1235931134.22690.digitalmars-d-annou...@puremagic.com... > On Sun, Mar 1, 2009 at 5:49 PM, Walter Bright > wrote: >> In Astoria, Oregon, on September 20-22 I'll be hosting a Compiler >> Construction seminar along with Cristian Vlasceanu. >> >> http://www.astoriaseminar.com/compiler-construction.html >> >> It'll be a two day intensive course in how compilers work and how to >> build >> them. > > What kind of pre-reqs are necessary? > The ability to actually get there. Which rules me out. Darnit! (And I can't swim through the rockies!)
Re: Compiler Construction seminar, Sep 20-22
Bill Baxter wrote: What kind of pre-reqs are necessary? Fluency with C, C++, D, C# or Java. Some experience with an assembler language or virtual machine bytecode is desirable.
Re: QtD 0.1 is out!
Frits van Bommel wrote: Walter Bright wrote: The problem if it detects it in an implementation-defined manner is the source code is no longer portable. ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error? Nothing, it's just that the compiler cannot prove it is an error.
Re: QtD 0.1 is out!
Jarrett Billingsley wrote: On Sun, Mar 1, 2009 at 10:16 AM, Don wrote: The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect. Yeah. Imagine if DMDFE were written in D; how big would those modules have to be? The current organization of DMDFE is totally inconducive to D's module system, which I find ironic.
Re: Compiler Construction seminar, Sep 20-22
On Sun, Mar 1, 2009 at 5:49 PM, Walter Bright wrote: > In Astoria, Oregon, on September 20-22 I'll be hosting a Compiler > Construction seminar along with Cristian Vlasceanu. > > http://www.astoriaseminar.com/compiler-construction.html > > It'll be a two day intensive course in how compilers work and how to build > them. What kind of pre-reqs are necessary? --bb
Re: QtD 0.1 is out!
On Sun, Mar 1, 2009 at 10:16 AM, Don wrote: > > The D system has a major limitation, though -- you can't split the source > for a module across multiple files. Which pushes you towards enormous source > files. It's more restricted than both C# and C++ in this respect. > Yeah. Imagine if DMDFE were written in D; how big would those modules have to be?
Re: QtD 0.1 is out!
Walter Bright wrote: Yigal Chripun wrote: this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly. D can do the same thing - it can use the source of the module directly, or it can use a hand-generated 'header' file, or an automatically generated 'header' file. The latter is semantically indistinguishable from compiling the source module to a "metadata" file. I originally considered having D write such a "metadata" file, until I realized I didn't have to invent a format and a writer and reader for that format. I could just use the D source code notation as a "metadata" file and reuse the existing code. The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect.
Re: QtD 0.1 is out!
Frits van Bommel wrote: Walter Bright wrote: Christopher Wright wrote: Walter Bright wrote: Christopher Wright wrote: Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug. No, it does not. The compiler doesn't know about private imports of separately compiled modules. Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement. The problem if it detects it in an implementation-defined manner is the source code is no longer portable. ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error? Right. It's like the compiler warning you if your program starts with "assert (false)".
Re: QtD 0.1 is out!
Walter Bright wrote: Christopher Wright wrote: Walter Bright wrote: Christopher Wright wrote: Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug. No, it does not. The compiler doesn't know about private imports of separately compiled modules. Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement. The problem if it detects it in an implementation-defined manner is the source code is no longer portable. ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error?
Re: Compiler Construction seminar, Sep 20-22
On Sun, 01 Mar 2009 22:19:27 +1300, Brad Roberts wrote: Daniel Keep wrote: Walter Bright wrote: In Astoria, Oregon, on September 20-22 I'll be hosting a Compiler Construction seminar along with Cristian Vlasceanu. http://www.astoriaseminar.com/compiler-construction.html It'll be a two day intensive course in how compilers work and how to build them. Curse you, Pacific ocean, CURSE YOU! -- Daniel Well, if you start swimming now... I dont think Walter has managed to include that into dmd yet so would probably be easier to have a live stream (video stream not water stream)
Re: Compiler Construction seminar, Sep 20-22
Daniel Keep wrote: > > Walter Bright wrote: >> In Astoria, Oregon, on September 20-22 I'll be hosting a Compiler >> Construction seminar along with Cristian Vlasceanu. >> >> http://www.astoriaseminar.com/compiler-construction.html >> >> It'll be a two day intensive course in how compilers work and how to >> build them. > > Curse you, Pacific ocean, CURSE YOU! > > -- Daniel Well, if you start swimming now...
Re: Compiler Construction seminar, Sep 20-22
Walter Bright wrote: > In Astoria, Oregon, on September 20-22 I'll be hosting a Compiler > Construction seminar along with Cristian Vlasceanu. > > http://www.astoriaseminar.com/compiler-construction.html > > It'll be a two day intensive course in how compilers work and how to > build them. Curse you, Pacific ocean, CURSE YOU! -- Daniel
Compiler Construction seminar, Sep 20-22
In Astoria, Oregon, on September 20-22 I'll be hosting a Compiler Construction seminar along with Cristian Vlasceanu. http://www.astoriaseminar.com/compiler-construction.html It'll be a two day intensive course in how compilers work and how to build them.
