Re: [fpc-pascal] WebAssembly Target

[Reimar Grabowski]

On Wed, 12 Apr 2017 08:49:08 -0500
nore...@z505.com wrote:

> Why run webgl through javascript if you could just make something like a 
> flash plugin object (like youtube videos) that plays opengl scenes using 
> some native format similar to how flash uses SWF files, or whatever?
First of all you don't run anything through anything. Web/OpenGL (ES) are in 
effect just a bunch of commands sent to the driver. It is not really impacted 
by the language from where you call it. It is just a graphics library 
Second OpenGL scenes are not played, they are interactive.
Third people don't want to deal with (buggy) plugins they want sh!t that just 
works across browsers.

> It seems like almost the web browser is trying to become Emacs, 
> everything and the kitchen sink, though...
Maybe, but "direct" (yeah I know it's not really direct, that's what Vulcan is 
for) access to your graphics card inside the browser is IMHO a nice feature.
 
> If it includes opengl or webgl, and video players
That's what your graphics card/chip gives you even on low end systems like the 
pi out of the box, so why not expose this inside the browser?

> under the sun.. it makes me wonder whether we should really not be going 
> back to exe's again... I.e. if you want to download a opengl 
> application, you just download an exe/elf program instead of running it 
> in the web browser ;-)
Only that the stuff in the browser seldom is what you call an OpenGL 
application (whatever that term means) and as noted above people are not going 
to download apps for stuff like this.
Examples:

https://arachne.dainst.org/3d?id=2
http://www.chaostoperfection.com/
http://www.zamaniproject.org/index.php/ethiopia-3d-model-of-medhane-alem.html
http://cabinetdecuriosites3d.mnhn.fr/fr/content/cro-magnon-1-homo-sapiens
http://vcg.isti.cnr.it/3dhop/demos/capsella/index_capsella.html

R.

Btw, all the links above will infect your computer with all kinds of nasty 
malware. Clicking them will kill every first-born egyptian child, etc
You have been warned, so go there on your own risk
 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-20 um 10:25 schrieb Graeme Geldenhuys:
> On 2017-04-14 09:41, Jürgen Hestermann wrote:
>> I hate Java Script and use NoScript to block it.
> You don't need a browser add-on for that. Simply go to (Firefox)
> about:config and search for JavaScript. Double click the
> "javascript.enabled" preference and it will toggle between enabled
> true/false.

But NoScript has comfortable functions do allow scripting
for certain web pages or even only parts of them
in case I am forced to use scripting on "special" cases.
I can do a white-listing this way.
It seems that about:config cannot distinguish between
special web pages.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-04-14 18:56, Jürgen Hestermann wrote:
> Therefor I use NoScript to prevent me from such code.
> 90% of these web pages using scripting are crap anyway.

It's also nice to see how fast web pages load if no JavaScript is
enabled (magnitudes faster). Also most web Ads stop working too. A nice
bonus. :)

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-04-14 09:41, Jürgen Hestermann wrote:
> I hate Java Script and use NoScript to block it.

You don't need a browser add-on for that. Simply go to (Firefox)
about:config and search for JavaScript. Double click the
"javascript.enabled" preference and it will toggle between enabled
true/false. There used to be days (years ago) when this setting was
directly available in the Preferences dialog. Good old times. ;-)

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 14.04.2017 10:41, Jürgen Hestermann wrote:

I can't understand why scripting is needed for a web page.
Regarding the discussion here, the term is "Rich Internet Application" 
("RIA") -> https://en.wikipedia.org/wiki/Rich_Internet_application


Here, a server based application (e.g. done in Pascal / fpc / Lazarus) 
shows a GUI within a browser. The connection between the Browser and the 
program being done via a standard HTTP server.


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Fri, 14 Apr 2017, Jürgen Hestermann wrote:


Am 2017-04-13 um 10:20 schrieb Michael Schnell:
> So at the moment HTML5 and Java script is the way to go, but WebAssembly 
should recreate Action Script versatility performance in a more "Standard" 
way.


I hate Java Script and use NoScript to block it.
I can't understand why scripting is needed for a web page.


Simple: to improve the user experience. 
Things like google calendar would be impossible without it.


Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Jürgen Hestermann]

