On Tuesday, 23 June 2015 at 11:37:41 UTC, Suliman wrote:
> Am I right understand that web assembly would not completely new technology and would be just evolution of asm.js, so all of webassembly apps would run in old javascript virtual machine?

They covered this question in the FAQ, too:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs

On Tuesday, 23 June 2015 at 11:41:03 UTC, Wyatt wrote:
> On Tuesday, 23 June 2015 at 11:37:41 UTC, Suliman wrote:
>> Am I right understand that web assembly would not completely new technology and would be just evolution of asm.js, so all of webassembly apps would run in old javascript virtual machine?
>
> They covered this question in the FAQ, too:
> https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs

I can't understand what I will see if I open HTML page? Would it's classical HTML page with import of some binary on top of it or what?

On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:

>
> As for a GC, why would webasm need to provide one?  I'd think the languages would just be able to compile their own GC to webasm, which seems low-level enough.
>

From the docs:

 Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated (1, 2, 3). However, "compile the VM" strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser.

Nick, you might be interested in this quick thing I just wrote up:

http://arsdnet.net/articles/web-apps.html

A few years ago, I was talking about a new windowing system... and believe it or not, I'm still slowly moving forward with it, but I think existing X is good enough to start with for this idea.

My old thing was about thin clients used through the web. Well, I like downloading programs too sometimes, can we solve that problem? Web apps do an ok job, so do app stores. Let's get the best of both worlds: download a program that targets a standard Linux VM distributed with browsers. I go into a bit more detail in the link.

On 06/23/2015 07:09 AM, Joakim wrote:
>
> But if you have some emotional connection with the term "desktop" and
> can't take the fact that they're being rendered defunct, I can see why
> you'd want to ignore all that and just call the new devices "converged"
> or "desktops." :)
>

As opposed to someone with an emotional connection with the term "smartphone" and can't take the fact that what such devices are turning into is not what they used to be and that they're getting there by borrowing from an old uncool "outdated" style of computing ;)


>> I've done so already. It's absolutely terrible. At best, it's an
>> occasional replacement for those already-horrid
>> mini-touchscreen-keyboards (which almost anything is better than).
>
> I've been surprised on the few occasions I used google's voice
> translation about how good it was, but I haven't use it much.
>

It's much better than I expected too, but even still, approx 50% of the time I use it (50% is NOT an exaggeration here) I end up having to go back and edit its mistakes. Plus it's laggy because of yet another problem: It works by sending everything the mic hears straight to Google. So much for end-to-end encryption/privacy.

And then here's the one that isn't even conceivably fixable by technological improvements: I've found that oftentimes, dictation is just isn't a very natural fit for your mental process, even if it does work flawlesly.

