Archive for September, 2007
Wednesday, September 12th, 2007
Don Clugston, the D community’s resident CTFE guru, has put his considerable talent to work in order to create a module which performs lexing, parsing, and semantic analysis on D expressions at compile-time. This is mind-boggling stuff. What’s more, he did it in under 300 lines of code. From the NG announcement:
contains one publicly usable function:
char [] syntaxtreeof(char [] expression).
When mixed in, this lexes and parses the expression, determines precedence and associativity, creating an object of type AbstractSyntaxTree, which contains a standardized ‘placeholder expression’ (eg “A+=(B*C)”)
and a symbol table for the variables, constants and functions A,B,C,…
The symbol table includes the type and value for each symbol.
All aliases and compile-time constants are resolved and converted to a standard form.
All symbols must be reachable from the scope where syntaxtreeof() is mixed into.
The created AbstractSyntaxTree is a compile-time constant, so it can be used for further compile-time operations and code generation.
Works for almost any expression (templates, functions, strings, slicing, struct literals,…); the biggest omission is relational operators.
And example usage:
import SyntaxTree;
const foo = “abc”;
int bar(real x, char [] s) { return 0; }
struct Duck{};
Duck duck;
AbstractSyntaxTree a = mixin(syntaxtreeof(`foo* bar(2.18_3242e+45L, “xyz”) in duck`));
I guess there’s a reason that the first letter in Don is ‘D’.
Technorati Tags: D Programming Language, compile time function execution
Posted in D Programming, News | No Comments »
Wednesday, September 12th, 2007
After Gregor stopped posting Rebuild binaries separately from DSSS, I downloaded the dsss-light version for Windows, which is DSSS without all of the net stuff. All I really wanted was access to the Rebuild executable without building it myself. I don’t care how they do it in the Linux world, I want my binaries without having to compile them first, thank you.
So I don’t really need, or want, DSSS to manage my libraries for me. I’ve got my own system that works just fine. That, actually, is one of the reasons I never bothered to use DSSS before nor wanted to use it when I downloaded it. I also didn’t like that it generated .di files for everything. Nor did I like the idea that I had to learn how to create dsss.conf files in order to make it do what I wanted with my own projects. I was quite happy with using the simple response files I use for Bud and Rebuild.
Recently, I came to realize that it would be a good idea to add a dsss.conf file to the Derelict trunk. Since more and more people are using Tango with Derelict, and since the provided build script cannot be run by DMD when using Tango (at least on Windows, it has to be compiled into an executable first), DSSS seemed like it could potentially be a solution to the problem. So it was time to buckle down and dig into dsss.conf files.
As it turns out, creating a dsss.conf file is not nearly as complicated as the docs make it seem (Gregor did say doc writing isn’t one of his strengths). It wasn’t long before I had DSSS doing my bidding and building all of the Derelict libraries. There are still a few nits to work out, like I’m fairly certain that the DerelictSDL stuff is being compiled into every single DerelictSDL* library. I’d prefer that not to happen, but I haven’t yet seen any obvious way to exclude entire packages (nor have I really dug around for one or asked Gregor). There’s also a bug with library names that Gregor has already fixed for the next release. So when Gregor does release the next version, Derelict will be getting a dsss.conf file.
My intent was to provide dsss.conf alongside buildme.d, so that people who prefer can still run the build script. Some time ago I had refactored it to allow support for multiple build tools. That idea has now gone the way of the dodo, so I streamlined it and cleaned it up a bit just to support bud only. But now, I’m thinking, do I really need the build script? Providing two different methods of building the same project could potentially lead to confusion. I get enough confusion from just the single build script as it is. The majority of Derelict users don’t bother reading the docs, judging by the majority of support requests I get in the forum. I may very well drop the build script and just require dsss if you want to build the libraries.
Today, I set some time aside to get started on the new, reinvented Smoothie. The first thing I would normally do is set up a couple of response files for Rebuild (or Bud as the case may be) for debug/release configurations. This time, I decided to go with a dsss.conf file instead. I still don’t like that it generates .di files (is there a way to turn that off?) or creates extra files that I don’t need, but it’s not a big deal. Besides, a ‘dsss distclean’ solves that problem.
Still, if that were all, I’d see no real reason to give up Rebuild for DSSS. The big things for me are the ability to set up multiple builds in a single config file and the variety of hooks and commands available. I tend to configure my projects in such a way that I often have multiple test apps set up in their own packages. Using Rebuild or Bud, I’d need to configure a separate response file for each app. Also, I can already see how some of the hooks are going to be very useful for setting up a complex build process that involves manipulating more than just D source files.
I’ve said before in a NG post that DSSS solves problems I don’t have. That’s true, to an extent, but I see now that there’s so much more to it than just library management and easy project compilation. To say I’ve warmed up to it is an understatement. I’ll be replacing the response files for my game, and any other projects I have lying around, with DSSS configuration files. Color me converted.
Technorati Tags: D Programming Language, DSSS
Posted in Derelict, Discussion | 3 Comments »
Wednesday, September 12th, 2007
Slow news day for D, but there’s a blog post over at hans-eric.com titled, D doesn’t have real closures. Hans-Eric talks about D’s delegates, how they are similar to closures, and how they aren’t quite real closures because they don’t keep surrounding variables alive after the scope has changed. His conclusion is that it’s not a big deal, but at least one commenter so far disagrees with him.
Personally, I don’t see it as a big deal either. For my purposes, I don’t really need true closures in D. I do like to see them implemented in scripting languages, though. They are very handy for game AI. Since Lua added closures, that has become one of its major selling points for game developers. If I do come across a case where a true closure would come in handy, I have no problem making use of an inner class instead. D just has so many other useful features, such as anonymous delegates and lazy evaluation (two among many), that not having true closures doesn’t bother me a bit.
Technorati Tags: D Programming Language, delegates, closures
Posted in D Programming, Discussion | No Comments »
Monday, September 10th, 2007
Now that I’m completely done (for real this time) with all of that nasty contract work and coming back to my D projects, I’m looking at Smoothie with a critical eye. I really don’t think my time is best spent on a 2D/3D game library right now. There are a few reasons to do so, but the bottom line is that working on Smoothie is distracting me from my game. I had thought to develop Smoothie as part of the game, so that the game would actually use the library, but I don’t need to be concerned with abstractions and use cases right now. I just need to knock my damn game code out. I’ve been fooling around too long with this game idea and it’s time to get the thing done and out the door. Besides, the ArcLib crew really does have the 2D lib department covered fairly well right now without me mucking about. Also, I’m back to trying to put together a graphics package for Tango, which is more than enough graphics work for me right now. Yet, I like the name Smoothie too much to throw it out.
As always, there is a long list of projects I would like to work on. So Smoothie is going to undergo a reinvention. Rather than being a 2D game library, it’s going to be something completely different, though still game related. I can work on it for a few hours each week without really distracting myself from the game. In fact, I think it will be the ideal project to take a break from the game, or tango.graphics, during those times when I’m banging my head on the desk trying to solve some problem.
I’ll talk more about the new Smoothie when I have something to show. I don’t want to jinx myself.
Technorati Tags: D Programming Language, Smoothie, game development, game libraries, game programming
Posted in Smoothie | 2 Comments »
Saturday, September 8th, 2007
Ary Manzana has released a small update for his Eclipse plugin. The comments in his NG post seem fairly important, so I’ve included most of his original post here:
These is a small release, but the first feature is the one I use most in JDT, so…:
- Added an Open Type dialog.
- Fixed a bug relating to Descent not showing the source code when debugging with gdb.
- The Build Path property page is back. This was removed in a previous release because it mainly has unimplemented features, but it has the “Source Folders” page which is in did useful.
Some notes:
- To bring up the Open Type dialog press Ctrl + T in an open editor (or go to Navigate -> Open Type…). There you can quickly open a type (class, interface, enum or template) by typing a substring of it’s name, or for example typing SE will return SelectionEvent, SmartEscape, etc. (the funcionality is similar to that of JDT). This only works in open D editors, unlike the Java’s one which works everywhere. The problem is that if I bind that combination to “everywhere” (window, actually), then both of them doesn’t work. In CDT this also only works in an open editor. (I think Eclipse is taking care of this problem)
We’ll consider also listing top-level functions. However, we don’t know what would be the most comfortable way to do it: in the same dialog or in another one? Also, should enums be listed? And templates?
Starting from this version, next time you want to update, you can do it from within Eclipse (you cannot do this now, though).
Note that I’ve also added a new IDE category to the blog, since there’s starting to be more IDE-related news coming out. I’ll be going through and updating all posts related to IDEs with the new tag when I can.
Technorati Tags: D Programming Language, Eclipse
Posted in IDE | No Comments »