Re: dfilt - c++filt like tool to demangle D names
On Jul 8, 11 00:04, David Nadlinger wrote: Oh, I noticed your post too late, this would be my own quick hack: https://gist.github.com/1069843 David On 7/7/11 4:50 PM, Trass3r wrote: Since I couldn't find a tool like c++filt for D I quickly hacked one together. Very useful especially for 'objdump -d test.o | dfilt'. If anybody is interested: https://github.com/Trass3r/tools/blob/master/dfilt/dfilt.d Side note: seems like core.demangle can't demangle _D5utils7__arrayZ, bug? Oh not another please :) Michel Fortin already made one and is waiting to be pulled. https://github.com/D-Programming-Language/tools/pull/2 BTW, _D5utils7__arrayZ cannot be demangled because there is no corresponding type for the character 'Z'. It could demangle if you change the last 'Z' to e.g. 'i': _D5utils7__arrayi -> int utils.__array
Re: DMD/Objective-C Alpha 1
On Jun 2, 11 18:17, Michel Fortin wrote:
On 2011-06-02 05:30:10 -0400, bearophile said:
From the page:
The ultimate goal is to merge the capabilities back into mainline DMD",
Do you want to add a syntax like this to D/DMD?
void insertItem(ObjcObject object, NSInteger value)
[insertItemWithObjectValue:atIndex:];
Well, that's what I'd like. Given that you can't hide completely
selectors as an implementation detail and that programmers might need to
specify them from time to time -- which is all the time when declaring
extern Objective-C classes! -- I thought it'd be very much appreciated
if the syntax for that wasn't too unreadable.
That said, if Walter doesn't like it I could change it to a more
"standard" pragma syntax:
pragma(objc_selector, "insertIdemWithObjectValue:atIndex:")
void insertItem(ObjcObject object, NSInteger value);
It's more verbose and less readable, but it'd work too.
@selector("insertIdemWithObjectValue:atIndex:")
void insertItem(ObjcObject object, NSInteger value);
;)
Re: Phobos unit testing uncovers a CPU bug
On Nov 27, 10 05:25, Simen kjaeraas wrote: Don wrote: The difference was discovered through the unit tests for the mathematical Special Functions which will be included in the next compiler release. Discovery of the discrepancy happened only because of several features of D: - built-in unit tests (encourages tests to be run on many machines) - built-in code coverage (the tests include extreme cases, simply because I was trying to increase the code coverage to high values) - D supports the hex format for floats. Without this feature, the discrepancy would have been blamed on differences in the floating-point conversion functions in the C standard library. This experience reinforces my belief that D is an excellent language for scientific computing. This sounds like a great sales argument. Gives us some bragging rights. :p Thanks to David Simcha and Dmitry Olshansky for help in tracking this down. Great job! Now, which of the results is correct, and has AMD and Intel been informed? Intel is correct. yl2x(0x1.0076fc5cc7933866p+40L, LN2) == log(9240117798188457011/8388608) == 0x1.bba4a9f774f49d0a64ac5666c969fd8ca8e...p+4 ^
Re: D web site facelift
On Jul 6, 10 10:04, Walter Bright wrote:
KennyTM~ wrote:
You could use to suppress translation. It's
documented in http://translate.google.com/support/.
It's actually span, not pre. But thanks for the tip, I'll give it a try.
Actually any elements with the class name 'notranslate' is OK, e.g.
int main () {
...
return 0;
}
Re: D web site facelift
On Jul 4, 10 04:57, Walter Bright wrote: Andrei Alexandrescu wrote: Walter Bright wrote: Walter Bright wrote: Michel Fortin wrote: On a side note, I've noticed on other websites that Google Translation doesn't attempt to translate code inside a element. So I would suggest the website uses ... for its code blocks, and ... for keywords and other code-related terms in the text. That could actually make the translation useful. This must be new, it didn't use to do that. I'll take advantage of it! Sadly, it doesn't work, as it strips all the newlines out, putting your code all on one line. Bah :-( How about nesting them the other way around? ...? I tried that, too. It recognizes the newlines, and then translates the code. Back to square 1. You could use to suppress translation. It's documented in http://translate.google.com/support/.
Re: fedora will get ldc and tango in official repo
On Jun 26, 10 23:43, BCS wrote: Hello bioinfornatics, because not all is in open License, i read this: http://www.prowiki.org/wiki4d/wiki.cgi?PhobosLicenseIssues Looking at it I don't recognize what license most of it is under but IIRC it's supposed to all be all under the boost license. I do know that Walter has been careful to only put in code that can be freely used (if not fully open source). That's true for D2, but probably not for D1.
Re: dmd 1.056 and 2.040 release
On Jan 30, 10 15:13, Walter Bright wrote: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.056.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.040.zip Thanks to the many people who contributed to this update! Is the changelog page broken? On the 2.0 changelog it starts with "$(D_S D Change Log,", and without a navigation bar.
Re: dmd 1.055 and 2.039 release
On Jan 4, 10 05:06, digited wrote: Walter Bright Wrote: Fixes the Tango build breaks. With RC's, you'll never need this. Neither if people regularly test with the trunk build.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
On Nov 5, 09 02:21, Leandro Lucarella wrote: grauzone, el 4 de noviembre a las 17:23 me escribiste: Walter Bright wrote: Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow. And if you really find it slow, GNU Gold (done by Google) is *much* faster. But gold is ELF only, which is irrelevant for Windows.
Re: dmd 1.046 and 2.031 releases
Ary Borenszweig wrote: Jesse Phillips escribió: On Mon, 06 Jul 2009 14:38:53 -0500, Andrei Alexandrescu wrote: Denis Koroskin wrote: Reuse goto? So any case-labeled code should end either with a control flow statement that transfers control elswhere? That sounds like a great idea. Fall-through is so rare and so rarely intended, it makes sense to require the programmer to state the intent explicitly via a goto case. Andrei The goto method already works, the only change needed would be to not have fallthru default. http://digitalmars.com/d/2.0/statement.html#GotoStatement But that's kind of redundant: case 1: goto case 11: case 11: goto case 111: case 111: goto case : case : doIt(); don't you think? Maybe http://msdn.microsoft.com/en-us/vcsharp/aa336815.aspx . If you change the case expression, you must change it twice. Why not: case 1: continue case; case 11: continue case; etc.?
Re: New DigitalMars D newsgroups/forum
Denis Koroskin wrote: I have been working on new newsgroups archive last few days. This is an newsgroup posts archive structured in a way so that it feels more like a forum (that's what you demanded, right?). Currently it is readonly, updated infrequently and have some known bugs. Testing needed! User registration, post submition (of course!), post editing/removal, search (per forum/per thread etc) - not supported atm (but will be soon!) Forum theme is copyrighted and needs to be changed by something free. Feedback, bugs detected, suggestions etc are *very* much appreciated! Check it out: http://dnews.naxx.ru Looks nice :) The page 1 | 2 | 3 | 4 | etc | 229 | 230 stuff could probably be condensed to links to first 10 pages and then followed by an input box to save space :)
Re: ATS -- unleashing the potential of types!
Pablo Ripolles wrote:
Hello all!
I assume many of you already know about ATS...
I'd like to know your thoughts about it!
Some interesting references are:
http://www.ats-lang.org/
http://www.reddit.com/r/programming/comments/72hmw/language_shootout_ats_is_the_new_top_gunslinger/
it is damn fast!
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all
Cheers!
fun fib4 {n:nat} (x: int n): [r:int] (FIB (n, r) | int r) = let
fun loop {i,j:nat | i+j == n} {r0,r1:int}
(pf0: FIB (j, r0), pf1: FIB (j+1, r1) | x: int i, a0: int r0, a1:
int r1)
: [r:int] (FIB (n, r) | int r) =
if x > 0 then loop (pf1, FIB_ind (pf0, pf1) | x-1, a1, a0 + a1)
else (pf0 | a0)
in
loop (FIB_bas_0 (), FIB_bas_1 () | x, 0, 1)
end // end of [fib4]
No thanks, I'd rather program in assembly. :(
Re: Adding Unicode operators to D [use cases]
KennyTM~ wrote:
bearophile wrote:
Sergey Gromov:
I'd use dot "⋅" and cross "×" products for 3D, union "∪" and
intersection "∩", subset "⊂" and superset "⊃" and their
negative forms.
I don't think I'd use anything else.
I just want to note that the whole thread is almost unreadable on the
digitalmars.com/webnews/, because it doesn't digest unicode chars at
all. So adding unicode to D will give problems to show code.
Unrelated to the unicode, but related on those opSubset, opSuperset, etc:
while implementing a set() class with the same API of the Python sets,
I have seen there are the following operators/methods too:
issubset(other) set <= other Test whether every element in the set is
in other.
set < other Test whether the set is a true subset of other, that is,
set <= other and set != other.
issuperset(other) set >= other Test whether every element in other is
in the set.
set > other Test whether the set is a true superset of other, that is,
set >= other and set != other.
A full opCmp can't be defined on sets, so I think in D1 we can't
overload <= >= among sets... I think this is a problem has to be
solved in D2, because sets are important enough.
Bye,
bearophile
If the two sets are incomparable, just return NaN... We need an opCmp
that returns a float :)
Actually I've made a working solution. Even the exotic operators like
!<= (not a subset of, ⊈) works too. It's designed for demonstration, not
performance, though.
import std.stdio;
class StupidSet(T) {
private bool[T] data;
void insert(in T x[] ...) {
foreach (val; x)
data[val] = true;
}
// check if two sets are equal.
bool opEquals(in typeof(this) y) const {
if (y.data.length != data.length)
return false;
foreach (idx, dummy; y.data) {
if (!(idx in data))
return false;
}
return true;
}
// compare two sets
float opCmp(in typeof(this) y) const {
auto y_data_len = y.data.length, x_data_len = data.length;
// if I have less elements than you, test if I am a subset of
you.
if (x_data_len < y_data_len) {
foreach (idx, dummy; data) {
if (!(idx in y.data))
// the sets are not contained within
each other; we are not comparable.
return float.nan;
}
// I am a strict subset of you.
return -1.f;
// reuse opEquals.
} else if (x_data_len == y_data_len)
return opEquals(y) ? 0 : float.nan;
// reverse the roles of you and me.
else
return -y.opCmp(this);
}
}
void main () {
auto s = new StupidSet!(int);
auto t = new StupidSet!(int);
s.insert(2, 4);
t.insert(2, 3);
writefln(s > t);// strict superset
writefln(s >= t); // superset
writefln(s == t); // equal
writefln(s <= t); // subset
writefln(s < t);// strict subset
writefln(s != t); // not equal
writefln(s !>= t); // not superset, etc.
writefln();
// should print 5 false and 2 true in order.
t.insert(4);// now t is a strict superset of s.
writefln(s > t);// strict superset
writefln(s >= t); // superset
writefln(s == t); // equal
writefln(s <= t); // subset
writefln(s < t);// strict subset
writefln(s != t); // not equal
writefln(s !>= t); // not superset, etc.
// should print 3 false and 4 true in order.
}
Re: Adding Unicode operators to D [use cases]
bearophile wrote: Sergey Gromov: I'd use dot "⋅" and cross "×" products for 3D, union "∪" and intersection "∩", subset "⊂" and superset "⊃" and their negative forms. I don't think I'd use anything else. I just want to note that the whole thread is almost unreadable on the digitalmars.com/webnews/, because it doesn't digest unicode chars at all. So adding unicode to D will give problems to show code. Unrelated to the unicode, but related on those opSubset, opSuperset, etc: while implementing a set() class with the same API of the Python sets, I have seen there are the following operators/methods too: issubset(other) set <= other Test whether every element in the set is in other. set < other Test whether the set is a true subset of other, that is, set <= other and set != other. issuperset(other) set >= other Test whether every element in other is in the set. set > other Test whether the set is a true superset of other, that is, set >= other and set != other. A full opCmp can't be defined on sets, so I think in D1 we can't overload <= >= among sets... I think this is a problem has to be solved in D2, because sets are important enough. Bye, bearophile If the two sets are incomparable, just return NaN... We need an opCmp that returns a float :)
Re: Adding Unicode operators to D
Andrei Alexandrescu wrote: Bruno Medeiros wrote: Andrei Alexandrescu wrote: Spacen Jasset wrote: Bill Baxter wrote: On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: Please vote up before the haters take it down, and discuss: http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ (My comment cross posted here from reddit) I think the right way to do it is not to make everything Unicode. All the pressure on the existing symbols would be dramatically relieved by the addition of just a handful of new symbols. The truth is keyboards aren't very good for inputting Unicode. That isn't likely to change. Yes they've dealt with the problem in Asian languages by using IMEs but in my opinion IMEs are horrible to use. Some people seem to argue it's a waste to go to Unicode only for a few symbols. If you're going to go Unicode, you should go whole hog. I'd argue the exact opposite. If you're going to go Unicode, it should be done in moderation. Use as little Unicode as necessary and no more. As for how to input unicode -- Microsoft Word solved that problem ages ago, assuming we're talking about small numbers of special characters. It's called AutoCorrect. You just register your unicode symbol as a misspelling for "(X)" or something unique like that and then every time you type "(X)" a funky unicode character instantly replaces those chars. Yeh, not many editors support such a feature. But it's very easy to implement. And with that one generic mechanism, your editor is ready to support input of Unicode chars in any language just by adding the right definitions. --bb I am not entirely sure that 30 or (x amount) of new operators would be a good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs m3 = m1 X m2 ? and how often will that happen? It's also going to make the language more difficult to learn and understand. I have noticed that in pretty much all scientific code, the f(a, b) and a.f(b) notations fall off a readability cliff when the number of operators grows only to a handful. Lured by simple examples like yours, people don't see that as a problem until they actually have to read or write such code. Adding temporaries and such is not that great because it further takes the algorithm away from its mathematical form just for serving a notation that was the problem in the first place. But what operators would be added? Some mathematician programmers might want vector and matrix operators, others set operators, others still derivation/integration operators, and so on. Where would we stop? I don't deny it might be useful for them, but it does seem like too specific a need to integrate in the language. I was thinking of allowing a general way of defining one Unicode character to stand in as one operator, and then have libraries implement the actual operators. There's the remaining problem of different libraries defining the same character to mean different operators. This may not be huge as math subdomains tend to be rather consistent in their use of operators. Across math subdomains, types and overloading can take care of things. Also, ascii representation should be allowed for operators, and one nice thing about Unicode characters is that many have HTML ascii and human-readable names, see http://www.fileformat.info/format/w3c/htmlentity.htm. So \unicodecharname may be a good alternate way to enter these operators. For example, the empty set could be \empty, and the cross-product could be written as \times. So c = a \times b; doesn't quite look bad to me. One nice thing about this is that we don't need to pore over naming and such, we just use stuff that others (creators and users alike) have already pored over. Saves on documentation writing too :o). Andrei LaTeX in D? :p Anyway we already have \× and \∅ so we could reuse them in source code level as I've described somewhere in this thread. auto torque = position \× force; This is uglier than auto torque = position \times force; but it gives a uniform syntax between escape sequences inside and outside strings. The problem is you may have to invent some names, i.e. the composition operator ∘ (U+2218 ring operator) has no name in SGML entities. In LaTeX it is represented as \circ but \ˆ is already taken by ˆ (U+02C6 modifier letter circumflex accent). And you'll need to predefine the associativity and operation precedence too. ;) See my other entry in this thread.
Re: Adding Unicode operators to D
Bruno Medeiros wrote: Andrei Alexandrescu wrote: Spacen Jasset wrote: Bill Baxter wrote: On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: Please vote up before the haters take it down, and discuss: http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ (My comment cross posted here from reddit) I think the right way to do it is not to make everything Unicode. All the pressure on the existing symbols would be dramatically relieved by the addition of just a handful of new symbols. The truth is keyboards aren't very good for inputting Unicode. That isn't likely to change. Yes they've dealt with the problem in Asian languages by using IMEs but in my opinion IMEs are horrible to use. Some people seem to argue it's a waste to go to Unicode only for a few symbols. If you're going to go Unicode, you should go whole hog. I'd argue the exact opposite. If you're going to go Unicode, it should be done in moderation. Use as little Unicode as necessary and no more. As for how to input unicode -- Microsoft Word solved that problem ages ago, assuming we're talking about small numbers of special characters. It's called AutoCorrect. You just register your unicode symbol as a misspelling for "(X)" or something unique like that and then every time you type "(X)" a funky unicode character instantly replaces those chars. Yeh, not many editors support such a feature. But it's very easy to implement. And with that one generic mechanism, your editor is ready to support input of Unicode chars in any language just by adding the right definitions. --bb I am not entirely sure that 30 or (x amount) of new operators would be a good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs m3 = m1 X m2 ? and how often will that happen? It's also going to make the language more difficult to learn and understand. I have noticed that in pretty much all scientific code, the f(a, b) and a.f(b) notations fall off a readability cliff when the number of operators grows only to a handful. Lured by simple examples like yours, people don't see that as a problem until they actually have to read or write such code. Adding temporaries and such is not that great because it further takes the algorithm away from its mathematical form just for serving a notation that was the problem in the first place. But what operators would be added? Some mathematician programmers might want vector and matrix operators, others set operators, others still derivation/integration operators, and so on. Where would we stop? I don't deny it might be useful for them, but it does seem like too specific a need to integrate in the language. Composition may be useful for functional programming (I've never used any functional programming paradigm except "reduce".) Matrix operations: + - * .tr() .inv() .det() etc are already sufficient for most jobs. Vector operations: Maybe an operator for cross product. Set operators: Just use + - * (| ~ &) instead like Pascal. So only 2 Unicode operators I see are really useful and the replacements are ugly: Composition (o) and cross product (×).
Re: Adding Unicode operators to D
Robert Fraser wrote: Bill Baxter wrote: Yigal Chripun wrote: PowerShell is GUI based as well. After downloading it and giving it a try, I find this claim somewhat suspect. What makes you say it's GUI based? It has the exact same decorations and goofy menu options as a regular non-GUI Windows console. If it were really a GUI, I doubt they would go through the extra programming effort required to make it look *exactly* like a console app. --bb It uses the same console application to do the displaying/execution. And, yes, this application sucks (ever done any serious copy/paste in it?) There's PoshConsole ( http://www.codeplex.com/PoshConsole ), but that TODO list is a bit extensive ;-P. Hopefully by Win7 time, the Windows group gets around to fixing the console, but that's like hoping they'll fix Paint or Notepad ;-P. Hey, they do have fixed MSPaint and WordPad! :)
Re: Adding Unicode operators to D
Bruno Medeiros wrote: Simen Kjaeraas wrote: As an example, while I'd enjoy seeing code like this, I'm not sure I'd enjoy writing it (Note that I am prone to exaggerations): int a = ∅; //empty set, same as "= void" int[] b = [1,2,3,4,5,6]; a = readInt(); Hum, interesting example, it actually made me realize that 'null' would be an ideal candidate for having a Unicode symbol of it's own. Does anyone have suggestions for a possible one? Preferably somewhat circle-shaped. auto Ø = null; // \Ø I assume you're not serious...
Re: Adding Unicode operators to D
Sergey Gromov wrote: Thu, 23 Oct 2008 18:21:18 +0800, davidl wrote: Everything you worry about is just poor editor. Why do you think an editor can affect the language? I think an editor is not the only thing that displays your program's source. I think that compiler's error message should be readable over a TTY terminal. Otherwise you're limited to working with fancy graphical shells. I agree. My real world experience: Sometimes I need to code over ssh. The server admin only installed vim (which I don't use) and nano, no emacs. Probably there could be a vim module also (is it possible?), but that's just palliatives.
Re: Adding Unicode operators to D
Andrei Alexandrescu wrote:
Please vote up before the haters take it down, and discuss:
http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/
Andrei
I suggest not. There are problems if you adopt Unicode as operators:
==
1) My editor supports Unicode, but my keyboard don't. So how do I type ∩
and ∪ for a set«T»?
1.1) What if the library writer forget to provide an alternative,
ASCII-only name? [This is also a problem of using Unicode as identifier
as general.]
1.2) Some suggested auto-correction in the IDE. Again what if I used
notepad/nano/TextEdit to code?
I had suggested once before, but let me put it formally here. If you
really want to support Unicode operators in source code,
- Firstly, ditch the ability to replace \xxx with '\xxx' when it
appears without the quotes (so “char x = \n;” won't compile).
- Then, replace \xxx with the character represented in source level, so
Vector3D«real» τ = r × F;
can be written as
Vector3D!(real) \τ = r \× F;
- You don't need to introduce a separate trigraph.
- But suggestion do trigger some people's trigraph-phobia. [Yell no!
Now! :) ]
- It may make the source code difficult to parse grammatically.
- It will make the source code difficult to read, just look at the
number of semicolons in the ASCII encoded version.
- But at least you can compile your code.
==
2) This is regarding the rejection of « & » to be supported even if the
emacs module goes official. Of course it turns out it is not, but let's
think of these scenarios:
2.1) OK it turns out ∩ and ∪ and «T» where just .opUnion(x) and
.opIntersect(x) and !(T) pretty-printed in emacs; the compiler won't
accept these characters anyway. But sometimes I forgot and just copied a
portion of these code to nano/geany/whatever and then it stops compiling!
2.2) Well this copy&paste problem has been solved in the IDE level by
inverting the pretty printing while copying. But now I publish my
fantastic, pretty-printed D program in a web page/PDF/whatever, and
people just complain the compiler won't accept it!
I still believe if you're going to transform D code to Unicode visually,
the compiler must accept these visual replacement as well.
May I also take Mathematica as an example. The programming language
itself uses a heavy load of non-ASCII characters, and the IDE also
pretty-printed them as nice mathematical formulas, but in the “source
code” level they are just escape sequences. So on screen you see
E^(I π) + 1
but in the source code you'll see
E^(I \[Pi]) + 1
However, if you type in “E^(I π) + 1” in a plain .nb file and open with
the Get[] function (think of it as “import xx.d”) it can still correctly
display the result “0”.
==
3) There are over 800 unary or binary operators in Unicode[1]. How are
you going to opXXX all them? Assume your blog entry doesn't mean the
simple “!=” ↦ “≠” transformation.
Use to the C++/C# approach? But I heard that's no good.
==
4) These are regarding if you are going to support overloading for all
these 800 operators, how to define:
4.1) [Big problem] Operator precedence? (One person may want ∧ to mean
the wedge product (so they have higher precedence than + and -) but
another want it to mean logical AND (so lower than + and -).)
4.2) Associativity? How to determine if an operator is left-associative,
right-associative or both? (∧ as wedge product is both, while ∧ as a
power function pow(a,b) is right-assoc.)
4.3) [Minor problem] Commutativity? Or we'll need to write opXXX and
opXXX_r all the time?
I don't have solutions for D on these. For 4.2 & 4.3 in C# we can
introduce some attributes like
[Associative, Commutative]
FuzzyBool operator∧ (FuzzyBool x, FuzzyBool y) { return min(x,y); }
(Not actual C# code.)
but it's not D. :)
Or predefine the meaning, precedence and associativity for the each
operator, so e.g. ∧ always means the wedge product and not logical AND,
just like now ^ always means XOR and not power function.
Or just require the programmer to always put the parenthesis.
Ref: [1] A rough word count in
http://www.unicode.org/Public/math/revision-11/MathClass-11.txt. The
actual number is higher than this.
Re: DMD 1.036 and 2.020 releases
Bill Baxter wrote: On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright <[EMAIL PROTECTED]> wrote: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.036.zip The 2.0 version splits phobos into druntime and phobos libraries (thanks to Sean Kelly). This will enable both Tango and Phobos to share a common core library. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.020.zip There are a lot of structural changes that go along with this, so expect some rough patches with this release. It may take a followup release to file them down. There's also some renaming of imports and function names, as a compromise with Tango names. Hooray for progress on mending the Tango/Phobos schism! One question about the D2 release notes. This one doesn't look quite right: OLD NEW import std.array; import core.exception; --bb But http://www.digitalmars.com/d/2.0/phobos/std_array.html got 404'ed, and std/array.d is really removed.
Re: DMD 1.036 and 2.020 releases
Extrawurst wrote: Lars Ivar Igesund wrote: Extrawurst wrote: Walter Bright wrote: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.036.zip The 2.0 version splits phobos into druntime and phobos libraries (thanks to Sean Kelly). This will enable both Tango and Phobos to share a common core library. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.020.zip There are a lot of structural changes that go along with this, so expect some rough patches with this release. It may take a followup release to file them down. There's also some renaming of imports and function names, as a compromise with Tango names. Sounds great ! But why is it that since 2.020 i cannot name a package "shared" anymore? moudle shared.foo; dmd: "Identifier expected following module" WTF ? Because shared is now a keyword. Ok, what is it for ? Where is it documented ? Or is it another reserved keyword like "macro" is ? shared & unshared memories for parallel computing IIRC.
