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 bearophileh...@lycos.com 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 nos...@nospam.com 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: 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.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: 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
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 \times; and \empty; so we could reuse them in source code level as I've described somewhere in this thread. auto torque = position \times; 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 \circ; 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: 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; // \Oslash; I assume you're not serious...
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.