Am 2017-04-13 um 10:20 schrieb Michael Schnell:
> So at the moment HTML5 and Java script is the way to go, but WebAssembly should 
recreate Action Script versatility performance in a more "Standard" way.

I hate Java Script and use NoScript to block it.
I can't understand why scripting is needed for a web page.

Once I could do even my home banking without scripting
but meanwhile scripting spreads over all the internet.
For security reasons this is a desaster and
I never found anything useful with scripting.

The most annoying thing with scripting is, that you potentially
download arbitrary code with every click.
A browser should only display information but never execute
arbitrary code from a web site.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 12.04.2017 15:49, nore...@z505.com wrote:


Why run webgl through javascript if you could just make something like 
a flash plugin object


We once did a decent application using Pascal at the server and Flash 
(Action Script) at the client site. Works very nicely. But Action Script 
is Adobe propriety and even Adobe says that Flash is depreciated. So at 
the moment HTML5 and Java script is the way to go, but WebAssembly 
should recreate Action Script versatility performance in a more 
"Standard" way.


-Michael

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Sven Barth via fpc-pascal]

Am 12.04.2017 16:10 schrieb :
> Why run webgl through javascript if you could just make something like a
flash plugin object (like youtube videos) that plays opengl scenes using
some native format similar to how flash uses SWF files, or whatever?

Because the point is not to need some strange, obscure plugin that works
only on a subset of the platforms the browser supports when the script
engine of the browser is powerful enough to do it itself.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[noreply]

On 2017-03-17 09:57, Reimar Grabowski wrote:

On Thu, 16 Mar 2017 11:14:17 +
Graeme Geldenhuys  wrote:


And I am pleasantly surprised! :)  That demo worked perfectly on my
system. Sound, animation, graphics all silky smooth. Impressive 
indeed.


If running a 3 year old iOS Demo in a browser when we have seen Unreal
Tournament 3 being playable there 4 years ago is impressive is
debatable.
For me the impressive thing is that FireFox with WebAssembly manages
to show the same performance as Chrome without it. Having them run
side by side both fullscreen I can see no performance difference at
all.
Perhaps the JS side is doing so little that it hardly matters (as it
should be, when doing WebGL you want to do as much on the GPU as
possible).
First benchmarks indicate that there isn't much of a performance
increase with the current WebAssembly implementation over pure JS
anyway.
The benefit is that you can 'run C code' in the browser and that's 
currently it.

Having a WebAssembly target for FPC would surely be nice (more
options) but hardly a game changer currently.
In my little experience with WebGL the JS performance was never that
big of a problem but getting lots of data into the browser without the
transfer being super slow or the browser consuming alot more memory
than it should.



Why run webgl through javascript if you could just make something like a 
flash plugin object (like youtube videos) that plays opengl scenes using 
some native format similar to how flash uses SWF files, or whatever?


I think there was some opengl plugin object, but can't remember...

It seems like almost the web browser is trying to become Emacs, 
everything and the kitchen sink, though...


If it includes opengl or webgl, and video players, and.. everything 
under the sun.. it makes me wonder whether we should really not be going 
back to exe's again... I.e. if you want to download a opengl 
application, you just download an exe/elf program instead of running it 
in the web browser ;-)


Still, web browser (abuse syndrome) apps are cool.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 17.03.2017 15:57, Reimar Grabowski wrote:
First benchmarks indicate that there isn't much of a performance 
increase with the current WebAssembly implementation over pure JS anyway.


A "decent" Framework will compile both to machine code in an "ahead of 
time" manner, so simple close loops should result in very similar 
performance.


The compiler creating WebAssembly can introduce decent optimization. So 
performance will depend on the Compiler-


Hand written Java Script might be good or bad so performance will depend 
on the author.


It will be interesting to compare the result of the two fpc compilers, 
when available :)


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 17.03.2017 18:54, Michael Van Canneyt wrote:


Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look.
  The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in 
the IDE.
  the necessary CSS will be generated for this. In both modes of 
course the IDE and object inspector will be used to create

event handlers and whatnot in Pascal...


Sounds Great !

Should be independent of compiling it to Java script or to Web Assembly 
(provided decent "Widgets" are provided/usable with WebAssembly: I don't 
know anything about those).


