Re: Static arrays size limit, int
On Thu, Nov 19, 2009 at 2:36 PM, bearophile bearophileh...@lycos.com wrote: I'd like a higher max size limit for static arrays: uint[10_000_000] arr; For the LDC compiler is a fully arbitrary limit, it can support higher values. I'd like ldc to be free to use a higher limit. Most/all PC CPUs operating systems are probably going to become 64 bit, but in D int values are 32 bit, so some years from now, when everything is 64 bit D programs will probably keep containing: int i; Unless D programmers will train themselves to nearly never use int and usually use: long i; that will be about as equally fast, but less probable to cause integral overflow. The choice of 32 bit as default int number in D may look bad few years from now. I don't see good solution. To me the best solution seems to use long everywhere in future programs fit for a 64 bit world (cent/ucent will be present, LLVM supports them already, so it's easy to add them to LDC). Bye, bearophile It's not really *easy* to add them to LDC, since they're not implemented in the frontend at all.
Re: Should we make DMD1.051 the recommended stable version?
On Wed, Nov 18, 2009 at 12:43 PM, Nick Sabalausky a...@a.a wrote: Denis Koroskin 2kor...@gmail.com wrote in message news:op.u3k8d9i9o7c...@dkoroskin.saber3d.local... On Wed, 18 Nov 2009 14:15:47 +0300, Nick Sabalausky a...@a.a wrote: Don nos...@nospam.com wrote in message news:he0d7l$34...@digitalmars.com... The standard download still points to DMD1.030 (May 2008). A couple of hundred serious bugs have been fixed since that time. Some of the intermediate releases had regressions which prevented many people from using them, but I don't think that's true of this one. I think it's a great release. The known regressions of DMD1.051 compared to DMD1.030 are: 2393 IFTI regression on (T:char)(T[]) vs (T:dchar)(T[]) 370 Compiler stack overflow on recursive typeof in function declaration. 3469 ICE(func.c): Regression. Calling non-template function as a template, from another module but in my opinion these are not serious enough to prevent 1.051 from being recommended. (BTW I've already sent Walter patches for those second two bugs). I'd like to protect newbies from encountering internal compiler errors which have already been fixed, and from experiencing frustration with CTFE. If anyone has a reason that they have to use 1.030 instead of 1.051, now would be a great time to say why. The only potential problem I see with that is that if you want to use tango, any DMD beyond 1.043 would force you to go with tango trunk, which wouldn't make much sense for anyone who is trying to stick with stable releases of things. Recent poll has shown that most people use Tango trunk anyway. Perhaps, it's time for another Tango release? I don't think anyone would disagree that it's long past time for another Tango release ;) But, I would venture to guess very few people stick with DMD stable either, probably even fewer than Tango 0.99.8. Heck, DMD's stable gets updated less often than Tango's stable releases. Personally, I don't see much of a reason for D1/Tango users not to use DMD 1.051 / Tango trunk, at least until Tango 0.99.9 comes out. But I just felt that for anyone who does want to stick with DMD's stable for whatever reason, it's likely they may want to stick with latest stable for Tango too. (Assuming, of course, that they want to use tango...not that that's a vary large assumption for a D1 user). It would also be possible to just release tango 0.99.8.1 (or something), LDC has a patch against 0.99.8 that probably fixes it for the latest dmd as well.
Re: Making alloca more safe
On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright newshou...@digitalmars.com wrote: Max Samukha wrote: On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright newshou...@digitalmars.com wrote: If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough. I have an example of such a software: http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html It loads third-party plugins into the host process's address space, an consequently it may fail at any moment. The software's design is not the best ever but it gives the user last chance to save his work in case of fatal error. This feature has saved my back a couple of times. I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away. P.S. I worked for Boeing for years on flight critical systems. Normally I eschew credentialism, but I feel very strongly about this issue and wish to point out that my knowledge on this is based on decades of real world experience by aviation companies who take this issue extremely seriously. Then, instead of sticking with Windows and the likes, you may want to think about porting dmd to a more serious environment specifically designed for developing such systems. What about a real-time microkernel OS like this one: http://www.qnx.com/products/neutrino_rtos/ ? dmd targets Windows because that's where probably half the programmers are. I'd certainly like to do embedded systems, too, but realistically that's going to be the purview of gdc or ldc. I'm not sure if LDC will ever support D2 (at least wont be by my hand)
Re: Making alloca more safe
On Tue, Nov 17, 2009 at 4:45 PM, dsimcha dsim...@yahoo.com wrote: == Quote from Tomas Lindquist Olsen (tomas.l.ol...@gmail.com)'s article I'm not sure if LDC will ever support D2 (at least wont be by my hand) What is it about D2 that makes this unlikely? I thought after LDC D1 support was stable and the D2 spec and front end were stable, the natural progression of things would be for LDC to support D2. LDC requires a lot of changes to the frontend. * DMD is not written as a cross compiler * The runtime interfaces are hardcoded into the frontend semantics * The ast rewrites dmd does are destructive and buggy * The dmd codegen is all over the frontend code, it wasn't meant to be used with another backend But most of all: someone has to do it. Keeping the two in sync is a major PITA, the original merge of our frontend changes, to the D2 frontend was done in a error prone way, which introduced a lot of bugs, codegen that worked in D1 still compiles, and generates code that compiles, but the code doesn't run. This requires time consuming debugging/reviewing and of course fixing. So most of all, like most of things D, it's about a lack of manpower. I personally no longer have the time to maintain LDC besides critical bugfixes now and then, and other devs are in similar situations. Another factor may be more ideological (or something), not everyone is happy about how D evolved, and who want to implement something they don't really care about ? -Tomas
Re: D2 front-end for LLVM (Was: Re: Making alloca more safe)
On Tue, Nov 17, 2009 at 5:58 PM, bearophile bearophileh...@lycos.com wrote: Tomas Lindquist Olsen: LDC requires a lot of changes to the frontend. * DMD is not written as a cross compiler * The runtime interfaces are hardcoded into the frontend semantics * The ast rewrites dmd does are destructive and buggy * The dmd codegen is all over the frontend code, it wasn't meant to be used with another backend LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some. Walter seems to be fairly rigid to work with. While the latest improvements, like DMD in a SVN repo, is a great step, I just don't have as much time for LDC as I used to, so the little difference it makes doesn't really help me that much. I agree it would be good with more developer documentation. But LDC is really not implemented very cleanly and writing such would be a huge amount of work. When I started on LDC I had no idea how DMD worked, and I made a lot of mistakes along the way. Now, since then, a lot of people have joined, and helped out. But it still suffers from some of the issues introduced very early. Another point is motivation. Personally, I've achieved what I originally planned for LDC, and quite a lot more. New projects await out there. Don't get me wrong. I *use* D (1.0 + Tango). And I need a x86-64 compatible D compiler, so I'm not abandoning LDC. But other people will have to step in for D2 support. Unless of course I somehow magically convert to liking D2. But I doubt that's going to happen. -Tomas P.S. LDC is an open source project, and while I started it, many other people now have write access to the repository. I'm not holding anyone back from making the changes needed for D2 support. And in case someone out there wants it, I'll be happy to give you access as well (after seeing a first patch).
Re: alignment on stack-allocated arrays/structs
On Tue, Nov 17, 2009 at 9:12 PM, Trass3r mrmoc...@gmx.de wrote: I originally posted a question about this in D.learn. bearophile advised me to ask for that feature here. Original post: == OpenCL requires all types to be naturally aligned. The D specs state: AlignAttribute is ignored when applied to declarations that are not struct members. Could there arise any problems translating the following /* * Vector types * * Note: OpenCL requires that all types be naturally aligned. * This means that vector types must be naturally aligned. * For example, a vector of four floats must be aligned to * a 16 byte boundary (calculated as 4 * the natural 4-byte * alignment of the float). The alignment qualifiers here * will only function properly if your compiler supports them * and if you don't actively work to defeat them. For example, * in order for a cl_float4 to be 16 byte aligned in a struct, * the start of the struct must itself be 16-byte aligned. * * Maintaining proper alignment is the user's responsibility. */ typedef double cl_double2[2] __attribute__((aligned(16))); typedef double cl_double4[4] __attribute__((aligned(32))); typedef double cl_double8[8] __attribute__((aligned(64))); typedef double cl_double16[16] __attribute__((aligned(128))); into just alias double[2] cl_double2; alias double[4] cl_double4; alias double[8] cl_double8; alias double[16] cl_double16; ? yep, D provides no way to do this, they'd all align to 4 bytes (at least on x86-32)
Re: Making alloca more safe
On Mon, Nov 16, 2009 at 9:48 PM, Walter Bright newshou...@digitalmars.com wrote: bearophile wrote: Walter Bright: I just wished to point out that it was not a *safety* issue. A safe system is not a program that switches itself off as soon as there's a small problem. Computers cannot know whether a problem is small or not. One Ariane missile has self-destroyed (and destroyed an extremely important scientific satellite it was carrying whose mission I miss still) because of this silly behaviour united with the inflexibility of the Ada language. A reliable system is a systems that keeps working correctly despite all. If this is not possible, in real life you usually want a good enough behaviour. For example, for your TAC medical machine, in Africa if the machine switches itself off at the minimal problem they force the machine to start again, because they don't have money for a 100% perfect fix. So for them it's better a machine that shows a slow and graceful degradation. That's a reliable system, something that looks more like your liver, that doesn't totally switch off as soon it has a small problem (killing you quickly). This is how you make reliable systems: You sure got all the answers...
Re: Metaprogramming in D : Some Real-world Examples
On Tue, Nov 10, 2009 at 1:27 AM, Bill Baxter wbax...@gmail.com wrote:
On Mon, Nov 9, 2009 at 4:09 PM, Walter Bright
newshou...@digitalmars.com wrote:
Looks like Bill Baxter is giving a presentation on D Nov. 18!
http://www.nwcpp.org/
Yep, that's right, and I'd be quite grateful to you smart folks here
if you could share your meta-programming favorites with me! If
you've got a real-world example of meta-programming in D that you
think is particularly handy, then please send it my way
I'm looking for small-but-useful things that are easy to explain, and
make something easier than it would be otherwise. Things like places
where static if can save your butt, or loop unrolling, and passing
code snippets to functions like in std.algorithm.
Things like a compile-time raytracer or regexp parser (though quite
cool!) are not what I'm after. Too involved for a short talk.
--bb
I think tuples are a good example of something that makes your life
easier, lately I've been very fond of this little snippet:
void delegate() Bind(Args...)(void delegate(Args) dg, Args args)
{
struct Closure
{
Args arguments;
void delegate(Args) callee;
void call()
{
callee(arguments);
}
}
auto c = new Closure;
// foreach not strictly necessary, but ldc currently chokes on
just an assignment... I should fix that..
foreach(i,a;args)
c.arguments[i] = a;
c.callee = dg;
return c.call;
}
class C
{
void foo(int,float) {}
}
void main()
{
auto c = new C;
auto dg = Bind(c.foo, 1, 2.0f);
// register delegate somewhere
}
Not sure if this gets easier in C++0x , haven't read up on that...
Nothing fancy, but it sure has made my life easier.
-Tomas
Re: No header files?
On Thu, Oct 22, 2009 at 11:50 AM, Yigal Chripun yigal...@gmail.com wrote: I think you misunderstood. the idea is *not* to replace .di header files with llvm bit-code files. the idea is to replace d object files lib files with a llvm bit-code equivalents which does not need additional header files. let's go over the list one more time: 1) i can't use obj files from different OSes or even different compilers on the same OS - so definitly *not* platform neutral 2) you need to parse a header file in addition to linking functions from the lib file, how is that better than having one file without needing to do any parsing of headers at all? 3) like Steve said, there is only one file so you don't get syncing problems between the header and the object file. the bit-code object file already contains all the required metadata and doesn't depend on a separate header file. 4)LLVM is already implemented and has all the required tools for its format. ldc for example can take advantage of this easily. This locks D to the LLVM backend, things like that is never a good idea. Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are platform specific. Sure you can process them on any platform, but the source code they were compiled from was platform specific, and so is the resulting bitcode. Using LLVM bitcode as a replacement format for native OMF/COFF/ELF objects, does not give us platform neutrality. -Tomas
Re: 64-bit
On Mon, Oct 19, 2009 at 10:26 PM, Nick Sabalausky a...@a.a wrote: Fawzi Mohamed fmoha...@mac.com wrote in message news:hbhi5q$1gq...@digitalmars.com... On 2009-10-18 20:01:26 +0200, language_fan f...@bar.com.invalid said: Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote: on x86 the 64 bit extension added registers, that makes it faster, even if as you correctly point out a priori just using 64 bit pointers is just a drawback unless you have lot of memory. That is very silly claim. First, you need to have use for all those extra registers to obtain any performance benefits. This is nearly not always the case. Probably you don't know x86 architecture well, it is register starved for modern standards, also with the 64 bit new instruction were added, on x86 the 64 bit change was not add 64-bit pointers but it was let's try to fix some major shortcomings of x86. These enhancements are available only in 64 bit mode (to keep backward compatibility). I know for a fact that my code runs faster in 64 bit mode (or you can say my compiler optimizes it better), and I am not the only one: for sure apple converted basically all its applications to 64 bit on snow leopard (that is focusing on speed), so that they are slower :P. I'll certainly agree with you on 64-bit x86 likely being faster than 32-bit, but Apple is bad example. Apple, at it's cor...erm...heart, is a hardware company. That's where they make their money. If software runs efficiently, then their newer hardware becomes a tougher sell (And Jobs himself has never been anything more than a salesman, only with far more control over his company than salesmen usually have). It's not surprising that for years, every version of iTunes has kept growing noticably more bloated than the last, despite having very little extra. It's interesting how Apple is doing a lot to better performance then. With things like OpenCL and LLVM.
Re: dmd support for IDEs and the D tool chain
On Fri, Oct 16, 2009 at 12:06 PM, Jacob Carlborg d...@me.com wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. What we have now and what I think is the closest match: Compiler: LDC * Missing most of the mentioned things * Needs better platform support * At least the back-end is built like this We have DSSS and xfbuilder (or what it's called) GUI library: DWT * There are some bugs in the mac version * Doesn't support (de)serializing controls * Not built in a D-way * Maybe too heavy IDE: Descent * Missing some features like refactoring * Only supports building using an external tool * Needs to improve the syntax and semantic errors * Needs to improve the performance if possible GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses * To my knowledge none of the above supports a GUI library like the one mentioned Any comments, thoughts? /Jacob Carlborg GtkD supports Glade.
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?
On Sat, Oct 3, 2009 at 2:55 PM, Denis Koroskin 2kor...@gmail.com wrote: I'm currently writing a program that interfaces with C++. C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or just 'unsigned', but is mangled differently. In particular, C++ mangles unsigned long as 'K', and I can't find a D counterpart that would be mangled similarly. This results in an unaccessible function (it is unresolved at link time). Any thoughts? The type of C++ unsigned long depends on the target platform.
Re: Developing a plan for D2.0: Getting everything on the table
On Tue, Jul 14, 2009 at 11:12 PM, Bill Baxterwbax...@gmail.com wrote: On Tue, Jul 14, 2009 at 1:37 PM, bearophilebearophileh...@lycos.com wrote: Robert Clipsham: But LLVM offers many interesting things that are hard to do with DMD's back-end, often such things are already implemented in LLVM (maybe not fully refined yet, but they are working on it) and they are waiting to be used. I'm looking at the linker too, for example with LDC you can do advanced Link-time optimizations, and in future it will probably be able to do even more things (like reducing code bloat produced by templates). On the other hand few things done by DMD are hard to do with LLVM. Except for generating exceptions on Windows, apparently. LLVM is getting better support for SJLJ exception handling. This would get us to the same point GCC is at. I think the bigger problem is lack of documentation on SEH and the runtime support Windows provides for it. There has even been some mailing list threads about it on LLVMDev recently... I think the best solution will be to use Dwarf on Windows eventually as well (which also seems to be the route GCC is going). I'm not sure how Walter figured these things out ? I agree with you generally though. --bb
Re: Conditional compilation inside asm and enum declarations
On Wed, Jul 15, 2009 at 2:18 AM, Walter
Brightnewshou...@digitalmars.com wrote:
Don wrote:
In this case you may have a long function, with only a single instruction
right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
}
asm
{
... even more instructions ...
mov EAX,EAX;
}
}
Since when does D guarantee that no code is inserted before/after asm blocks?
Re: Conditional compilation inside asm and enum declarations
On Wed, Jul 15, 2009 at 12:24 PM, Daniel
Keepdaniel.keep.li...@gmail.com wrote:
Tomas Lindquist Olsen wrote:
On Wed, Jul 15, 2009 at 2:18 AM, Walter
Brightnewshou...@digitalmars.com wrote:
Don wrote:
In this case you may have a long function, with only a single instruction
right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
}
asm
{
... even more instructions ...
mov EAX,EAX;
}
}
Since when does D guarantee that no code is inserted before/after asm blocks?
I think it was around the time that the mail service guaranteed that
they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.
Funny.
But seriously, it actually takes some effort to make sure all
successive asm statements are merged into a single asm block when
generating code for LLVM.
The DMD frontend unpacks asm blocks, so each line is a seperate
AsmStatement, and with version blocks, you have to look into blocks as
well.
LLVM will restore registers etc. when an asm block is done!
And besides this is not in the spec, it might be implied, somehow, but
it's not in the spec.
Re: Conditional compilation inside asm and enum declarations
On Mon, Jul 13, 2009 at 8:24 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Julian Salazar wrote:
Hi, I'm new here to the community but I've been using D for a while now,
and I have to say that it's a great programming language. I'd like to get
involved in this community and help shape this language.
Welcome!
I'm just wondering about a minor issue: why are conditional blocks invalid
within expressions such as enum and asm? I mean, in trivial cases it's fine,
but in instances where code duplication is a big maintainability nightmare,
making conditional compilation more flexible would have benefits for
developers.
The request to do it for enums has been thrashed about before. Essentially,
version works at the declaration and statement level, not at the expression
level or in between tokens, etc. The reason for this is to encourage a more
modular approach to versioning than the typical C method of doing it at the
lowest level.
Something like (I know it's a trivial example, but you get the point):
asm {
version(x86) mov EAX, 1;
else version(x86_64) mov EAX, 2;
}
would trigger an error. Also, though I know enum qualifies as a
constant/datatype cross, structs and classes are perfectly fine with
conditional compilation. Couldn't the lexical stuff be changed to support it
for enum and asm as well?
Let me illustrate by a current example. The linker (optlink) is written 100%
in assembler. This makes it rather intractable. It's also loaded up with
line-by-line nested conditional assembly (and a lot of macros). It's so hard
to see what is *actually* being compiled that I'll assemble it, run OBJ2ASM
on the output, and work off of the disassembled code.
So, in essence, the idea is to push conditional compilation to higher
levels, not lower levels. Ideally, versioning would be done by abstracting
all the version differences into an interface implemented by different
modules.
Also, I noticed that there is no formal specification page for x86-64
inline assembly. You define a predefined version identifier such as
D_InlineAsm_X86_64, but you don't define registers and instructions
pertaining to it. In GDC for example, using the RAX register in the D inline
ASM syntax is invalid. Not sure what the case is in LDC (they probably do
implement it for x86-64), and I know DMD does not have a 64-bit version, but
the spec should at least have a definition for compilers that do implement
64-bit support.
The first approximation to the definition is to use the Intel asm syntax as
outlined in their processor data sheets. I haven't written a spec more
detailed than that because it's a lot of work and I'm lazy, and such work is
not terribly exciting. But if you'd like to help with that, I'd welcome it.
LDC implements x86-64 inline asm just like x86-32 inline asm, that is
the syntax is the same, and the only real difference is the new 64bit
registers and opcodes.
Of course a spec would be nice, but they're really so similar that it
might well be a single page if you ask me.
Re: Source control for all dmd source
On Fri, May 29, 2009 at 4:52 PM, Frits van Bommel fvbom...@remwovexcapss.nl wrote: Sean Kelly wrote: Jason House wrote: Over in D.anounce, the LDC devs said they would have an easier time upgrading to newer dmd (fe) versions if the source was in source control. Even if Walter is the only one with write access, it's still be helpful. It's helpful for more than just the LDC folks; that's just the most recent example. It would be nice to have DMD in version control, but I don't buy the LDC argument. It's trivial to diff one release against another, regardless of whether version control is involved. It's probably just easier what a change is for[1] if it's small and self-contained, with a description (commit message) of what it's supposed to do. But that's just a guess, you'd have to ask Thomas Lindquist since he's the one that usually merges new frontend versions. [1]: And thus what to do in case of conflicts, as well as what may need to change in the backend (if anything). Yes... the DMD frontend is poorly documented, and small self-contained commits (with meaningful commit messages) would be a great way to learn a little more, even if just about how Walter does his coding. In the end there's a lot more to it than just version control. What I'd really like to see is the DMD frontend made into a proper opensource project. I don't care about the backend. It's personal use only. But right now you have to remove a lot of code to get down to the part you want, the frontend. Imagine if LDC was just a backend module that you could use pretty much out-of-the-box with the official DMD frontend source tree !! I've worked with a few smaller open source project communities, and it's just a much nicer way to work than what we have with DMD right now. With version control, DMD will feel more like an open source project. -Tomas
Re: QtD 0.2 release announcement.
On Fri, May 29, 2009 at 12:44 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Eldar Insadutdinov Wrote: Another release of QtD is out. This time, it's Linux-only because OPTLINK refuses to link the project with debug info on Windows (see bug http://d.puremagic.com/issues/show_bug.cgi?id=2436). If anybody wants QtD on Windows, please keep pushing Walter until he does something with OPTLINK (bury it). Voting for the bug may help, too. I would repeat once again the request, that was raised here numerous of times, Walter, please change object file format, for me the ones used by MSVC or MinGW would be just fine. In this release: * Lots of bugfixes * Switched to Qt 4.5 * ldc supported (for both X86 and X86-64) * All imports inside Qt are now public to avoid import hell * Implemented API dealing with containers * All classes from Gui, OpenGL, Xml, Svg, Network and Webkit packages are wrapped * Build system is now based on CMake to be crossplatform and more flexible * New signals and slots implementation (pretty limited but we are working on a better one, which will support queued connections, connections by name at runtime, etc). * Ported duic, the tool for generating code out of xml representation * Ported drcc, the resources compiler Thanks to everyone involved in the project. So apparently I made it working on Windows as well. The thing that solved the problem was to feed source files to the compiler in the different order. Is it a correct behaviour? The DMD frontend has quite a few order dependencies. It's not correct behaviour, but a result of how it does semantics.
Re: QtD 0.2 release announcement.
On Fri, May 29, 2009 at 11:57 AM, Denis Koroskin 2kor...@gmail.com wrote: On Fri, 29 May 2009 13:54:58 +0400, Tomas Lindquist Olsen tomas.l.ol...@gmail.com wrote: On Fri, May 29, 2009 at 12:44 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Eldar Insadutdinov Wrote: Another release of QtD is out. This time, it's Linux-only because OPTLINK refuses to link the project with debug info on Windows (see bug http://d.puremagic.com/issues/show_bug.cgi?id=2436). If anybody wants QtD on Windows, please keep pushing Walter until he does something with OPTLINK (bury it). Voting for the bug may help, too. I would repeat once again the request, that was raised here numerous of times, Walter, please change object file format, for me the ones used by MSVC or MinGW would be just fine. In this release: * Lots of bugfixes * Switched to Qt 4.5 * ldc supported (for both X86 and X86-64) * All imports inside Qt are now public to avoid import hell * Implemented API dealing with containers * All classes from Gui, OpenGL, Xml, Svg, Network and Webkit packages are wrapped * Build system is now based on CMake to be crossplatform and more flexible * New signals and slots implementation (pretty limited but we are working on a better one, which will support queued connections, connections by name at runtime, etc). * Ported duic, the tool for generating code out of xml representation * Ported drcc, the resources compiler Thanks to everyone involved in the project. So apparently I made it working on Windows as well. The thing that solved the problem was to feed source files to the compiler in the different order. Is it a correct behaviour? The DMD frontend has quite a few order dependencies. It's not correct behaviour, but a result of how it does semantics. Is it fixable, or a new frontend is required? Of course it's fixable :) But how much work it is, that's the real question ...
Re: QtD 0.2 release announcement.
On Fri, May 29, 2009 at 12:22 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Tomas Lindquist Olsen Wrote: On Fri, May 29, 2009 at 12:44 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Eldar Insadutdinov Wrote: Another release of QtD is out. This time, it's Linux-only because OPTLINK refuses to link the project with debug info on Windows (see bug http://d.puremagic.com/issues/show_bug.cgi?id=2436). If anybody wants QtD on Windows, please keep pushing Walter until he does something with OPTLINK (bury it). Voting for the bug may help, too. I would repeat once again the request, that was raised here numerous of times, Walter, please change object file format, for me the ones used by MSVC or MinGW would be just fine. In this release: * Lots of bugfixes * Switched to Qt 4.5 * ldc supported (for both X86 and X86-64) * All imports inside Qt are now public to avoid import hell * Implemented API dealing with containers * All classes from Gui, OpenGL, Xml, Svg, Network and Webkit packages are wrapped * Build system is now based on CMake to be crossplatform and more flexible * New signals and slots implementation (pretty limited but we are working on a better one, which will support queued connections, connections by name at runtime, etc). * Ported duic, the tool for generating code out of xml representation * Ported drcc, the resources compiler Thanks to everyone involved in the project. So apparently I made it working on Windows as well. The thing that solved the problem was to feed source files to the compiler in the different order. Is it a correct behaviour? The DMD frontend has quite a few order dependencies. It's not correct behaviour, but a result of how it does semantics. Why is it working on linux then? With both ldc and dmd? I can't answer that, it's entirely possible it's a whole other issue. However, it could be that a version block is pulling in some trouble code, that is otherwise skipped on other platforms than windows. In the end you should really construct a test case to get it fixed.
Re: Finalizing D2
On Sat, May 23, 2009 at 7:25 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Jason House wrote: Andrei Alexandrescu Wrote: Jason House wrote: BCS wrote: Hello Jason, Should the final freezing of D2 be delayed until major D1 libraries port to D2? I'm mostly thinking of Tango, but I bet there are others. It may even be good if major libraries could use a Phobos-compatible license and become part of the releases by digital mars. Maybe it should be declared done as in it's got everything that Walter, Andrei, Barotsz and friends what in it, but it might be changed if the Lib writers as for some tweaks. Sort of a feature freaze. Yes! Walter, Andrei, Bartosz, and friends: If you're reading this, can you shed some light on what's happening before D2 is declared stable? And when? I've submitted the first three chapters to Rough Cuts. I will make progress towards writing up until the end of August. The last chapter concerns concurrency and is the fuzziest one. Ok, so pen down in three months? Yah. Thank you for your initiative to enlist help from the community. There's a lot of very visible help already happening: there's been a sharp increase in bug reports and patches recently. Walter and I are still scratching our head over that (it's not like dmd got much crappier overnight). I can only infer that more people have started using more of D. The increase is interesting. Out of curiosity, is the increase dominantly for the backend? I wonder if having a sense of D2 stabilizing is increasing usage of D2 overall. Walter has no specific statistics. I'd be thrilled to add more stuff to Phobos. Stuff can be done with ranges that's almost indistinguishable from poetry. But ranges aren't everything, Georg :o). I think Shin's BlackHole and WhiteHole slammed open a door to a world of amazing possibilities. Things like compile-time reflection, run-time reflection, and dynamic loading are very hot and the possibilities are huge. Among other things, Variant can with relative ease implement a function var.call(fun, arg1, arg2) that forwards everything dynamically to a member function of the embedded object. What do you / others consider the weakest / missing parts of Phobos? Wow. Where should I start. Let me go down the list of modules and share a few thoughts. * std.array: we need to make a decision about differentiating arrays from slices. * std.base64: doesn't deserve a separate module * std.bind: eliminate? * std.bitmanip: define a range for BitArray and eliminate opApply. Add opSlice. * std.vendor: should this go in core? * std.complex: IMPLEMENT. Eliminate any trace of built-in complex. How do you plan to handle ABI compatibility with C if complex becomes a library type? Drop it? * std.conv: define operations to stream data out and in in binary and text formats. * std.cover: another little module that should be merged somewhere * std.date: unnecessarily clunky and low-level. Also, somehow Walter thinks that std.dateparse has absolutely nothing to do with date. * std.demangle: another small module. Should be merged with e.g. other compiler-specific stuff. * std.encoding, std.utf: we need a massive overhaul of all encoding-specific stuff. Massive. Epic. The current pile of... functionality makes the simplest stuff look like rocket surgery. * std.md5: we should add more such encryption devices. * std.metastrings: I hate the name. Merge into std.string using ctfe * std.mmfile: integrate with the garbage collector. It should be there. * std.outbuffer: I think this shouldn't be a class and shouldn't have that name. * std.outofmemory: why??? * std.process: add pipe() for Windows. Actually that should be in stdio. * std.regex, std.regexp: merge and finalize. * std.signals: I don't know much. A review wouldn't hurt. * std.socket, std.socketstream: We need a real networking library. * std.stdio: implement readf and various I/O specific ranges * std.cstream, std.stream: eliminate. * std.string: arrange so there's no overlapping/conflict with std.algorithm. Implement bidir range for reading strings correctly (already done that). * std.system: merge somewhere * std.thread: replace * std.variant: add dynamic method invocation capabilities * std.xml: replace with something that moves faster than molasses. * std.zip: rewrite Well there's much other stuff I'm sure but I just dumped what came to mind when taking a look. Andrei
Re: Taunting
On Fri, May 22, 2009 at 1:40 AM, Ary Borenszweig a...@esperanto.org.ar wrote: http://www.youtube.com/watch?v=rtYCFVPfx4M Pretty cool feature :)
Re: dmd 1.045 / 2.030 release
On Tue, May 12, 2009 at 6:19 PM, Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net wrote: Tomas Lindquist Olsen Wrote: Is there a reason for the missing announcement ? http://digitalmars.com/d/1.0/changelog.html#new1_045 http://www.digitalmars.com/d/2.0/changelog.html#new2_030 and what happened to 1.044 ? -Tomas Walter usuallly updates the changelog pages just before the actual release. Expect the announcement shortly, if you haven't already ruined the surprise! But it says May 11th... That's yesterday! And thanks, Walter, for another big release with lots of bug fixes and improvements. Paul And what happened to the D1 stability stance ? 1.045 is a breaking release (both code and binary)! I don't mind, but I'm very surprised.. -Tomas
Re: dmd 1.045 / 2.030 release
On Tue, May 12, 2009 at 6:40 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: Is there a reason for the missing announcement ? Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it. I do apologize if I made a lot of people download a broken DMD release, but ... Some people watch the changelog, so if you don't want to release to be public, don't update the site! -Tomas
Re: dmd 1.045 / 2.030 release
On Tue, May 12, 2009 at 6:40 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: Is there a reason for the missing announcement ? Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it. I do apologize if I made a lot of people download a broken DMD release, but ... Some people watch the changelog, so if you don't want to release to be public, don't update the site! -Tomas
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Tue, May 12, 2009 at 2:26 AM, Walter Bright newshou...@digitalmars.com wrote: Is this a good idea? I think it's a great idea, there's some decent arguments that they should have more general names, but I like the idea that you'd always know which group to look in for specific issues, even when we're at D4! vote +1 !
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Tue, May 12, 2009 at 7:38 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: I think it's a great idea, there's some decent arguments that they should have more general names, but I like the idea that you'd always know which group to look in for specific issues, even when we're at D4! I do have reservations about the idea, based on experience with all the Digital Mars C++ newsgroups. There are too many, making for rather thin traffic. It's tedious to check them all for new postings, which means that that doesn't happen, and new postings often languish as a result. The main D n.g. gets a lot of action, which feeds on itself. I'm reluctant to mess with success. It's a good point... I still don't think it's a bad idea, but I can see your reason to be reluctant perfectly well. However, why propose it if you don't like the idea in the first place ?
Re: When will D1 be finished?
2009/5/12 Luís Marques luismarq...@gmail.com: Walter Bright wrote: D1 regularly gets around 20 bug fixes a month. I don't understand why this is not seen as progress to a stable state. About 80% of bug fixes are common to both D2 and D1. I think my perception (and I accept it may be a perception which does not reflect reality at large) comes from issues like the following. It's not a particularly important issue, but it's one for which I could find a bug report. Two years ago, I tried to use a particular construct and DMD incorrectly detected that a statement was not reachable [1]. OK, D1 had been frozen earlier that year, so I thought it would be only a matter of time until the higher priority stuff had been taken care of and someone took care of this issue. That's my experience with stable languages, even if they aren't particularly mainstream (say, Lua). Two years later I see this issue is still lingering. My perception is that unless I nag someone or send a fix myself no one will take care of it anytime soon. I guess they just have a huge pile of more important stuff, which is fair. But, 1) how long do you perceive it will take until more pressing matters delay fixing these kinds of bugs? I don't know if 20 bug fixes a month is enough or not to have DMD v1 rock solid in the next 5 years. Are most of the fixes for new bug reports? Is the list of old bugs being cleaned at a good rate? My perception, I said, was that the rate was a bit disapointing (compared with my experience using other language implementations) 2) Even if most bug fixes are common to D1 and D2, isn't it still true that if D2 is being discussed, elaborated, documented and implemented, most of those activities do not fix bugs and take time away from making D1 / DMD v1 stable and with few bugs? Some say send a patch. I'll try, when that is possible. But I can't send a patch for every bug I find in my spreadsheet software, browser, programming language, IM client, etc. That means that much of the software I use I have to accept it as is. That applies to everyone which uses a large amount of software and is not a programming demigod. I think this is pretty spot on. The point is not that D1 isn't getting bugfixes, it's which bugs are actually fixed. I realise I've done my part of the whining now and in the past, something I'm going to try and change (by fixing bugs myself and sending patches), but ... I don't know anyone who tried out D seriously who haven't found some near-deal-breaking bug (most of the time already reported), which requires them to implement workarounds that often make some otherwise neat (and according to spec, value) design impossible. It's a huge demotivator. -Tomas P.S. I know we can vote for issues now, that's a really good development and has helped already, but the situation is still not perfect.
Re: When will D1 be finished?
On Tue, May 12, 2009 at 2:52 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Tue, May 12, 2009 at 8:26 AM, Tomas Lindquist Olsen tomas.l.ol...@gmail.com wrote: P.S. I know we can vote for issues now, that's a really good development and has helped already, but the situation is still not perfect. I know. How many months has bug 314* had the most votes? And 313 while we're at it. Importing has been broken for years and instead D2 is getting thread-local variables. It seems like a gross misdirection of effort. *http://d.puremagic.com/issues/show_bug.cgi?id=314 Especially since Christian's patch has been in there for over a year - almost as long as it has been applied to LDC, where it still hasn't caused a false positive, only caught bugs!
Re: Bugzilla Downtime
On Sun, May 10, 2009 at 2:53 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Sun, May 10, 2009 at 7:37 AM, Nick Sabalausky a...@a.a wrote: Whooo, it's very pretty :) Indeed it is! Save for an apparent rendering problem with Firefox: http://d.puremagic.com/issues/show_bug.cgi?id=2959 Anyone else notice this? Yup!
Re: Bugzilla Downtime
On Sun, May 10, 2009 at 7:06 PM, Brad Roberts bra...@puremagic.com wrote: Sean Kelly wrote: Jarrett Billingsley wrote: On Sun, May 10, 2009 at 7:37 AM, Nick Sabalausky a...@a.a wrote: Whooo, it's very pretty :) Indeed it is! Save for an apparent rendering problem with Firefox: http://d.puremagic.com/issues/show_bug.cgi?id=2959 Anyone else notice this? It's kind of a mess on Safari. I'll file a report :-) I don't see that problem at all using windows firefox 3.0.10. I suggest flushing your cache.. make sure you've got current .css files. You're right, a proper reload fixed it ! :) Later, Brad
Re: What's the current state of D?
On Fri, May 8, 2009 at 8:56 PM, Walter Bright newshou...@digitalmars.com wrote: Steve Teale wrote: I am not criticizing you. I think you are doing a great job under the pressure of a slew of suggestions. But maybe a line in the sand at some point? But there *is* a line in the sand - D1. OK so for those who crave stability there is D1.x, but when all the focus appears to be on D2, what level of confidence is afforded to D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time? This just makes me very frustrated. Every fix going into D2 that also applies to D1 has been folded into D1. There are even some fixes that only apply to D1 that only go into D1. These average about 20 per month. D1 even got the FreeBSD port before D2. What other language gets that kind of support? A lot of good points have been brought forward in this thread. To me the big problem with D1 is that we *still* don't have a conforming (what does that even mean with D) compiler. Yes I'm thinking forward reference problems and such. Sure, these are hard problems to fix in the compiler, at least at this point. It's something that should have been fixed immediately when the first bug report came in. From my work on LDC I've seen a lot of the DMD frontend source code, its glitches, but of course also those wow, that's neat moments. However, one thing is very certain, it has some horrible problems with order-of-things issues, which the spec says should not matter. I'm talking about forward references, differing semantic trees depending on the order of declarations, imports etc. even the order in which modules are passed on the command line can affect the resulting semantic trees (yes I mean AST, but DMD has no distinction, it rewrites the AST happily until it thinks the result is sane). The main feeling I've come to settle on during the soon two years I've spent with LDC, is: we need a new frontend! D1 and D2 both have these problems, and they're not going away by themselves. -Tomas
Re: What's the current state of D?
On Sun, May 10, 2009 at 12:05 AM, mpt m...@ikikiki.fi wrote: I keep making 2 mistakes in my D programs, and fixing them feels troublesome. 1. Null references. I get a segfault and gdb is useless (ldc thing maybe). Useless how? Generally LDC debug info should be decent. If not, we'd be glad to look into why that is! 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing the real cause of error. Shouldn't there be an automatic null check for references and stack traces? Sometimes I think I'm using the wrong tool as others have solutions for these.
Re: Google Android
On Thu, Apr 30, 2009 at 11:29 AM, Georg Wrede georg.wr...@iki.fi wrote: Tomas Lindquist Olsen wrote: 2009/4/29 Robert Fraser fraseroftheni...@gmail.com: Weed wrote: Is it possible to implement support for Google Android on the D? Perhaps, but it'd be easier to implement support for D on the Google Android :-). LDC might be able to generate .class files, which can be run through the Android thingy to get them into a format gor which Google doesn't have to pay Sun. The trick would be integrating D and Java's GCs. You can probably already get a *very* simple program which doesn't use the D runtime working by using LDC to generate a .bc, using the LLVM JVM backend to write out a .class file and run it through the google thing. Not sure if anyone's tried it, though. According to wikipedia ( http://en.wikipedia.org/wiki/Google_Android ) it should be possible to run native ARM code, even though it's not officially supported by google. It's probably possible to get a full D implementation, but someone would just have to fix Tango on ARM ;) I'd just hate to create statically linked programs on a small machine. Feels like a massive waste of space. Typically I'd think the apps would be less than a thousand lines of code, and already having several tens of such binaries could either take a small or a huge amount of memory. LDC has supported shared libs (including a shared runtime) for quite a while, of course I'm not sure about the state of PIC codegen in LLVM's ARM backend, but I'd guess it's working.
Re: Google Android
2009/4/29 Robert Fraser fraseroftheni...@gmail.com: Weed wrote: Is it possible to implement support for Google Android on the D? Perhaps, but it'd be easier to implement support for D on the Google Android :-). LDC might be able to generate .class files, which can be run through the Android thingy to get them into a format gor which Google doesn't have to pay Sun. The trick would be integrating D and Java's GCs. You can probably already get a *very* simple program which doesn't use the D runtime working by using LDC to generate a .bc, using the LLVM JVM backend to write out a .class file and run it through the google thing. Not sure if anyone's tried it, though. According to wikipedia ( http://en.wikipedia.org/wiki/Google_Android ) it should be possible to run native ARM code, even though it's not officially supported by google. It's probably possible to get a full D implementation, but someone would just have to fix Tango on ARM ;)
Re: struct vs. class, int vs. char.
On Tue, Apr 28, 2009 at 6:07 PM, MLT n...@anon.com wrote: 2. char[] vs. int[] I think it is strange that char[] x = 1234 ; x[0] = '4' ; Produces a run time error, but int[] x = [1,2,3,4] ; x[0] = 4 ; Doesn't. I think that they both should, or both shouldn't - to be consistent (and it would be better if they both didn't). Best would be again, to allow the programmer to specify where the array (or other stuff) should be stored. It pretty much boils down to this (mostly said in other replies) * string literals are special, they are allocated in a static data segment, readonly if the platform allows it. * arrayliterals as non-static expressions are always heap allocated. even when there's absolute no need for it... (see http://d.puremagic.com/issues/show_bug.cgi?id=2356 ) -Tomas
Re: dmd 2.029 release
On Thu, Apr 23, 2009 at 2:37 PM, Don nos...@nospam.com wrote: bearophile wrote: Don: I really don't understand the backend. It's quite cryptic. Key acronyms are AE, CP and VBE. Then there's Bin, Bgen, Bkill, etc. AE *might* be Available Expression (but what does that mean?) CP might be Copy Propagation info I've found that VBE = Very Busy Expression! (what does that mean?) I suggest to add comments to the DMD source code every time a small mystery is revealed, to rename the files once a much better name is found, to improve and refactor the code every time it a good thing to do it. Every time you put your hand in the code you can improve the code locally and leave it better then before (this is the Scout principle in programming). Then such patches/changes can be slowly folded back into DMD and with time the sources will improve and will become more readable. Once they can be understood better, further changes become faster and simpler. I'd love to do that, but unfortunately it's not easy to get _any_ changes into DMD. Only Walter has write-access to it, and AFAIK he checks every line and enters it manually. Like Linus was famous for doing with the Linux kernel. Glad to hear I'm not the only one with that impression...
Re: dmd 2.029 release
On Mon, Apr 20, 2009 at 2:47 PM, Saaa em...@needmail.com wrote: Using D1 feels especially retarded today :( Why retarded ?
Re: dmd 1.043 alpha for FreeBSD 7.1
On Fri, Apr 17, 2009 at 5:38 AM, Walter Bright newshou...@digitalmars.com wrote: Frits van Bommel wrote: Walter Bright wrote: Anders Bergh wrote: You could probably make dmd run on some GNU/Darwin, but it's sort of dead. There's http://www.puredarwin.org/ but I'm not sure if it actually works yet. The iPhone is an ARM platform so dmd would certainly not work there... If dmd/phobos binaries for osx won't work on those machines, then it's appropriate to have a different version identifier. So you're saying version(linux) shouldn't be defined on PPC or ARM Linux systems? After all, dmd/phobos binaries for Linux won't run on them... (I agree with BCS; the test should be source code compatibility) I meant if they were running on an x86 yet the binaries are different. Isn't there powerpc osx as well ?
Re: dmd 1.043 alpha for FreeBSD 7.1
On Fri, Apr 17, 2009 at 8:10 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: Isn't there powerpc osx as well ? Such should get OSX predefined as well as whatever is appropriate to identify the powerpc (X86 is predefined for 32 bit x86, X86_64 for 64 bit x86). I'm aware of this. I was more wondering what system/logic you're using to decide these things... ! (sry, but it's a small - yet important detail it seems)
Re: dmd 1.043 alpha for FreeBSD 7.1
On Thu, Apr 16, 2009 at 1:08 AM, Jordan Miner jminer2...@nospam.students.pcci.edu wrote: Walter Bright Wrote: Because gcc on linux predefines linux, not Linux. Please change the version identifier from linux to Linux. I realise I probably did my part to spike this discussion. However, given the complaints Walter got from adding the Posix identifier, removing linux is obviously a really bad idea. But I must say I think Linux should be added, and linux be there for legacy reasons, like darwin I guess. -Tomas
Re: dmd 1.043 alpha for FreeBSD 7.1
On Tue, Apr 14, 2009 at 7:29 PM, Lars Ivar Igesund larsi...@igesund.net wrote: Walter Bright wrote: Now works for FreeBSD 7.1! Nice! But is there a particularly good reason for disregarding version identifiers already established by gdc and ldc? freebsd vs FreeBSD, darwin vs OSX And if not, why is there no Linux ? This is the obvious reason for GDC/LDC pick the lowercase identifiers in the first place ...
Re: dmd 1.043 alpha for FreeBSD 7.1
On Tue, Apr 14, 2009 at 9:49 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: And if not, why is there no Linux ? This is the obvious reason for GDC/LDC pick the lowercase identifiers in the first place ... Because gcc on linux predefines linux, not Linux. It seems somewhat arbitrary, but fair enough..
Re: dmd 1.043 alpha for FreeBSD 7.1
On Tue, Apr 14, 2009 at 11:51 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: On Tue, Apr 14, 2009 at 9:49 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: And if not, why is there no Linux ? This is the obvious reason for GDC/LDC pick the lowercase identifiers in the first place ... Because gcc on linux predefines linux, not Linux. It seems somewhat arbitrary, but fair enough.. It's just one less thing to remember when switching between C and D. After reading more, I just can't help but feel this is wrong. linux is still the only version identifier following this logic. Comparing http://predef.sourceforge.net/preos.html and D: linux - linux _WIN32 - Win32 _WIN64 - Win64 __FreeBSD__ - FreeBSD __APPLE__ or __MACH__ - OSX Even if you strip underscores, OSX and Win32/64 still don't match C/C++ identifiers. Why should linux be special? I realise this is a minor thing probably not worth the time it gets, but D seems to have a tendency to throw in inconsistencies in every crack there is to find ...
Re: Objective-D, reflective programming, dynamic typing
On Fri, Apr 3, 2009 at 5:20 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Jarrett Billingsley wrote:
On Fri, Apr 3, 2009 at 10:38 AM, Eljay el...@adobe.com wrote:
Alas, I'm not sure how to pass the variadic arguments through to another
variadic function, with this
signature:
void perform(...)
You can't. D's varargs suck.
Of course you can. Where did that come from?
void foo(T...)(T args) { bar(args); }
void bar(T...)(T args) { foreach (a; args) writeln(a); }
void main()
{
foo(3, 4.5);
}
prints:
3
4.5
Andrei
That's not a D vararg, it's a variadic template!
I've made proposals to allow this properly (without templates) before
so I'm not going to waste time on that again...
It's a silly limitation IMHO.
Re: Shouldn't __traits return Tuples?
On Mon, Mar 30, 2009 at 5:11 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Mon, Mar 30, 2009 at 10:57 AM, Max Samukha samu...@voliacable.com.removethis wrote: Also the following doesn't work with dmd, returns 0 for all members: Base base = new Base; auto members = __traits(allMembers, typeof(base)); foreach(m; members) writefln(base.classinfo.getMembers(m).length); getMembers has not been implemented, AFAIK It has in LDC ;) I think we need D2 support first ;)
Re: Shouldn't __traits return Tuples?
On Mon, Mar 30, 2009 at 5:13 PM, Tomas Lindquist Olsen tomas.l.ol...@gmail.com wrote: On Mon, Mar 30, 2009 at 5:11 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Mon, Mar 30, 2009 at 10:57 AM, Max Samukha samu...@voliacable.com.removethis wrote: Also the following doesn't work with dmd, returns 0 for all members: Base base = new Base; auto members = __traits(allMembers, typeof(base)); foreach(m; members) writefln(base.classinfo.getMembers(m).length); getMembers has not been implemented, AFAIK It has in LDC ;) I think we need D2 support first ;) Maybe you're thinking of OffsetTypeInfo (classinfo.offTi) ? Yes that can be enabled when configuring LDC, before building the compiler.
Re: OffsetTypeInfo
On Mon, Mar 30, 2009 at 5:48 PM, dsimcha dsim...@yahoo.com wrote: According to this post: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=86918 OffsetTypeInfo can be enabled when building LDC. Why does it not appear to work in current versions of DMD? Is there a good reason why it's apparently disabled? The reason I ask is because with OffsetTypeInfo enabled, one could almost trivially build a mostly-precise GC. All that would be needed is for each block to store a pointer to typeinfo. Last I check DMD just emits a null array, in codegen. I think I only realised this after implementing it in LDC. Anyway, Tango is currently set up in a way that will cause linking problems on some platforms when offTi is enabled, due to the extra typeinfo references. I don't recall the exact details, but that and that it adds some bloat as well (which is useless with .offTi is never used) are the reasons we disabled it by default. -Tomas
Re: [OT] [I mean totally OT] Re: What can you new
On Sat, Mar 28, 2009 at 2:22 PM, Christopher Wright dhase...@gmail.com wrote: Walter Bright wrote: Andrei Alexandrescu wrote: Sometimes I run these crazy calculations: how much modern firepower would be just enough to turn the odds in a classic battle? At Thermopilae, I think two Vickers with enough ammo would have been just about enough. Also at the Lord of the Rings 2 night castle defense, one machine gun would have sufficed (better protection and fewer assailants). Sometimes I think what if I were dropped naked back in time 20,000 years ago? Assuming I didn't get promptly cooked for dinner, what technology could I deliver that would have the most impact? I can't decide between iron, agriculture, or writing. I suspect writing. Every time humans got better at communicating, there was a huge increase in the rate of progress. Writing allows you to keep solutions to problems that only come about rarely. Disseminating these is very time-consuming, though; copying a manuscript by hand takes months. But 20,000 years? I think basic sanitation comes first. It also doesn't take very long. Once you have writing, though, it becomes *much* easier to approach things scientifically, especially with a bit of arithmetic. So that might be more worthwhile, since they can arrive at sanitation eventually anyway, and sooner if they have writing. Of course, in any case, you need to get around two obstacles: the language barrier and your ignorance of whatever you're trying to teach. I know less about agriculture, probably, than any stone age farmer. I don't know anywhere near enough about ironworking or mining to be able to offer any meaningful advice. But most people know enough about writing to create a writing system for another culture, if they just sit down and consider the problem for a few hours. So in your case, I dare say the only technology that you listed that you could deliver is writing. Even a metallurgist might have significant trouble providing ironworking to a culture without the typical modern tools of that trade. Are we playing some newsgroup based version of Civilization now?
Re: Building D compiler in MSVC IDE
On Sat, Mar 28, 2009 at 11:49 PM, Robert Fraser fraseroftheni...@gmail.com wrote: x-code wrote: I want to build last D 2.0 compiler in Microsoft Visual Studio IDE. Prompt me please, what create and adjust *.vcproj project in MSVC 2003/2005/2008 (or *.dsp for VC6) for assembly of the D compiler in Visual Studio? I tried this do, but faced that that some files #1085;#1077;#1093;#1074;#1072;#1090;#1072;#1077;#1090; (even after I have found in sources subprojects which generate the part lacking sources). Anyone created the similar projects? If yes, that where possible download working project? I spent ~15 hours trying to get LDC to build with it, and eventually basically gave up. It'll build (with some modifications), but there are quite a few issues that prevent it from working right in many cases. At the moment, LDC on Windows is pretty much a waste of time, since LLVM only supports Dwarf debug information and exception handling in the backends. This *will* change eventually, but none the less, this has been the situation for more than two years. There seems to be some GSOC proposals that will help if accepted, but anyway ... Btw.., you spent ~15hrs getting LDC to compile with MSVC? O.o What changes did you have to make? Where? Please send us your patches :)
Re: State of Play
On Thu, Mar 26, 2009 at 2:10 PM, Daniel Keep daniel.keep.li...@gmail.com wrote: ValeriM wrote: Ary Borenszweig Wrote: Mike James escribi�: What is the state of play with D1.0 vs. D2.0? Is D1.0 a dead-end and D2.0 should be used for future projects? Is D2.0 stable enough for use at the present? Is Tango for D2.0 at a level of D1.0 and can be used now? Is DWT ready for D2.0 now? Regards, mike. I don't know why a lot of people see D1.0 as a dead-end. It's a stable language. It won't get new features. It won't change. It'll probably receive bug fixes. It works. It gets the job done. You can use it and be sure than in a time all of what you did will still be compatible with newer versions of D1. No. It's not stable. Try to build last Tango and DWT releases with D1.041 and you will get the problems. It's a stable language. Note the use of the word language. What you're referring to are bugs in the compiler. It happens. -- Daniel D1 does have some missing features that are in D2, and could be backported to D1 without breaking any code. This isn't going to happen for the sake of stability. But if I want to use some of the new features, I have to get all the cruft that made me look into D in the first place as well. A major reason I started with D was because of simple syntax, GC and lack of the const hell. D2 is no longer a simple language, you have to know all kinds of shit to be able to use it correctly. All my projects at the moment are in C++. And TBH I don't see that changing any time soon. The stuff I did in D no longer works, and I don't have time to debug the entire thing to figure out how/where the compiler changed. And yes, the Phobos vs. Tango (which in turn keeps breaking) situation of course isn't making things better.
Re: State of Play
On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella llu...@gmail.com wrote: ...snip... That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to make an unofficial D 1.1 language), with a few minor non-breaking new features over D 1.0, then D 1.2 could introduce some more, and so on. This way people can catch-up easly, with small simple iterations, and D1 wont feel as a dead frozen language. I think this is bound to happen sooner or later. Just my 2¢ -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
Re: State of Play
On Thu, Mar 26, 2009 at 6:41 PM, Leandro Lucarella llu...@gmail.com wrote: Tomas Lindquist Olsen, el 26 de marzo a las 18:18 me escribiste: On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella llu...@gmail.com wrote: ...snip... That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to make an unofficial D 1.1 language), with a few minor non-breaking new features over D 1.0, then D 1.2 could introduce some more, and so on. This way people can catch-up easly, with small simple iterations, and D1 wont feel as a dead frozen language. I think this is bound to happen sooner or later. Well, then I'd love it happen sooner ;) We could start by figuring out what D 1.1 is ... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: State of Play
On Thu, Mar 26, 2009 at 6:58 PM, Ary Borenszweig a...@esperanto.org.ar wrote: Tomas Lindquist Olsen wrote: On Thu, Mar 26, 2009 at 6:41 PM, Leandro Lucarella llu...@gmail.com wrote: Tomas Lindquist Olsen, el 26 de marzo a las 18:18 me escribiste: On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella llu...@gmail.com wrote: ...snip... That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to make an unofficial D 1.1 language), with a few minor non-breaking new features over D 1.0, then D 1.2 could introduce some more, and so on. This way people can catch-up easly, with small simple iterations, and D1 wont feel as a dead frozen language. I think this is bound to happen sooner or later. Well, then I'd love it happen sooner ;) We could start by figuring out what D 1.1 is ... It's D2 - const/invariant, yeaaah! :-P Sounds a little drastic to me.
Re: State of Play
On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright newshou...@digitalmars.com wrote: Denis Koroskin wrote: One of the breaking changes that I recall was that you made Posix identifier built-in and thus any custom Posix versioning became an error. Not sure if it was introduced in 1.041, though, but it is still a breaking change. It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1. Everyone certainly does not think it was a bad idea. If trivial things like this sets people off, they should at least look at the problem (and comment those few lines) before complaining. All my humble opinion of course.
Re: State of Play
On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright newshou...@digitalmars.com wrote: Denis Koroskin wrote: One of the breaking changes that I recall was that you made Posix identifier built-in and thus any custom Posix versioning became an error. Not sure if it was introduced in 1.041, though, but it is still a breaking change. It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1. Everyone certainly does not think it was a bad idea. If trivial things like this sets people off, they should at least look at the problem (and comment those few lines) before complaining. All my humble opinion of course. To me, it illustrates a fundamental disconnect. One cannot have both a 100% stable language and yet introduce improvements to it. I don't necessarily want a 100% stable language. In fact I don't. But obviously asking for both is just silly. The only thing I'm not happy about is if code that used to work, still compiles, but no longer works. This is where the real problem is and I've seen it several times. MinWin, APaGeD and probably others.
Re: State of Play
On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen tomas.l.ol...@gmail.com wrote: On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright newshou...@digitalmars.com wrote: Denis Koroskin wrote: One of the breaking changes that I recall was that you made Posix identifier built-in and thus any custom Posix versioning became an error. Not sure if it was introduced in 1.041, though, but it is still a breaking change. It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1. Everyone certainly does not think it was a bad idea. If trivial things like this sets people off, they should at least look at the problem (and comment those few lines) before complaining. All my humble opinion of course. To me, it illustrates a fundamental disconnect. One cannot have both a 100% stable language and yet introduce improvements to it. I don't necessarily want a 100% stable language. In fact I don't. But obviously asking for both is just silly. The only thing I'm not happy about is if code that used to work, still compiles, but no longer works. This is where the real problem is and I've seen it several times. MinWin, APaGeD and probably others. Which leads me to: If I was to help with a D 1.1 implementation, only features that would not change any semantics of valid D1 code would go in.
Re: State of Play
On Thu, Mar 26, 2009 at 9:45 PM, grauzone n...@example.net wrote: Tomas Lindquist Olsen wrote: Which leads me to: If I was to help with a D 1.1 implementation, only features that would not change any semantics of valid D1 code would go in. Isn't this the point of the whole D 1.1 idea? People seem to have different ideas of what D 1.1 should be.
Re: State of Play
On Thu, Mar 26, 2009 at 10:02 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: Which leads me to: If I was to help with a D 1.1 implementation, only features that would not change any semantics of valid D1 code would go in. But they always do. Many of the complaints about D1 breaking things is the result of bug fixes to D1 inadvertently breaking something unexpected. True. However, now that the DMD source is available, that can change. All we need is for it be put in a public repository (svn, hg etc). Then people would be able to see what you're doing and test the fixes. Catching bugs early in the process, as well as providing pretty much guaranteed code review. I know I'd be subscribing my RSS reader to the changelog at least.
Re: State of Play
On Thu, Mar 26, 2009 at 10:05 PM, Walter Bright newshou...@digitalmars.com wrote: Tomas Lindquist Olsen wrote: I don't necessarily want a 100% stable language. In fact I don't. But obviously asking for both is just silly. The only thing I'm not happy about is if code that used to work, still compiles, but no longer works. This is where the real problem is and I've seen it several times. MinWin, APaGeD and probably others. What do you suggest? It's why there's a last stable version of D1 on the website. With any software package, if you always download the latest version but another package was only tested with a different version, it's likely to have problems. I'm not sure about what to do with the damage done already. I think it came across worse than I meant it to. In the future I think this can largely be solved by my public source repository proposal.
Re: winsamp sample crashed windbg
On Sun, Mar 15, 2009 at 10:46 AM, Walter Bright newshou...@digitalmars.com wrote: ws wrote: Ah, finally I found the culprit! It is the unlocker.exe running in the background, and that crashes windbg running D windows app consistently when it exits. (does not affect the console app). Took me a long time to find out. Thanks for your concerns! What's unlocker.exe ? Google seems to suggest it's a Worm virus... A virus scan is probably in order!
Re: Using dmd on older machines
On Wed, Mar 11, 2009 at 12:56 PM, Michel Fortin michel.for...@michelf.com wrote: On 2009-03-11 04:50:37 -0400, Walter Bright newshou...@digitalmars.com said: The source works just fine. The binaries don't. The new lib distros don't include the old lib, and vice versa. Often the missing lib isn't available. It's an ongoing nuisance. It isn't like Windows, where the basic api's have been unchanged for nearly 20 years. Mac OSX is the worst of the lot, there you get a bus error if you build for 10.5 and run it on 10.4. Yeah, the error message is bad. But on Mac OS X if you build for 10.4 (either by building on 10.4 or using the 10.4 SDK bundled with Xcode) it'll be forward-compatible with the newer versions of Mac OS X yet to come. For instance, I can run apps compiled on 10.0 quite well on 10.5, with no tweaking at all. Seems on Linux if you choose the old lib it won't run on the newer distos. That looks worse to me. This is usually not a problem as most linux software is free (as in freedom) and has open source code though. Commercial applications can simply provide multiple binaries. Just like the situation is getting for XP/Vista as well (I know, it's only really games, and it's not really the same situation, but anyway ...) DMD source code being available is a good start, but as I understand it, Linux distributions are still not allowed to redistribute it ? Or binaries of a modified source build ? -Tomas -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Using dmd on older machines
On Wed, Mar 11, 2009 at 1:29 PM, Denis Koroskin 2kor...@gmail.com wrote: On Wed, 11 Mar 2009 15:14:44 +0300, Tomas Lindquist Olsen tomas.l.ol...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:56 PM, Michel Fortin michel.for...@michelf.com wrote: On 2009-03-11 04:50:37 -0400, Walter Bright newshou...@digitalmars.com said: The source works just fine. The binaries don't. The new lib distros don't include the old lib, and vice versa. Often the missing lib isn't available. It's an ongoing nuisance. It isn't like Windows, where the basic api's have been unchanged for nearly 20 years. Mac OSX is the worst of the lot, there you get a bus error if you build for 10.5 and run it on 10.4. Yeah, the error message is bad. But on Mac OS X if you build for 10.4 (either by building on 10.4 or using the 10.4 SDK bundled with Xcode) it'll be forward-compatible with the newer versions of Mac OS X yet to come. For instance, I can run apps compiled on 10.0 quite well on 10.5, with no tweaking at all. Seems on Linux if you choose the old lib it won't run on the newer distos. That looks worse to me. This is usually not a problem as most linux software is free (as in freedom) and has open source code though. Commercial applications can simply provide multiple binaries. Just like the situation is getting for XP/Vista as well (I know, it's only really games, and it's not really the same situation, but anyway ...) It's more like x86/x86_64 situation. DMD source code being available is a good start, but as I understand it, Linux distributions are still not allowed to redistribute it ? Or binaries of a modified source build ? -Tomas Is there a need for that? Gentoo ebuild can automatically fetch source code from digitalmars.com and compile the binary (given the ebuild, of course), and I believe other distros can do the same. Maybe it's not so bad as I think, but sometimes a build fails, and beginner programmers who, lets say wanted to try D, has no means to fix that, and the binary is broken ... -Tomas
Re: OpenMW 0.6 (+Monster) is out!
On Sat, Mar 7, 2009 at 10:43 AM, Nicolay Korslund korsl...@gmail.com wrote: Those following the progress of D in game development might be interested to know that OpenMW 0.6 is out. I just checked it out, and while it took a little while to get everything built, the result was really really cool :D Definitely gonna play a bit with this tonight :) Just for information, building on Arch Linux is fairly easy. All the packages are in AUR except openmw itself. In case someone else want to try, just get: 1) ogre mygui-svn bullet-2.74 openal ffmpeg ois dmd libphobos dsss 2) then checkout openmw. a few things aren't set up right, so edit the Makefile and add: -I/usr/include/libavcodec -I/usr/include/libavformat to the ffmpeg section. Edit dsss.conf as well replacing the bullet libraries with: -llBulletDynamics -llBulletCollision -llLinearMath in both places. 3) symlink data files into 'openmw/data', execute, enjoy ! I'm not sure this is a good place to post this, but here it is! -Tomas
Re: Open source dmd on Reddit!
On Fri, Mar 6, 2009 at 4:42 AM, Sean Kelly s...@invisibleduck.org wrote: hasen wrote: Walter Bright wrote: http://www.reddit.com/r/programming/comments/82ck4/digitalmars_d_now_open_source/ http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_programming_language_now/ Wow there's a big fuss over there about it not being /really/ open source, Seems kind of silly to me. The big deal with the full source for DMD being available is that if DigitalMars disappears in a puff of smoke tomorrow, customers have a means of preserving their investment in the language. This can be a big deal for corporate users. I'm not sure I see the big value here. If Digital Mars indeed went up in smoke some day, how will the source help? They're still not allowed to do anything but personal use with it... Or am I missing something ? -Tomas
Re: LLVM updates
On Tue, Mar 3, 2009 at 11:58 AM, bearophile bearophileh...@lycos.com wrote: There are some improvements in the last LLVM V.2.5, among them now LLVM provides intrinsics for (some) arithmetic with overflow operations: http://llvm.org/docs/LangRef.html#int_overflow Introducing such feature into D (LDC and more) is even simpler now :-) Bye, bearophile Frits van Bommel has already added support for the new intrinsics to LDC :D -Tomas
Re: First class lazy Interval
On Tue, Mar 3, 2009 at 5:22 PM, Don nos...@nospam.com wrote: Joel C. Salomon wrote: Daniel Keep wrote: Yes, a..b is very nice. It's also a bad syntax for intervals. As Don keeps pointing out, you can't have an interval that includes int.max with that syntax. 4 .. int.$ —Joel Salomon I love that real.$ is the number that's even bigger than infinity g. What if the range is stored in variables? x[a..b]; How can you set b so that it includes x[int.max]? How about x[a..b] vs x[a..b+] ?
Re: Inline Functions
On Wed, Feb 25, 2009 at 8:42 AM, Walter Bright newshou...@digitalmars.com wrote: Mason Green (Zzzzrrr) wrote: When I remove -inline there doesn't seem to be much of a difference in execution speed. Try running obj2asm to see if the functions you want inlined are actually inlined or not. perhaps a verbose mode could be added in dmd that prints the pretty printed declaration when a function is inlined. then it would be a simple grep to make sure. dmd -vi foo.d | grep 'foo\.inc' telling people to inspect the obj2asm output seems to be popular, but it's hardly user friendly.
Re: Inline assembler in D and LDC, round 2
On Thu, Feb 5, 2009 at 2:42 PM, Frits van Bommel fvbom...@remwovexcapss.nl wrote: Don wrote: Frits van Bommel wrote: Walter Bright wrote: Frits van Bommel wrote: Is it really that hard? Can't you just detect this case (non-void function without a 'return' at the end but with inline asm inside)? Since the compiler should know the calling convention[1], the register that will contain the return value of the function should be a simple lookup (based on target architecture, cc and return type). Just add that register as an output of the inline asm and return it... dmd doesn't attempt to figure out which register is the return value. It just assumes that the registers specified by the ABI for the function's return type have the proper return value in them. That isn't an option for LDC, which is why I suggested another approach. What's the difference? Walter's approach assumes there's a return EAX; at the end of every function returning an int, for example; your approach seems to be to add it. His approach depends on DMD directly emitting x86 machine code, so it can just emit 'RET' and be done with it. LDC on the other hand needs to emit LLVM asm, which requires it to specify an explicit return value. My approach is a way to extract that return value from the inline asm, allowing it to emulate DMD behavior within the LLVM IR. I had really hoped I didn't have to do something like this, but I can't come up with a better approach. I just hope it actually works when I'm done ... Also I have no idea if code quality is going to be optimal. I imagine people write code like this for efficiency, if LLVM adds extra instructions there is little point in writing code like this for LDC, and we'd want to version things in any case, providing a true naked version for LDC. In this case I'm not sure it's worth it to actually do this work in the first place.
Inline assembler in D and LDC, round 2
Hello everybody.
Here comes the second round of inline asm discussion related to LDC,
the LLVM D Compiler.
Last time was about naked inline asm and the problems it poses for a
backend like LLVM.
Since revision 920 in our mercurial tree, naked inline asm support is
good enough that Don's Bigint code from Tango now works. This is a
great step forward...
I implemented it by using a feature in LLVM that allows you to insert
raw assembly at the codeunit level, and modified the asm processor to
support generating that as well. It wasn't that big a job really,
isn't completely finished yet, and still needs a lot of testing of
course ;)
Now Christian Kamm also finished the last ABI / calling-convention
bits we were missing on x86-32 Linux. This naturally lead us to try
out defining the controversial D_InlineAsm_X86 version identifier...
Now in Tango there's a bunch of code, like the following (copied from
tango.math.IEEE.d)
real ldexp(real n, int exp) /* intrinsic */
{
version(Really_D_InlineAsm_X86)
{
asm {
fild exp;
fld n;
fscale;
fstp ST(1), ST(0);
}
}
else
{
return tango.stdc.math.ldexpl(n, exp);
}
}
This code assumes that the value of ST(0) is preserved after the asm
block ends and that the compiler simply inserts a return instruction
as appropriate.
This doesn't work with LLVM. For the function to be valid in codegen,
we must insert a return instruction in the LLVM IR code after the
block, and the only choices we have for the value to return is an
undefined value. This kind of code usually works when the program
isn't optimized, however, if optimization is enabled, a caller of
ldexp will most likely notice that the return value is undefined or a
constant, and so has a lot of freedom to do what it wants. Breaking
the way the return value is received in the process.
This is almost exactly the same problem I had with naked inline asm,
and the only fix is to somehow generate an inline asm expression
(that's what llvm has, not statements like D), that produces the right
return value. Something a bit like:
return asm { ... }
Since D has no way to express this directly, it means we would have to
analyze the inline asm and somehow capture the right registers etc.
This is not something I want to implement right now, if ever...
The LLVM people are not interested in adding some kind of feature to
allow this, since the inline asm expressions already suffice for
normal GCC (which has inline asm expressions) C/C++ code.
Now the real question is, does this code even have well defined
semantics in terms of the D spec? and if not, could we possibly
specify it as implementation specific behaviour.
Everything is in place to specify the D_InlineAsm_X86 version
identifier in LDC, but a lot of asm still isn't going to work, due to
reasons like this.
I hope to hear some feedback on how to move on from here.
Thank you all,
Tomas Lindquist Olsen and the LDC Team.
Re: dsource considered harmful
On Sun, Jan 18, 2009 at 11:11 PM, Stewart Gordon smjg_1...@yahoo.comwrote: ... Speaking of which, has anybody tried asking Brad for commit permission on an abandoned project in order to revive it? Stewart. I took over the MinWin project a long time ago, since its author, Ben Hinkle, had disappeared from the community, I tried reviving it for about half a year, with some success, but eventually I got tired of doing it alone, with little to no testers/users. So it's pretty dead now again... -Tomas
Re: LDC 0.9 released
On Fri, Jan 9, 2009 at 11:19 AM, Walter Bright newshou...@digitalmars.comwrote: Christian Kamm wrote: PowerPC support is still in its infancy. We've had two people looking at it a few months back, but I haven't heard from either recently. I think they ran into a frontend-portability issue: http://www.dsource.org/projects/ldc/ticket/76 I don't think anyone has tried LDC on ARM yet. ARM is real big on embedded systems like phones. D is an ideal language for them. I get asked a lot about supporting it. Moritz Warning did some good work on getting LDC to compile and run on ARM/Linux a while back. IIRC he even posted a virtual machine image with everything to try it out, there was still some runtime issue to care of though. Also, this wasn't a cross compiler, but rather LDC running natively on the ARM itself, which is probably not what most people would want. LDC has most things in place for cross compilation already, but there's still some work to be done in that area before it's fully useful. Moritz, please chime in with any corrections/additions :) The PPC is a more fill-in-the-blank, as it is yesterday's machine. As far as I know, LLVM's PPC target is fairly mature, and getting LDC to work on this platform would probably not take that much more work once the frontend issues there have been sorted. Anyhow, getting D on more platforms will remove a lot of barriers people have to using it. LDC is a big step forward for that.
Re: foreach ... else statement
On Wed, Jan 7, 2009 at 6:07 AM, Walter Bright newshou...@digitalmars.comwrote: Don wrote: I still avoid goto because I was told to. But eventually I realised that it's 100% propaganda. I actually think my code would be cleaner if I used it; it would allow lots of local flag variables to be eliminated. But I still have this residual prejudice against 'goto' which is really hard to get rid of. The problem with goto is it is easy to get into a human readability problem with it. No such problem exists for optimization algorithms. Yes, but I doubt any compiler would have a problem with goto. The last time I even heard of a compiler that fell over and gave up optimizing if it saw a goto was in the early 80's. I have a hard time believing LDC has problems with it, but if it does, the authors should hit the books g. It doesn't :P I keep thinking I should put on a Compiler Construction seminar! P.S. There are problems with goto'ing out of a finally block, and there's a problem in the optimizer with goto'ing from one try block to another, but that's not the issue here.
Re: 'naked' keyword
On Wed, Jan 7, 2009 at 12:41 PM, Don nos...@nospam.com wrote:
Tomas Lindquist Olsen wrote:
On Fri, Jan 2, 2009 at 9:21 AM, Don nos...@nospam.com mailto:
nos...@nospam.com wrote:
Duane Bailey wrote:
I am currently porting LDC to PowerPC and, hopefully,
eventually the POWER and CELL platforms as well. The first bit
requires me to port the inline assembler, allowing me to
review the problems that the D language presents LLVM.
Cool
LLVM is not a toy virtual machine. It is, perhaps, the most
flexible and powerful compiler toolset ever, spanning massive
numbers of computing platforms. It even supports (in a limited
manner) the PIC16 platform, require insane constraints: there
are no registers, memory can only be accessed in one byte
amounts, and some processors only have 35 instructions.
That's pretty impressive. I'm currently using a PIC, but it's so
memory-limited it's hard to believe D ever being workable on it.
LLVM, however, is not able to do everything. For some reason,
its current API does not allow the restriction of prologue and
epilogue generation; to allow so would not make sense: the
language itself depends on the maintenance of the stack. The
only way to establish a 'naked' function in *c* is to 'omit' the
frame pointer—technically not allowed in most OS's ABIs—and then
explicitly avoid using all variables (and hence the stack), OR
to use top level assembly to write the assembly yourself.
Now, neither of those options are really what D should use, but
I have some other recommendations based on this. 'naked'
functions should not be allowed to have any D, except to
reference arguments passed to it. In other words, it should not
touch the stack. in fact, there's really no reason at all to
have the 'naked' statement in the inline assembly. It's not a
property of the assembly, it's a property of the *function*. And
because D code should not be used (except perhaps for macros?),
'naked' functions should intrinsically be assembly functions.
I agree with this. Mixing run-time D and naked asm doesn't make any
sense. But, something which I've done which is _very_ useful is to
mixin CTFE functions. You get something like:
void foo() {
asm {
naked;
}
mixin(someasm(EBX)); // becomes asm {mov EAX, EBX; }
asm { ret; }
}
char [] someasm(char [] c) {
return asm { mov EAX, ~ c ~; };
}
I see this as crucial functionality since it gives you an
unbelievably powerful macro language in the assembler.
it should be no problem to merge asm blocks in a function, the only
problem is mixing normal dcode in there as well.
I've decided to make this an error in LDC since there is no sensible way
to implement D-style function parameters *and* make sure the function really
is naked. function parameters in llvm are ssa values, so you manually have
to alloca a stack slot and copy the argument into that to make sure the
parameter is an l-value
I don't understand those last two sentences. Does it mean that you'd only
allow 'naked' on extern(C) functions? Or only that mixing D and naked asm
would be illegal?
Sorry, I can see I was a bit unclear. All I meant was that I can't sensibly
implement naked and allow arbitrary D code in the mix as well, it's either
or... naked should eventually work fine for any calling conventions, it'll
just bail out with an error if you try and mix D in between the asm blocks.
By the way, in DMD, mixing naked and D code only works if you put a push
EBP; mov EBP, ESP; before the first bit of D code, which isn't documented
anywhere as far as I know; and I don't know how to make inner functions
work. So it's pretty much unspecified behaviour right now.
nested delegates inside naked functions pose some problems, since they will
modify the stack frame as well (like allowing full access to function
parameters, like taking the address of one, which was what I was trying to
talk about in my reply)
Consider taking the address of a parameter that is passed by value in EAX,
this will allocate a stack slot...
Hope I was a bit more clear this time :)
Re: Basic benchmark
bearophile wrote: I have adapted another small benchmark to D. This benchmark is less interesting than the other ones because it mostly tests the optimizations done by the back-end. This means it's not a problem of the D language or its front-end, so even if DMD here shows to be not much efficient, LDC once finished may show significant improvements. As usual I may have done several errors, so keep your eyes open. ..snip.. Timings: C gcc: Long arithmetic: 11.15 s Nested Loops: 0.11 s D dmd: Long arithmetic: 63.7 s Nested Loops: 6.17 s Bye, bearophile I tried this out with Tango + DMD 1.033, Tango + LDC r847 and GCC 4.3.2, my timings are as follows, best of three: $ dmd bench.d -O -release -inline long arith: 55630 ms nested loop: 5090 ms $ ldc bench.d -O3 -release -inline long arith: 13870 ms nested loop: 120 ms $ gcc bench.c -O3 -s -fomit-frame-pointer long arith: 13600 ms nested loop: 170 ms My cpu is: Athlon64 X2 3800+
Re: Treating the abusive unsigned syndrome
I'm not really sure what I think about all this. I try to always insert
assertions before operations like this, which makes me think the nicest
solution would be if the compiler errors out if it detects a problematic
expression that is unchecked...
uint diff(uint begin, uint end)
{
return end - begin; // error
}
uint diff(uint begin, uint end)
{
assert(begin = end);
return end - begin; // ok because of the assert
}
I'm not going to get into how this would be implemented in the compiler,
but it sure would be sweet :)
Re: 64 bits D compiler ?
On Sat, Nov 22, 2008 at 1:25 PM, Denis Koroskin [EMAIL PROTECTED] wrote: 22.11.08 в 15:21 Vermi в своём письме писал(а): Hi, I'm wondering : why the D compiler can't produce x86_64 code ? All seems to be ready in the langage for 64 bits. I need to produce a .dll file in both 32 and 64 bits, but I can't. Will we see soon a 64 bits version of the D Compiler or should I re-write my apps in C++ ? @+ Vermi There is a LLVM D compiler (LDC for short) in works: http://dsource.org/projects/ldc/ which will be able to do what you wants once it is released. But 64bit support on *Windows* is probably not gonna happen in any near future -Tomas
