headers
Bill Baxter | 1 Dec 2009 01:09
Picon
Gravatar

Re: dynamic classes and duck typing

On Mon, Nov 30, 2009 at 3:38 PM, bearophile <bearophileHUGS <at> lycos.com> wrote:
> Walter Bright:
>> So am I. It seems to be incredibly powerful.
>
> Very powerful things can be dangerous too, they can lead to bugs, etc.

I'm a bit concerned about what this does to introspection.
With a dynamic language like Python, adding runtime methods does not
interfere with your ability to enumerate all the methods supported by
an object.
With this opDispatch it's no longer possible for the compiler to know
what list of methods a class responds to.

So unless we add some way for a class to enumerate such things,
opDispatch effectively kills any introspecting that requires knowing
everything in a class.

So that would make things like automatic wrapper generation difficult.
 And automatic mock classes.  Anything else that requires enumerating
methods?

Also how does this interact with property syntax?

--bb
Permalink | Reply | 0 comments |
headers
Walter Bright | 1 Dec 2009 01:07
Favicon

Converting Optlink from Assembler to C - Reboot

http://www.reddit.com/r/programming/comments/a9mse/walter_bright_from_assembly_to_c/

Hopefully a working link this time.
Permalink | Reply | 2 comments |
headers
Bill Baxter | 1 Dec 2009 01:19
Picon
Gravatar

Re: dynamic classes and duck typing

On Mon, Nov 30, 2009 at 3:20 PM, Alvaro Castro-Castilla
<alvcastro <at> yahoo.es> wrote:
> Walter Bright Wrote:
>
>> Simen kjaeraas wrote:
>> > I'm already in love with this feature.
>>
>> So am I. It seems to be incredibly powerful.
>>
>> Looks to me you can do things like:
>>
>> ...
>>
>> 5. the already mentioned "swizzler" functions that are generated at
>> runtime based on the name of the function

And once again we see Clugston's Law at work.  As soon as you figure
out how to do one thing in D, a new compiler feature comes along that
makes it a one-liner.  :-)

--bb
Permalink | Reply | 0 comments |
headers
Alvaro Castro-Castilla | 1 Dec 2009 01:19
Picon
Picon
Favicon

Re: dynamic classes and duck typing

Walter Bright Wrote:

> Simen kjaeraas wrote:
> > It would seem Walter is right, but only for opDispatch. This compiles
> > fine. If you want compile errors, move the ellipsis around:
> 
> Hmm, looks like there is a problem, but it has nothing to do with 
> opDispatch, as this:
> 
>      void bar(string s, T...)(T args)
> 
> doesn't work either.

I think this doesn't work as should. This code:

struct foo {
    void opDispatch( string name, T... )( T values... ) { 
        pragma(msg,values);       // ...shows "tuple()" 
        writeln(values);                  // ...shows nothing at runtime
        foreach(v;values) {            // ...idem
            writeln(v);
        }   
    } 
}

void main( ) { 
    foo f;
    f.bar( 3.14, 6.28 );
}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam D. Ruppe | 1 Dec 2009 01:39
Picon

Re: Converting Optlink from Assembler to C

On Mon, Nov 30, 2009 at 10:14:32PM +0000, Spacen Jasset wrote:
> The article doesn't really say why optlink?

That's not really the point though - the article is discussing "how" rather
than "why".

> Why not use another linker? 

Speed is a big one, but I imagine familiarity is another - Walter has
worked with optlink for a lot of years and surely knows it very well.

--

-- 
Adam D. Ruppe
http://arsdnet.net
Permalink | Reply | 0 comments |
headers
Adam D. Ruppe | 1 Dec 2009 01:44
Picon

Re: dynamic classes and duck typing

On Mon, Nov 30, 2009 at 02:02:46PM -0800, Walter Bright wrote:
> 3. add methods to existing classes (monkey patching) that allow such 
> extensions

I think allowing this in general is a bad idea - the opDispatch should
only be implemented on a small number of classes.

The reason is simple: a typo in a method name should be a compile time error
the vast majority of the time.

If opDispatch was implemented all over the place, allowing random runtime
extensions, the error is put off until runtime.

I'm for having the feature - I just don't think it should be used very often.

To add methods to existing classes at compile time, the way I'd love to
see it done is:

void newMethod(SomeClass myThis...)  myThis.whatever...{ }

SomeClass a;
a.newMethod(); // rewritten as newMethod(a)

--

-- 
Adam D. Ruppe
http://arsdnet.net
Permalink | Reply | 0 comments |
headers
bearophile | 1 Dec 2009 01:35
Picon

Re: Converting Optlink from Assembler to C - Reboot

A nice article, thank you for writing it for us for free (I used to pay to read similar texts).