(Is this not more like an issue for the Lazarus community, as they are 
supposed to provide "Widget Type" settings for such targets ? )


-Michael

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Daniel Gaspary]

On Fri, Mar 17, 2017 at 2:55 PM, Michael Van Canneyt
 wrote:
> Forgot to say that there will of course be some classes to manipulate the
> DOM at will.


Thank you, Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Fri, 17 Mar 2017, Daniel Gaspary wrote:


On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt
 wrote:

In fact, there is an alternate approach, transpiling pascal to Javascript.

It's much farther ahead than the webassembly target, already produces
programs running in the browser and the first web-based components are
already being developed using this approach.


What is the role of those components ?

Reading this thread I was thinking would be nice (easier to work) ) to
have access to browser components via a fpc lib.

Something like fcl-browser-facilities (terrible name, I know), where
you could simple calls to DOM parts.


Forgot to say that there will of course be some classes to manipulate the
DOM at will.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Fri, 17 Mar 2017, Daniel Gaspary wrote:


On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt
 wrote:

In fact, there is an alternate approach, transpiling pascal to Javascript.

It's much farther ahead than the webassembly target, already produces
programs running in the browser and the first web-based components are
already being developed using this approach.


What is the role of those components ?


You'll design a web app in the lazarus IDE (or Delphi IDE, for that matter).
The app will be compiled to Javascript.

Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look.
  The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in the IDE.
  the necessary CSS will be generated for this. 
In both modes of course the IDE and object inspector will be used to create

event handlers and whatnot in Pascal...

But this is all still under heavy development.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Daniel Gaspary]

On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt
 wrote:
> In fact, there is an alternate approach, transpiling pascal to Javascript.
>
> It's much farther ahead than the webassembly target, already produces
> programs running in the browser and the first web-based components are
> already being developed using this approach.

What is the role of those components ?

Reading this thread I was thinking would be nice (easier to work) ) to
have access to browser components via a fpc lib.

Something like fcl-browser-facilities (terrible name, I know), where
you could simple calls to DOM parts.

Whether this is already in fcl-js, sorry, I didn't knew about it..
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-17 14:57, Reimar Grabowski wrote:
> Perhaps the JS side is doing so little that it hardly matters (as it
> should be, when doing WebGL you want to do as much on the GPU as
> possible).

A very good point. It was probably all down to WebGL (ie: your GPU)
doing all the work.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Reimar Grabowski]

On Thu, 16 Mar 2017 11:14:17 +
Graeme Geldenhuys  wrote:

> And I am pleasantly surprised! :)  That demo worked perfectly on my
> system. Sound, animation, graphics all silky smooth. Impressive indeed.

If running a 3 year old iOS Demo in a browser when we have seen Unreal 
Tournament 3 being playable there 4 years ago is impressive is debatable.
For me the impressive thing is that FireFox with WebAssembly manages to show 
the same performance as Chrome without it. Having them run side by side both 
fullscreen I can see no performance difference at all.
Perhaps the JS side is doing so little that it hardly matters (as it should be, 
when doing WebGL you want to do as much on the GPU as possible).
First benchmarks indicate that there isn't much of a performance increase with 
the current WebAssembly implementation over pure JS anyway.
The benefit is that you can 'run C code' in the browser and that's currently it.
Having a WebAssembly target for FPC would surely be nice (more options) but 
hardly a game changer currently.
In my little experience with WebGL the JS performance was never that big of a 
problem but getting lots of data into the browser without the transfer being 
super slow or the browser consuming alot more memory than it should.

R.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Fri, 17 Mar 2017, Karoly Balogh (Charlie/SGR) wrote:


Hi,

On Fri, 17 Mar 2017, Michael Van Canneyt wrote:


In fact, there is an alternate approach, transpiling pascal to Javascript.

It's much farther ahead than the webassembly target, already produces
programs running in the browser and the first web-based components are
already being developed using this approach.


I believe these will be complimentary solutions in the end, one will be
better for certain things than the other, with a lot of overlap, of
course. I think the transpiler might be better for developing unique
front-end solutions in Pascal for the web, the WebAssembly compiler might
be better to bring existing large chunks of code to run on the web, with
minimal modifications, and for performance critical things.


Fully agreed, and the "unique front-end solutions in Pascal for the web" is
the intended target.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 17 Mar 2017, Michael Van Canneyt wrote:

> In fact, there is an alternate approach, transpiling pascal to Javascript.
>
> It's much farther ahead than the webassembly target, already produces
> programs running in the browser and the first web-based components are
> already being developed using this approach.

I believe these will be complimentary solutions in the end, one will be
better for certain things than the other, with a lot of overlap, of
course. I think the transpiler might be better for developing unique
front-end solutions in Pascal for the web, the WebAssembly compiler might
be better to bring existing large chunks of code to run on the web, with
minimal modifications, and for performance critical things.

But only time will tell. :)

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Thu, 16 Mar 2017, Michael Schnell wrote:


On 15.03.2017 17:58, Karoly Balogh (Charlie/SGR) wrote:

Well, "degree of success" is relative, ...


Anyway, it's great to know that you are watching the proceedings 
regarding WebAssembly, and already did some effort to get started 


Just for enhancing your motivation :-) (of course this issue is more 
like a project related to the Lazarus or mse designers, but you are 
going to pave the way) :


The way is already paved.

In fact, there is an alternate approach, transpiling pascal to Javascript.

It's much farther ahead than the webassembly target, already produces 
programs running in the browser and the first web-based components are 
already being developed using this approach.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 16.03.2017 11:46, Graeme Geldenhuys wrote:


Umm, didn't they say the exact same thing about Java Applets,

No idea

Flash,
While it's depreciated right now it did last for a long time and was 
_very_ useful.

Silverlight
While technically it did look nice, it was a single-company thingy and 
doomed as this company did not succeed with taking over on the mobile 
market.

etc. :)
As Microsoft, Google, and Mozilla had been in the boat it looked a lot 
more promising.

I guess time will tell, but if history is anything
to go buy, security issues *will* pop up.

Hopefully they did consider this in the textbook

-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 15.03.2017 17:58, Karoly Balogh (Charlie/SGR) wrote:

Well, "degree of success" is relative, ...


Anyway, it's great to know that you are watching the proceedings 
regarding WebAssembly, and already did some effort to get started 


Just for enhancing your motivation :-) (of course this issue is more 
like a project related to the Lazarus or mse designers, but you are 
going to pave the way) :


IMHO this will be a great method to create (pure Pascal) applications 
that are split in a server based part and a browser based part.


A very desirable way to do so would be to use a GUI based IDE (such as 
Lazarus or mse) to create and test an application running locally, and 
then define "split points" and use some kind of standard communication 
protocol (i. e. rpc) library to split it up appropriately - just with 
some definitions, without really writing any additional code.


While the perfect splitting points of course depend on the application 
you are doing, one "simple" way would be to provide a server based 
application with a browser based remote GUI. (This might usually be 
called "Rich Internet Application".)


I know that mse features a tool called "ifi" to convert a normal "local" 
application into a remote-controlled application with a remote GUI. 
Here, the GUI part is an application created by mse/fpc, and able to 
connect to any backend application done with "ifi". Building on top of 
"ifi" it might be possible do have the "ifi-Browser" run in a 
Web-Browser using WebAssembly. ms like a very viable goal to me.


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[noreply]

On 2017-03-16 08:35, Mattias Gaertner wrote:

On Thu, 16 Mar 2017 14:07:51 +0100 (CET)
"Karoly Balogh (Charlie/SGR)"  wrote:


[...]
Also, WebAssembly is a descendant of asm.js,


Maybe historically. Technically asm.js is higher lvl than webassembly.



which was basically striped
down Javascript with some integer/pointer type tagging. As far as I 
know,
the main problem with JS from a computing point of view, that it 
handles

