On Tuesday, 2 June 2015 at 08:06:16 UTC, deadalnix wrote:
> That would be even greater if they would be chained ! What a debug tool we could get out of this ! I know ! We should call them "stack traces" ! Catchy !

A stack trace is a dump of activation records, yes. But compile time introspection isn't actually a stack trace.

On Tuesday, 2 June 2015 at 09:18:27 UTC, ketmar wrote:
> ugly js. this is so bad that i believe that we will live with that for many years

Possibly, but whatever is available on dominant browsers will be used. I many situations avoiding user-initiated installs are desirable. In most, actually...

On Tuesday, 2 June 2015 at 10:18:59 UTC, ketmar wrote:
> On Tue, 02 Jun 2015 09:44:24 +0000, Paulo  Pinto wrote:
>
>> Thankfully mobile OSes and desktop app stores seem to be on the right
>> track to kill this.
>
> yet they pushing cromeos and firefoxos...

FirefoxOS is going nowhere.

http://www.cnet.com/uk/news/mozilla-overhauls-firefox-smartphone-plan-to-focus-on-quality-not-cost/

As for Chromebooks, at least in Germany they are gathering dust on the few stores that bother to try to sell them.

They might be on the Amazon US top charts, but I bet most of its users are GNU/Linux users, wiping ChromeOS and using GNU/Linux instead.

On Tue, 02 Jun 2015 10:37:40 +0000, Ola Fosheim Grøstad wrote:

> On Tuesday, 2 June 2015 at 09:18:27 UTC, ketmar wrote:
>> ugly js. this is so bad that i believe that we will live with that for many years
> 
> Possibly, but whatever is available on dominant browsers will be used. I many situations avoiding user-initiated installs are desirable. In most, actually...

and there was a thing that allows to use real applications without installing them... java web start! way too ahead of it's time, though...

On Tuesday, 2 June 2015 at 13:37:47 UTC, ketmar wrote:
> and there was a thing that allows to use real applications without
> installing them... java web start! way too ahead of it's time, though...

Java got itself a bad reputation in the 90s by providing a really poor implementation.

The situation that is emerging now is that you can integrate different browser technologies, and that browser vendors cooperate, and that makes all the difference.

On Tue, 02 Jun 2015 13:43:29 +0000, Ola Fosheim Grøstad wrote:

> The situation that is emerging now is that you can integrate different browser technologies, and that browser vendors cooperate, and that makes all the difference.

except you can't really integrate browser techs in your program, but you are required to integrate your program into browser. ;-)

On Tuesday, 2 June 2015 at 14:01:48 UTC, ketmar wrote:
> On Tue, 02 Jun 2015 13:43:29 +0000, Ola Fosheim Grøstad wrote:
>
>> The situation that is emerging now is that you can integrate different
>> browser technologies, and that browser vendors cooperate, and that makes
>> all the difference.
>
> except you can't really integrate browser techs in your program, but you
> are required to integrate your program into browser. ;-)

https://github.com/domokit/mojo

On 2015-06-02 08:32, Jonathan M Davis wrote:

> D's semantics for __FILE__ and __LINE__ are so much better than C++'s. I
> sorely miss D's semantics for them whenever I'm in C++. Having them get
> the values from the call site rather than the declaration site is so
> much more useful that it's not even funny.

Yeah, it's pretty cool. Swift also evaluates them in the same way as D, they even credited D in their blog post :)

-- 
/Jacob Carlborg

On 06/01/2015 01:08 AM, Paulo Pinto wrote:
> On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:
>> On 1 June 2015 at 10:56, ketmar via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> On Sun, 31 May 2015 09:08:27 +0000, Joakim wrote:
>>>
>>>> Most mobile games are written in C/C++/OpenGL
>>>
>>> that will fade away soon. it's safe to ignore that in long-time plan.
>>
>> How so? Game dev's aren't moving away from native code any time soon...
>
>   Objective-C, Swift, Java (as of Android 5) and .NET on mobile OSes
> aren't no less native than D.
>
> All of them compile to pure native code. There isn't any VM running on
> the device.
>

That may be technically true, but the elimination of the VM still doesn't eliminate all the VM baggage.

The need for the languages to support their old VMs does still impose restrictions on the language designers, and thus language itself, that wouldn't need to exist had there been no VM at all.

Ex: No matter how aggressively AOT is used, manual memory management and controlling memory layout are still gonna be a royal pain in Java/Android5 and .NET. That's unlikely to go away without deprecating support for the VMs. But it IS likely to become more and more of a problem for those languages with performance being increasingly sensitive to data layout. Good news for D though ;)

On 06/02/2015 07:26 AM, Paulo Pinto wrote:
> On Tuesday, 2 June 2015 at 10:18:59 UTC, ketmar wrote:
>> On Tue, 02 Jun 2015 09:44:24 +0000, Paulo  Pinto wrote:
>>
>>> Thankfully mobile OSes and desktop app stores seem to be on the right
>>> track to kill this.
>>
>> yet they pushing cromeos and firefoxos...
>
> FirefoxOS is going nowhere.
>
> http://www.cnet.com/uk/news/mozilla-overhauls-firefox-smartphone-plan-to-focus-on-quality-not-cost/
>
>
> As for Chromebooks, at least in Germany they are gathering dust on the
> few stores that bother to try to sell them.
>
> They might be on the Amazon US top charts, but I bet most of its users
> are GNU/Linux users, wiping ChromeOS and using GNU/Linux instead.

Yes. That's also part of why I don't have much expectation for Taizen, either. It would already have enough of an uphill battle even if the technical aspect was total 100%. But by promoting HTML5-for-apps, they might very well be riding the wrong end of a last-decade fad.