>I had the job at the time of converting a huge (and very successful) electronic schematic editor, DASH,
from assembler into C. In C it could then be recompiled for 32 bits, and even ported to other platforms like
the Sun workstations. The conversion took months, but was a big success.<

Sounds like a so much bug-prone job that the probability of having a final working product seem small. I
guess you have translated it part-by-part, keeping it functional all the time, as you are doing with optlink.

>9. Optlink has no unit tests. Writing them would require understanding what the various functions do, and
I won't know precisely what they are supposed to do until most of the program is converted.<

Translating a largish program from a language to a different language is a good way to convince most
programmers that unit tests are a Good Thing. Unit tests make this work quite simpler. And many good
programs eventually need to be translated, it's not an uncommon event.

>Although I have not run any speed tests, I expect the performance of the non-I/O bound code to be about 30%
slower. Since a linker tends to be I/O bound, the actual performance loss probably will be about 10%, which
I can live with.<

We'll see. Modern C compilers, like the Intel one, LLVM or GCC 4.4 sometimes give surprises :-) Modern C
compilers also use CPU instructions that were not available in the past (you have to use compilation flags
for Pentium4/Core2 or similar CPUs of course).

>The difference in object code size is primarily due to the assembler having done register assignments
that cross over multiple function calls. There's just a lot less pushing and popping of parameters.<

In GCC there are annotations (that LLVM doesn't support yet) that allow to nail variables into registers.
One Haskell compiler (GHC) uses this feature a lot, it's explained here:
http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf
(Continue reading)

Permalink | Reply | 1 comment |
headers
4tuu4k002 | 1 Dec 2009 02:01
Picon
Favicon

Unofficial wish list status.(Dec 2009)


Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

I am closing this wish list. 
New requests should be posted to bugzilla on http://d.puremagic.com/issues/

It would be a great help, 
if you could help move some of the wish list items to bugzilla.
But please use the same title, so it is easy to avoid duplication.

Right now the wish list looks like this:

212  Stack tracing (#26)
202  Reflection API (#6)
133  vectorization (#10)
114  Multiple return values (tuples (#28)
103  Multiple opCast per class (#24)
97  Debug check for null reference (#52)
90  Native AMD64 codegen (#36)
80  !in (#44)
79  Short syntax for new (#18)
77  unit test after compilation (#1)
71  extra compiler values (#19)
67  Return-type overloading (#49)
58  Explicit out/inout (#38)
56  Foreach on first/on last (#42)
54  Unit test isolation  (#2)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don | 1 Dec 2009 02:22

Re: new version

l8night wrote:
> hi,
> thank you all for your answers. i think your are right with “look for the severity of bugs”. for my
superiors however the thing is different. they just see a huge amount of bugs, missing gui libraries,
missing database libraries and nothing close to anything that m$ offers in the way of development. than
there are 2 libraries, one with no collections and no way they seem to come together. There is no
advertising (such as go language) and seemingly slow updates (bug fixes).
> and for me - shit if this doesn’t change somehow to the better, i end up doing the next tool/project in
delphi instead of D2.
> and that sucks, since i at least got them to think about D.

Yes, that's always been a problem. But it seems there'll be only a 
couple more releases before there is a feature-complete D2 release. Once 
that happens, we'll stop having bugs due to newly-introduced features. 
Also, now that the severe bug count has dropped so much, it's getting 
easier to deal with the minor ones.
Obviously there's still a very long way to go.

> 
> dsimcha Wrote:
> 
>> == Quote from BCS (none <at> anon.com)'s article
>>> Hello l8night,
>>>> Too many bugs - no way my superiors allow some program with that bug
>>>> list and the open date for version 2. worst is the slow bugfixes.
>>>>
>>> Check me on this but there may be more know bugs in things like FireFox then
>>> in DMD. The length of the bug list in and of its self say almost nothing
>>> about a program. (OTOH it makes a handy metric for people who don't know
>>> that.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
bearophile | 1 Dec 2009 02:26
Picon

Re: Phobos packages a bit confusing

Andrei Alexandrescu:
> Why not just reuse the same buffer as the previous line? That approach 
> is inherently adaptive.

That approach is unsafe. xfile yields byte strings, in D1. When I write 10 lines long scripts I usually don't
need every bit of optimization, I need the less bug-prone code as possible, because the thing I have to
optimize is my coding time. In D1 strings are mutable, so if you put them in an AA as keys you must dup them to
avoid bugs if you reuse the same buffer.

>And why is there a need for xstdin vs. xfile? Stdin _is_ a file.<

I use it like this:
foreach (line; xstdin) { ... }
line is a string with newline at the end.
I know this isn't the best design, but it's the most handy for my purposes. I need to do a limited number of
things in those scripts and iterating over the lines of a fine and over the lines of the stdin are the only two
that matter.

Bye,
bearophile
Permalink | Reply | 14 comments |

Gmane