all numbers as floats for "simplicity", but with some code in other
languages, this can have real side effects (for example some integers
cannot be exactly expressed as floats,


JS uses Double, which can express integers correctly from
-$10 to $f.
That should be enough for most browser programs, don't you think?



Well I used to think 32 bit integers were good enough for everyone, but 
now I wish that all our integers went on to infinity, as some clever 
person probably wants to create some program you never dreamed of that 
will hit the integer limit...


But for dumb things like web stores, blogs... Yes.

For some physics simulation that is a massive number cruncher "no 
integer is ever big enough"...


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[wkitty42]

On 03/16/2017 06:56 AM, Graeme Geldenhuys wrote:

On 2017-03-11 23:23, Daniel Gaspary wrote:

I was reading about the new Firefox making WebAssembly publicly available
("On Tuesday Firefox 52 became the first browser to support WebAssembly



My system (FreeBSD) is compiling Firefox 52 in the background as we
speak. I’m very curious to see how the Zen Garden demo runs here.

  https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html


is this a takeoff from the movie AVATAR where they go up to choose their flying 
lizard creature?



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-16 15:39, Michael Van Canneyt wrote:
> It should be opposite. Start with very tight security, and loosen up if
> deemed safe...

Yes, that definitely is a much better way to go.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-16 15:48, José Mejuto wrote:
> about:config
> 
> javascript.options.wasm;true/false


Thanks for correcting me, my bad. I search for "assembly", "webassembly"
and also looked under "security.*"


Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[José Mejuto]

El 16/03/2017 a las 16:27, Graeme Geldenhuys escribió:

On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:

I think there's still a master switch to disable this in the browsers.


So far Firefox 52 has none. Not in the Preferences, and not in
about:config either.


Hello,

about:config

javascript.options.wasm;true/false


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:


On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:

I think there's still a master switch to disable this in the browsers.


So far Firefox 52 has none. Not in the Preferences, and not in
about:config either.

But yeah, it is early days, so hopefully security will tighten up in the
near future.


It should be opposite. Start with very tight security, and loosen up if
deemed safe...

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:
> I think there's still a master switch to disable this in the browsers.

So far Firefox 52 has none. Not in the Preferences, and not in
about:config either.

But yeah, it is early days, so hopefully security will tighten up in the
near future.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> And this brings me to my next worry. As far as I understand, WebAssembly
> is C (for now - other languages to follow) compiled into WebAssembly
> bytecode. So now we have C code with all its pointer access, buffer
> overflow issues etc running in the web browser space - at least Java
> Applets were a lot safer in that regards, and Java Applets require
> explicit signed executables and granted permission by the end-user (per
> app, per domain etc). WebAssembly just runs - no questions asked.

Yes. Much like your average Javascript snipet. But even if it's compiled
from C (or Pascal, eventually... :P), it doesn't mean it can just poke
pointers whereever it feels like, there are several protection layers
between the bytecode and the native code, the JIT engine itself, the
browser, and the OS. Also, most browsers run most pages in isolation
anyway. I agree though that some kind of code signing would be benefical.

Also, the major problem with Java and other plugins security faults were,
that the organizations behind them moved with glacial speed, and sometimes
(Flash, Silverlight) they were even closed source, which made it
impossible for browser vendors to act quickly and patch things up. None of
this is true for WebAssembly.

> Then we have the issue of code being obfuscated when compiled into
> bytecode. So now it is even harder to detect malicious code.

There are already decompiler tools for WebAssembly, which translate the
bytecode back into the AST or even some JS-alike syntax. It's not that
much less human readable, than a deobfuscated JS code, which someone ran
through an obfuscator before, IMO.

> It seems I am not alone in thinking this way. Just read the comments
> posted at the link listed in the first message of this thread.

I think there's still a master switch to disable this in the browsers. I'm
sure there'll be tricky attacks, but these happen with normal JS anyway.
But I don't think it'll be such a disaster as people predict. (And I'm
usually quite pessimistic about such things.)

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 16 Mar 2017, Mattias Gaertner wrote:

> > which was basically striped down Javascript with some integer/pointer
> > type tagging. As far as I know, the main problem with JS from a
> > computing point of view, that it handles all numbers as floats for
> > "simplicity", but with some code in other languages, this can have
> > real side effects (for example some integers cannot be exactly
> > expressed as floats,
>
> JS uses Double, which can express integers correctly from
> -$10 to $f.
> That should be enough for most browser programs, don't you think?

No, to be honest, I don't think so. I already tracked down bugs in native
client side software caused by this, because of stupid NodeJS backends.
Because someone thought it will be "good enough". It wasn't. Not to
mention the cases I got "NaN" string as value in an integer field, but
that's just JS in general for fun.

Although NodeJS wasn't running in the browser, admittedly. But I think the
more complex apps you bring to the web, on top of JS, the more such issues
will appear, and the harder it will be to track it down.

Bottom line: It's not good enough if you want to guarantee the same
results as on other platforms, for all integer arithmetics with all
standard types, including 64bit ones. Which is a must for any self
respecting multiplatform compiler, IMO. (There are ways to do it
nevertheless even w/o WebAssembly, but with a clear performance hit.)

But I guess this is drifting away from the WebAssembly target itself, so
we should continue on fpc-other. :)

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-16 13:07, Karoly Balogh (Charlie/SGR) wrote:
> Yes, but it is important to know there's a difference with Java Applets,
> Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
> VM which runs everything Javascript in the browser. So the browser vendors
> have full control on the code which runs there.

And this brings me to my next worry. As far as I understand, WebAssembly
is C (for now - other languages to follow) compiled into WebAssembly
bytecode. So now we have C code with all its pointer access, buffer
overflow issues etc running in the web browser space - at least Java
Applets were a lot safer in that regards, and Java Applets require
explicit signed executables and granted permission by the end-user (per
app, per domain etc). WebAssembly just runs - no questions asked.

Then we have the issue of code being obfuscated when compiled into
bytecode. So now it is even harder to detect malicious code.

The more I look at this, the more of a nightmare (security wise)
WebAssembly looks. Now we will have a cross-platform incubator for
malicious viruses, free to run in the web browser space, access to
low-level hardware, and all without explicit asking for or being granted
permission to run (ie: like Java Applets).

It seems I am not alone in thinking this way. Just read the comments
posted at the link listed in the first message of this thread.


Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Mattias Gaertner]

On Thu, 16 Mar 2017 14:07:51 +0100 (CET)
"Karoly Balogh (Charlie/SGR)"  wrote:

>[...]
> Also, WebAssembly is a descendant of asm.js,

Maybe historically. Technically asm.js is higher lvl than webassembly.


> which was basically striped
> down Javascript with some integer/pointer type tagging. As far as I know,
> the main problem with JS from a computing point of view, that it handles
> all numbers as floats for "simplicity", but with some code in other
> languages, this can have real side effects (for example some integers
> cannot be exactly expressed as floats,

JS uses Double, which can express integers correctly from
-$10 to $f.
That should be enough for most browser programs, don't you think?


>[...] 
> So all in all, despite its [webassembly] problems, it's still the best effort 
> to provide
> some sane bytecode standard for the web. (If a web bytecode can be
> anywhere near sane, that is.)

+1

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Benjamin Rosseaux]

The ECMAScript standard uses 64-bit double-precision floating
point numbers, and a double-precision floating point value can represent
absolute integer values up to of less than or equal to 2^53, without any
loss of accuracy, since an IEEE 754 64 bit double-precision floating point
number has a mantissa with a size of 52 bits (plus 1 bit implied).

On Thu, Mar 16, 2017 at 2:07 PM, Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu> wrote:

> Hi,
>
> On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:
>
> > I love how they say multiple times in the video:
> >
> >"... and completely secure."
> >
> > Umm, didn't they say the exact same thing about Java Applets, Flash,
> > Silverlight etc. :)  I guess time will tell, but if history is anything
> > to go buy, security issues *will* pop up.
>
> Yes, but it is important to know there's a difference with Java Applets,
> Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
> VM which runs everything Javascript in the browser. So the browser vendors
> have full control on the code which runs there.
>
> Also, WebAssembly is a descendant of asm.js, which was basically striped
> down Javascript with some integer/pointer type tagging. As far as I know,
> the main problem with JS from a computing point of view, that it handles
> all numbers as floats for "simplicity", but with some code in other
> languages, this can have real side effects (for example some integers
> cannot be exactly expressed as floats, which means slight differences in
> computation results accumulate over time, etc), and it's much slower on
> most CPUs. This is why I'm a bit relucant to accept High Level language
> translators to JS - there could be too many sideeffects hidden in any
> algorithm, just because of this one thing.
>
> This is the main problem asm.js, and now WebAssembly is addressing. It can
> work with the same integer and float types the hardware underneath is
> using, and can avoid all the float handling and various range/index etc
> checks. This is what provides the performance part. And obvously a lot of
> other "shortcuts" to work around JS language requirements, which another
> language might not need.
>
> And it fits in the process, how they gradually opened up the underlying
> hardware to the browser. Another great example is WebGL, which is also a
> very thin layer on top of the hardware, to skip through the billion "who
> cares about that" CSS and JS canvas layers, and go directly to the GPU, to
> get some decent performance...
>
> So all in all, despite its problems, it's still the best effort to provide
> some sane bytecode standard for the web. (If a web bytecode can be
> anywhere near sane, that is.)
>
> Charlie
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> I love how they say multiple times in the video:
>
>"... and completely secure."
>
> Umm, didn't they say the exact same thing about Java Applets, Flash,
> Silverlight etc. :)  I guess time will tell, but if history is anything
> to go buy, security issues *will* pop up.

