On 28/11/13 22:01, Fra wrote:
> What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective.  A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

On 2013-12-04 08:32:15 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-12-04 04:47, Michel Fortin wrote:
> 
>> - it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a
>> different runtime which requires different codegen, and Apple has been
>> phasing out 32-bit for some time already
> 
> BTW, is there much difference between the modern runtime for 32bit and 64bit? I'm thinking, is things like the optimization of using the pointer for storing the data for types like NSNumber used on 32bit with the modern runtime?

The pointer magic for NSNumber is pretty much inconsequential: it just means you need to use the runtime functions everywhere, such as objc_getClass to get a pointer to the class object instead of dereferencing the object yourself. But it's a detail to keep in mind.

A big change in the modern runtime is that classes are completely non-fragile, in that you can add a member in a superclass without breaking binary compatibility with derived classes. Which means that instance variables are accessed differently, by checking a global constant to find the right offset (initialized when first loading the class). I think the compiler also has to emit that constant that the runtime will initialize.

Another big change is exception handling which now piggyback on the C++ exception mechanism instead of using the inefficient longjump implementation of the previous runtime.

There's an optimized path for calling certain methods using a virtual table, but we can skip that in a first release as it's an optimisation (objc_msgSend still work fine in every case).

Beside that, they changed all the section names for the binary output, and probably did a some alterations to the binary structure I'm forgetting right now.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Wednesday, 4 December 2013 at 09:31:06 UTC, Manu wrote:
> On 4 December 2013 19:24, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2013-12-04 10:12, Iain Buclaw wrote:
>>
>>  Forget templates and everything else...
>>>
>>
>> Then it's not complete, just as I said.
>
>
> In a sense. But I don't think the goal is to be able to write C++ code in
> D. It's just to achieve binary compatibility.
> Templates in C++ must be declared in header files, and are rarely present
> in libs. You almost never link a template instance.
> In the extremely rare event that you want to (I've never wanted to), it's
> not inconceivable that an extern(C++) template with super-restrictive
> template parameter rules could be made to mangle the same as C++, and then
> it truly would be complete :)
> I personally have no use for this though... but it's probably technically
> possible.

In Windows you have COM and now WinRT as a C++ ABI of some sort,
what about all the other platforms?

--
Paulo

On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:
> ...

Can you address proposal to move all such functions into UFCS instead? What are possible issues in your opinion as compared to declaring them as final inside class?

On 04/12/13 14:22, Dicebot wrote:
> Can you address proposal to move all such functions into UFCS instead? What are
> possible issues in your opinion as compared to declaring them as final inside
> class?

This was discussed at length previously, so it may be an idea to search the archives for the original debate.

The killer argument really came down to two points -- of which I'd say the second was the one that really swung it:

    * Performance -- with virtual-by-default, we also have slower performance
      by default.  Users who casually try out D will probably be put off by this
      and not bother to explore far enough to realize they have to use "final"
      to get better performance.

    * Breaking changes -- with final by default, if you accidentally forget to
      mark a method as virtual, you can correct this without affecting
      downstream users.  By contrast with virtual by default, if you incorrectly
      forget to mark a method as final, you can't correct it later without
      potentially breaking downstream code.

The latter argument is explained in some detail in an interview with one of the main C# designers, discussing why they went for final-by-default in their class design.

Wow, this topic went far more ahead of what I originally expected. Nice!

A nice idea that came out is that we should create some form of kickstarter for bigger projects (AA, GDC & LGD, formal specification of the language, may I add in ddmd?). Anyone here willing to take this responsibility?

I would step in but I'm a D newbie, I would have no idea about the work required to fix stuff or to get better support for the gcc and llvm backends. I'm just an entusiast but I've been playing with D and following the language for 2 years, give or take. I have now a chance to try it in for a bigger project so I'm "more concerned" about development and support of the language.

On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling wrote:
> On 28/11/13 22:01, Fra wrote:
>> What would your choice be?
>
> A really good overhaul of the website, forums etc. from a UI/UX perspective.  A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1

I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/

Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.

On Wednesday, 4 December 2013 at 08:01:25 UTC, Manu wrote:
> Indeed. I think it's very safe to say that any un-maintained code already won't compile. This isn't the first, or even the greatest in magnitude breaking change that there's been recently.

Actually, a lot of my old code still compiles, and part of the reason is a lot of it is written in a more Java style than using the fancier, more likely to change features....

Though, to tell you the truth, I'm not sure just how many methods I've overridden in child classes. There's definitely some but probably not a huge number (at least excluding interfaces).

On 2013-12-04 12:43, Michel Fortin wrote:

> The pointer magic for NSNumber is pretty much inconsequential: it just
> means you need to use the runtime functions everywhere, such as
> objc_getClass to get a pointer to the class object instead of
> dereferencing the object yourself. But it's a detail to keep in mind.
>
> A big change in the modern runtime is that classes are completely
> non-fragile, in that you can add a member in a superclass without
> breaking binary compatibility with derived classes. Which means that
> instance variables are accessed differently, by checking a global
> constant to find the right offset (initialized when first loading the
> class). I think the compiler also has to emit that constant that the
> runtime will initialize.
>
> Another big change is exception handling which now piggyback on the C++
> exception mechanism instead of using the inefficient longjump
> implementation of the previous runtime.
>
> There's an optimized path for calling certain methods using a virtual
> table, but we can skip that in a first release as it's an optimisation
> (objc_msgSend still work fine in every case).
>
> Beside that, they changed all the section names for the binary output,
> and probably did a some alterations to the binary structure I'm
> forgetting right now.

What I actually was asking is if there's any difference in the 32bit modern runtime as used by iOS and the 64bit modern runtime? Except for the usual differences that exists in C.

-- 
/Jacob Carlborg

On 12/4/13 6:12 AM, Daniel Davidson wrote:
> On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling
> wrote:
>> On 28/11/13 22:01, Fra wrote:
>>> What would your choice be?
>>
>> A really good overhaul of the website, forums etc. from a UI/UX
>> perspective.  A good number of the problems we have with D aren't
>> problems with the language or libraries, they're problems with people
>> finding the right information on how to work with D.
>
> +1
>
> I'd pay to see vibe.d entered in this:
> http://www.techempower.com/benchmarks/
>
> Notwithstanding the gaming that goes in benchmarking, I think not being
> present is a missed opportunity.

If you're willing you pay you may want to contact them.

Andrei