I know that's somewhat vague, because it's difficult to explain. but I'll put it this way: Dictation is almost like the "waterfall model" of text entry. Versus a keyboard being more naturally suited to iterative refinement, and working out how you want to word something. Sure, you can do that with voice, but it's less natural. (That's actually part of why I prefer email to telephone calls for business and technical communications.)

On 06/23/2015 09:44 AM, Adam D. Ruppe wrote:
> Nick, you might be interested in this quick thing I just wrote up:
>
> http://arsdnet.net/articles/web-apps.html
>
> A few years ago, I was talking about a new windowing system... and
> believe it or not, I'm still slowly moving forward with it, but I think
> existing X is good enough to start with for this idea.
>
> My old thing was about thin clients used through the web.

Yea, totally! Actually, that windowing system of yours has been in the back of my mind whenever I think of "web apps" for the past several years since you first put it up.

Although I wouldn't put too much reliance on X, what with Wayland on the way.

> Well, I like
> downloading programs too sometimes, can we solve that problem? Web apps
> do an ok job, so do app stores. Let's get the best of both worlds:
> download a program that targets a standard Linux VM distributed with
> browsers. I go into a bit more detail in the link.

Yea, I'll have to take a closer look at that. My first impression is that "Linux VM" sounds very heavy-weight, but I supposed it need not necessarily be.

On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
> Although I wouldn't put too much reliance on X, what with Wayland on the way.

meh, wayland doesn't look very interesting to me, especially in this use case where I'd want a network protocol because the application runs on an isolated VM and needs to communicate with the host somehow.

> Yea, I'll have to take a closer look at that. My first impression is that "Linux VM" sounds very heavy-weight, but I supposed it need not necessarily be.

Well, keep in mind that I want to kill the browser, which is already very heavy-weight!

Firefox is like 80 MB.... http://www.tinycorelinux.net/downloads.html that's 9 MB and probably more than the browser VM would need! The core system should be sharable without copying the file every time, and its only job is to run one program, providing it a familiar, consistent base api. I don't think the weight would be much of a problem, though perhaps it might be on the mobile sphere.

On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:
> On Monday, 22 June 2015 at 16:34:58 UTC, Ola Fosheim Grøstad wrote:
>> People are already writing less javascript, but without a GC in webasm most languages are better of compiling to javascript or a mix.
>
> The problem is that they may be writing less javascript now, but they're still stuck with the performance of javascript, as they're just compiling to javascript.  Webasm making that faster and allowing more languages should change that equation much more.

asm.js/Webasm is more restricted. Those restrictions basically tells the JIT that the code has already been optimized, doesn't need higher level support and it can be translated into machine language as is...

Although I don't think javascript is the bottle neck at the moment. I think the layout and render engine is.

> As for a GC, why would webasm need to provide one?  I'd think the languages would just be able to compile their own GC to webasm, which seems low-level enough.

That would be difficult to get right.

> This is nonsense.  They're just dumping in everything they can think of, that has nothing to do with backwards-compatibility.

Web tech is pretty good at backwards-compatibility. Not sure why anyone would argue against that.

>> I think the vendors have realized that they need to take babysteps in concert, because there is to much politics involved to accept a "whole-sale solution" like PNACL etc.
>
> PNaCl is bitcode too.

From one party. So it did not get adopted.

> That doesn't answer the question of why they're using a bitcode and not a textual IR, as you prefer text for SVG.

Because we don't edit the IR.

On 06/23/2015 12:36 PM, Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
>> Yea, I'll have to take a closer look at that. My first impression is
>> that "Linux VM" sounds very heavy-weight, but I supposed it need not
>> necessarily be.
>
> Well, keep in mind that I want to kill the browser, which is already
> very heavy-weight!
>

Very true. Fair point.

> Firefox is like 80 MB.... http://www.tinycorelinux.net/downloads.html
> that's 9 MB and probably more than the browser VM would need!

ABout 99% of the time, my browser (FF) is soaking up anywhere from 1-1.5GB of RAM. By far the biggest memory hog on my system (at least when I don't have a Windows VM or something running).

Well, there is one other exception though: After switching my main desktop to Linux, I found that my favorite editor (Programmer's Notepad 2) has some issues under Wine, so I've been using a lot of Komodo Edit. Unfortunately, among other big annoyances, Komodo seems to have some serious memory leak issues because it's ram usage only ever grows, never shrinks (not even if I close ALL files), and after only a few days it'll hit 1GB+ ram as well, and then start pausing/lagging like crazy. Ugh.

I'm trying Kate now. Actually seems to have grown up from an "MS Notepad for KDE" to a fully legitimate code editor since the last time I really looked closely at it (back in KDE3 days). Seems quite promising so far.

> The core
> system should be sharable without copying the file every time, and its
> only job is to run one program, providing it a familiar, consistent base
> api. I don't think the weight would be much of a problem, though perhaps
> it might be on the mobile sphere.

If the weight is a problem on mobile, that would unfortunately be a deal-breaker. Mobile web is every bit as important as desktop web these days, and will likely only grow further.

On Tuesday, 23 June 2015 at 16:36:21 UTC, Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
>> Although I wouldn't put too much reliance on X, what with Wayland on the way.
>
> meh, wayland doesn't look very interesting to me, especially in this use case where I'd want a network protocol because the application runs on an isolated VM and needs to communicate with the host somehow.
>

I'm not sure of your use case, but wayland is clearly a huge step forward compared to X. Take it from someone that have messed up with both.