Yes, but it is important to know there's a difference with Java Applets,
Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
VM which runs everything Javascript in the browser. So the browser vendors
have full control on the code which runs there.

Also, WebAssembly is a descendant of asm.js, which was basically striped
down Javascript with some integer/pointer type tagging. As far as I know,
the main problem with JS from a computing point of view, that it handles
all numbers as floats for "simplicity", but with some code in other
languages, this can have real side effects (for example some integers
cannot be exactly expressed as floats, which means slight differences in
computation results accumulate over time, etc), and it's much slower on
most CPUs. This is why I'm a bit relucant to accept High Level language
translators to JS - there could be too many sideeffects hidden in any
algorithm, just because of this one thing.

This is the main problem asm.js, and now WebAssembly is addressing. It can
work with the same integer and float types the hardware underneath is
using, and can avoid all the float handling and various range/index etc
checks. This is what provides the performance part. And obvously a lot of
other "shortcuts" to work around JS language requirements, which another
language might not need.

And it fits in the process, how they gradually opened up the underlying
hardware to the browser. Another great example is WebGL, which is also a
very thin layer on top of the hardware, to skip through the billion "who
cares about that" CSS and JS canvas layers, and go directly to the GPU, to
get some decent performance...

So all in all, despite its problems, it's still the best effort to provide
some sane bytecode standard for the web. (If a web bytecode can be
anywhere near sane, that is.)

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-16 10:56, Graeme Geldenhuys wrote:
> I’ll be pleasantly surprised if it works - after all, so many browser
> features often only work for OSX and Windows, even though the browser
> and web is supposed to be “cross-platform”.  I’ll report back later. ;-)


