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] Threadvar member field

[Michael Van Canneyt]

On Thu, 16 Mar 2017, African Wild Dog wrote:


I have a class where its instances are shared between multiple threads.
How can I declare one variable per instance per thread?

The code below does not compile (fpc 3.0.0):

TMyClass = class
public
 threadvar MyValue: Integer;
end;


This is not foreseen as a language construct, you must do this yourself.

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

[fpc-pascal] Threadvar member field

[African Wild Dog]

I have a class where its instances are shared between multiple threads.
How can I declare one variable per instance per thread?

The code below does not compile (fpc 3.0.0):

TMyClass = class
public
  threadvar MyValue: Integer;
end;

Regards
___
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