And I am pleasantly surprised! :)  That demo worked perfectly on my
system. Sound, animation, graphics all silky smooth. Impressive indeed.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-11 23:23, Daniel Gaspary wrote:
> I was reading about the new Firefox making WebAssembly publicly
> available ("On Tuesday Firefox 52 became the first browser to support
> WebAssembly


My system (FreeBSD) is compiling Firefox 52 in the background as we
speak. I’m very curious to see how the Zen Garden demo runs here.

  https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

I’ll be pleasantly surprised if it works - after all, so many browser
features often only work for OSX and Windows, even though the browser
and web is supposed to be “cross-platform”.  I’ll report back later. ;-)

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-15 16:58, Karoly Balogh (Charlie/SGR) wrote:
> It's now committed to the webassembly branch in FPC SVN, the compiler
> itself should build at least as "wasm" target, but don't expect much.

Thanks for the update Charlie. Lets just say you are a brave man in my
eyes to tackle something like that. :) I wish you all the best with the
task at hand.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Graeme Geldenhuys]

On 2017-03-11 23:23, Daniel Gaspary wrote:
> WebAssembly
> ")

I love how they say multiple times in the video:

   "... and completely secure."


Umm, didn't they say the exact same thing about Java Applets, Flash,
Silverlight etc. :)  I guess time will tell, but if history is anything
to go buy, security issues *will* pop up.

Saying all that, I really respect Mozilla for what they have done
regarding the web. Firefox is the only browser I ever use.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Lukasz Sokol]

To all who received my previous message through mailing list: 
please disregard. posted without reading thoroughly. apologies.

-L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Lukasz Sokol]

Hi,

On 15/03/17 16:58, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
> 
> On Sun, 12 Mar 2017, Michael Van Canneyt wrote:
> 
>>> Is there something planned in this matter for FPC?
>>> 
>>> I was reading about the new Firefox making WebAssembly publicly 
>>> available ("On Tuesday Firefox 52 became the first browser to
>>> support WebAssembly
>>> 
>> ")
>>>
>> 
[1] .
>> 
>> Karoly Balogh (Charlie/SGR) is working on this, and as far as I
>> know has already some degree of success. There is a bounty for
>> initial webassembly support..
> 
> Well, "degree of success" is relative, I have added WASM target to
> the compiler so it compiles at least. I even made it output 1 single 
> instruction... :)
> 
> It's based largely on gutted JVM codegenerator code, although since 
> WebAssembly itself is still a moving target, many things are still 
> uncertain. There's also the problem, that despite it's name,
> WebAssembly is not really an assembly format, but just a stack based
> bytecode (much like JVM), and the official textual representation is
> not yet accepted, plus the reference compiler LLVM outputs something
> entirely different to the semi-official textual formats. And these
> official textual formats are quite painful for the traditional
> structured compiler layers like FPC has.
> 
> But the LLVM-style output would be good, but it's undocumented, and
> as they say it will go away, and LLVM will output the binary
> bytecode directly... (Which is stupid IMO, but hey, a comittee
> decided, so it must be right.)
> 
> Also, any "assembler" or toolchain is still in its infancy. (I made
> both binaryen and wabt segfault in several funny ways already.) So I
> wouldn't expect fast results with this whole target. But I will keep
> working on it as time allows, so "eventually"... Of course if someone
> thinks he can proceed faster and wants to jump in, it's very
> welcomed.
> 
> It's now committed to the webassembly branch in FPC SVN, the
> compiler itself should build at least as "wasm" target, but don't
> expect much.
> 
> Charlie 


Just because of curiosity: since Firefox  52 apparently boasts (to be the first 
browser with)
WebAssembly support - 
- i know, i know, just because one vendor claims it, it doesn't mean anything 
yet - 
-maybe something concrete could be derived from that fact? Even if it's just a 
'how do they do it' style of fact.

(in the press release they say something about Emscripten being the reference 
implementation, if that helps)

-L.
(rs,ianad)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Schnell]

On 12.03.2017 00:53, Michael Van Canneyt wrote:


Karoly Balogh (Charlie/SGR) is working on this, and as far as I know 
has already some degree of

success.

The Silverlight killer meets the C# killer :)

-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sun, 12 Mar 2017, Michael Van Canneyt wrote:

> >   Is there something planned in this matter for FPC?
> >
> >   I was reading about the new Firefox making WebAssembly publicly
> > available ("On Tuesday Firefox 52 became the first browser to support
> > WebAssembly
> >
> ")
> > [1] .
>
> Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has
> already some degree of success. There is a bounty for initial
> webassembly support..

Well, "degree of success" is relative, I have added WASM target to the
compiler so it compiles at least. I even made it output 1 single
instruction... :)

It's based largely on gutted JVM codegenerator code, although since
WebAssembly itself is still a moving target, many things are still
uncertain. There's also the problem, that despite it's name, WebAssembly
is not really an assembly format, but just a stack based bytecode (much
like JVM), and the official textual representation is not yet accepted,
plus the reference compiler LLVM outputs something entirely different to
the semi-official textual formats. And these official textual formats are
quite painful for the traditional structured compiler layers like FPC has.

But the LLVM-style output would be good, but it's undocumented, and as
they say it will go away, and LLVM will output the binary bytecode
directly... (Which is stupid IMO, but hey, a comittee decided, so it must
be right.)

Also, any "assembler" or toolchain is still in its infancy. (I made both
binaryen and wabt segfault in several funny ways already.) So I wouldn't
expect fast results with this whole target. But I will keep working on it
as time allows, so "eventually"... Of course if someone thinks he can
proceed faster and wants to jump in, it's very welcomed.

It's now committed to the webassembly branch in FPC SVN, the compiler
itself should build at least as "wasm" target, but don't expect much.

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

[Michael Van Canneyt]

On Sat, 11 Mar 2017, Daniel Gaspary wrote:


Hi,

  Is there something planned in this matter for FPC?

  I was reading about the new Firefox making WebAssembly publicly
available ("On Tuesday Firefox 52 became the first browser to support
WebAssembly
")
[1] .


Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has 
already some degree of
success. There is a bounty for initial webassembly support..

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal