Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 11:35 PM, Phil Bouchard wrote:

On 07/15/2017 01:18 PM, Phil Bouchard wrote:

On 07/15/2017 12:59 PM, Thiago Macieira wrote:

On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote:

Yes of course, I should have anticipated that. So one option left would
be to:
- compile the Javascript file for each architecture / platform
- link that "jex" to a portable dynamic library API
- run native containers (Hyper-V on Windows I think)
- run the "jex" executable in that native container


Hyper-V is not a container.

Containers are not completely secure. That's why we spent the
engineering
effort of making the Clear Containers, so that the processor's virtual
machine
protections kick in.

And you could investigate NaCl.


I will but you get the idea.


Like I was saying, there was a bug in my code and perhaps it's
impossible for Javascript to run without a GC indeed.

But that doesn't mean that we couldn't run executables in one of those
specialized containers. And although I like the concept of these quick
function callbacks in Javascript, I do not like the 'escape analysis'
thing and I think this should be trashed because the ratio costs /
benefits isn't profitable enough.

Perhaps we could derive a new language from Javascript and C++ which
could be run inside these specialized containers. I already have a
parser and only minor changes are necessary. If people want speed then
there is no other way.


And if I remove that run-time stack thing then the generated code will 
be even more efficient.



-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 01:18 PM, Phil Bouchard wrote:

On 07/15/2017 12:59 PM, Thiago Macieira wrote:

On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote:

Yes of course, I should have anticipated that. So one option left would
be to:
- compile the Javascript file for each architecture / platform
- link that "jex" to a portable dynamic library API
- run native containers (Hyper-V on Windows I think)
- run the "jex" executable in that native container


Hyper-V is not a container.

Containers are not completely secure. That's why we spent the engineering
effort of making the Clear Containers, so that the processor's virtual
machine
protections kick in.

And you could investigate NaCl.


I will but you get the idea.


Like I was saying, there was a bug in my code and perhaps it's 
impossible for Javascript to run without a GC indeed.


But that doesn't mean that we couldn't run executables in one of those 
specialized containers. And although I like the concept of these quick 
function callbacks in Javascript, I do not like the 'escape analysis' 
thing and I think this should be trashed because the ratio costs / 
benefits isn't profitable enough.


Perhaps we could derive a new language from Javascript and C++ which 
could be run inside these specialized containers. I already have a 
parser and only minor changes are necessary. If people want speed then 
there is no other way.



-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 07:49 PM, Phil Bouchard wrote:

On 07/15/2017 07:21 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point with
the following code:

var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


after `foo` returns, you only have one root, as neither `result` nor
`object` will escape `foo` and `object` will only be referenced by the
closure returned by `foo`.

`result` is a perfect target for escape analysis. maybe even `object`.
you have read about escape analysis, right?


Yes I understand escape analysis and that's exactly why I had to add a
run-time stack.


I apologize but there was a bug in my code which I just fixed (about 
missing variables). And perhaps you and Thiago were right that it's 
impossible for Javascript to run without a GC because variables indeed 
go out of scope and only the GC can tell whether to keep it or not.


Perhaps I should go back to the C++ world with my root_ptr, now that I 
have a better understanding of it all.  But I will double check all of 
this beforehand.



Thanks again!
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 09:46 PM, Phil Bouchard wrote:

On 07/15/2017 07:32 PM, Phil Bouchard wrote:

On 07/15/2017 04:58 PM, Phil Bouchard wrote:

On 07/15/2017 02:26 PM, Phil Bouchard wrote:

On 07/15/2017 02:17 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point
with
the following code:

var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


Alright I got good news: the parser already generates code that compiles
and works!

I still need to fix minor issues but I am on the right path.


Alright... it's good enough now so you try it out yourselves (BTW I
added the keyword: "extern" so you can already mix C++ code with
Javascript).


Instructions (you'll need: Boost, Flex, Bison, Qt):

1) Get the following code: https://github.com/philippeb8/root_ptr/tree/qt

2) In "example/js2cpp", type:
$ qmake
$ make
$ ./js2cpp < tests/input1.js > tmp.cpp
$ g++ -std=c++11 -O2 -Iinclude -I../../include tmp.cpp -otmp
-lboost_system
$ time ./tmp
int main()

real0m1.581s
user0m1.581s
sys 0m0.000s


TODO:

1) Finish removing all dependencies from Boost

2) Figure a way to have variadic number of arguments for functions

3) Create local variables linked to the function arguments

4) Fix a -DBOOST_DISABLE_THREADS that is not working for some reason

5) ...


Actually there seem to have a bug in g++-4.8 so please use g++-4.9 as
follows:

g++-4.9 -DBOOST_DISABLE_THREADS -std=c++11 -O2 -I./include
-I../../include tmp.cpp -otmp -lboost_system


... and it's still exactly twice as fast as Node.JS.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 07:32 PM, Phil Bouchard wrote:

On 07/15/2017 04:58 PM, Phil Bouchard wrote:

On 07/15/2017 02:26 PM, Phil Bouchard wrote:

On 07/15/2017 02:17 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point with
the following code:

var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


Alright I got good news: the parser already generates code that compiles
and works!

I still need to fix minor issues but I am on the right path.


Alright... it's good enough now so you try it out yourselves (BTW I
added the keyword: "extern" so you can already mix C++ code with
Javascript).


Instructions (you'll need: Boost, Flex, Bison, Qt):

1) Get the following code: https://github.com/philippeb8/root_ptr/tree/qt

2) In "example/js2cpp", type:
$ qmake
$ make
$ ./js2cpp < tests/input1.js > tmp.cpp
$ g++ -std=c++11 -O2 -Iinclude -I../../include tmp.cpp -otmp -lboost_system
$ time ./tmp
int main()

real0m1.581s
user0m1.581s
sys 0m0.000s


TODO:

1) Finish removing all dependencies from Boost

2) Figure a way to have variadic number of arguments for functions

3) Create local variables linked to the function arguments

4) Fix a -DBOOST_DISABLE_THREADS that is not working for some reason

5) ...


Actually there seem to have a bug in g++-4.8 so please use g++-4.9 as 
follows:


g++-4.9 -DBOOST_DISABLE_THREADS -std=c++11 -O2 -I./include 
-I../../include tmp.cpp -otmp -lboost_system



Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 07:21 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point with
the following code:

var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


after `foo` returns, you only have one root, as neither `result` nor
`object` will escape `foo` and `object` will only be referenced by the
closure returned by `foo`.

`result` is a perfect target for escape analysis. maybe even `object`.
you have read about escape analysis, right?


Yes I understand escape analysis and that's exactly why I had to add a 
run-time stack.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 04:58 PM, Phil Bouchard wrote:

On 07/15/2017 02:26 PM, Phil Bouchard wrote:

On 07/15/2017 02:17 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point with
the following code:

var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


Alright I got good news: the parser already generates code that compiles
and works!

I still need to fix minor issues but I am on the right path.


Alright... it's good enough now so you try it out yourselves (BTW I 
added the keyword: "extern" so you can already mix C++ code with 
Javascript).



Instructions (you'll need: Boost, Flex, Bison, Qt):

1) Get the following code: https://github.com/philippeb8/root_ptr/tree/qt

2) In "example/js2cpp", type:
$ qmake
$ make
$ ./js2cpp < tests/input1.js > tmp.cpp
$ g++ -std=c++11 -O2 -Iinclude -I../../include tmp.cpp -otmp -lboost_system
$ time ./tmp
int main()

real0m1.581s
user0m1.581s
sys 0m0.000s


TODO:

1) Finish removing all dependencies from Boost

2) Figure a way to have variadic number of arguments for functions

3) Create local variables linked to the function arguments

4) Fix a -DBOOST_DISABLE_THREADS that is not working for some reason

5) ...


Thanks for your patience!
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Tim Blechmann]

 fwiw, to get this thread back to the main topic, i still fail to see
 how
 root_ptr deals with objects which are reachable from multiple roots,
 which have independent lifetime
>>>
>>> Please provide an example.
>>
>> i've posted some already
> 
> I'm working on the parser right now but I thought I proved my point with
> the following code:
> 
> var temporary = 0;
> 
> var bar = function (object)
> {
> return 10;
> };
> 
> var foo = function ()
> {
> var object;
> var result = function() { return object; };
> return function() { return bar( object ); };
> };
> 
> for (var i = 0; i < 100; ++ i)
> console_log((foo())(temporary));

after `foo` returns, you only have one root, as neither `result` nor
`object` will escape `foo` and `object` will only be referenced by the
closure returned by `foo`.

`result` is a perfect target for escape analysis. maybe even `object`.
you have read about escape analysis, right?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 02:26 PM, Phil Bouchard wrote:

On 07/15/2017 02:17 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point with
the following code:

var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


Alright I got good news: the parser already generates code that compiles 
and works!


I still need to fix minor issues but I am on the right path.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 02:17 PM, Tim Blechmann wrote:

fwiw, to get this thread back to the main topic, i still fail to see how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime


Please provide an example.


i've posted some already


I'm working on the parser right now but I thought I proved my point with 
the following code:


var temporary = 0;

var bar = function (object)
{
return 10;
};

var foo = function ()
{
var object;
var result = function() { return object; };
return function() { return bar( object ); };
};

for (var i = 0; i < 100; ++ i)
console_log((foo())(temporary));


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Tim Blechmann]

>> fwiw, to get this thread back to the main topic, i still fail to see how
>> root_ptr deals with objects which are reachable from multiple roots,
>> which have independent lifetime
> 
> Please provide an example.

i've posted some already

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Tim Blechmann]

> Oh sorry they did invent Minesweeper and Basic, I give them that...

https://en.wikipedia.org/wiki/Dartmouth_BASIC

--

fwiw, to get this thread back to the main topic, i still fail to see how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 12:59 PM, Thiago Macieira wrote:

On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote:

Yes of course, I should have anticipated that. So one option left would
be to:
- compile the Javascript file for each architecture / platform
- link that "jex" to a portable dynamic library API
- run native containers (Hyper-V on Windows I think)
- run the "jex" executable in that native container


Hyper-V is not a container.

Containers are not completely secure. That's why we spent the engineering
effort of making the Clear Containers, so that the processor's virtual machine
protections kick in.

And you could investigate NaCl.


I will but you get the idea.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote:
> Yes of course, I should have anticipated that. So one option left would
> be to:
> - compile the Javascript file for each architecture / platform
> - link that "jex" to a portable dynamic library API
> - run native containers (Hyper-V on Windows I think)
> - run the "jex" executable in that native container

Hyper-V is not a container.

Containers are not completely secure. That's why we spent the engineering 
effort of making the Clear Containers, so that the processor's virtual machine 
protections kick in.

And you could investigate NaCl.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/15/2017 02:56 AM, Thiago Macieira wrote:

On sexta-feira, 14 de julho de 2017 12:13:52 PDT Phil Bouchard wrote:

[1] https://clearlinux.org/features/intel%C2%AE-clear-containers


I understand but what's the problem with containers?  I think Linux
containers are also supported under Windows. Obviously some efforts will
have to be done to strip out some access to the hardware


Windows and macOS run Linux containers by starting a virtual machine that runs
Linux. The time those take to start is in the order of seconds, not tenths of
seconds like Clear Containers or tenths of milliseconds like regular
containers.

Clear Containers on Linux takes advantage that the *host* is Linux to bypass a
lot of things. It doesn't run a BIOS, for instance, and simply executes a
specially-prepared vmlinux binary inside the VM. There's no disk I/O --
everything is Direct Access (DAX) just like on tiny microcontrolers.

Making that run on macOS or Windows requires changes to the host OS itself.


Yes of course, I should have anticipated that. So one option left would 
be to:

- compile the Javascript file for each architecture / platform
- link that "jex" to a portable dynamic library API
- run native containers (Hyper-V on Windows I think)
- run the "jex" executable in that native container


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On sexta-feira, 14 de julho de 2017 12:13:52 PDT Phil Bouchard wrote:
> > [1] https://clearlinux.org/features/intel%C2%AE-clear-containers
> 
> I understand but what's the problem with containers?  I think Linux
> containers are also supported under Windows. Obviously some efforts will
> have to be done to strip out some access to the hardware

Windows and macOS run Linux containers by starting a virtual machine that runs 
Linux. The time those take to start is in the order of seconds, not tenths of 
seconds like Clear Containers or tenths of milliseconds like regular 
containers.

Clear Containers on Linux takes advantage that the *host* is Linux to bypass a 
lot of things. It doesn't run a BIOS, for instance, and simply executes a 
specially-prepared vmlinux binary inside the VM. There's no disk I/O -- 
everything is Direct Access (DAX) just like on tiny microcontrolers.

Making that run on macOS or Windows requires changes to the host OS itself.

> > It has always been a standard! That's what the Khronos Group is for in the
> > first place.
> 
> I meant Open GL and Open GL ES will have to be unified one day.

And then we added Vulkan. So, unlikely, though I think OpenGL 4 is a complete 
superset of OpenGL ES 2. Maybe of ES3 too?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/14/2017 12:58 AM, Phil Bouchard wrote:

On 07/13/2017 10:32 AM, Grégoire Barbier wrote:

Le 13/07/2017 à 14:33, Phil Bouchard a écrit :

Sérgio Martins  wrote:

On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard 
wrote:

Anyway I'm deviating from QNodePtr but I just don't understand the
hype
about JIT when it doesn't seem it has been compared to a Javascript
compiler
because none exists up to now.


That's precisely the biggest advantage of JIT: It exists, while js2cpp
doesn't (or at least in a usable form for us).


I'm working on it; it shouldn't take too long.


<3


Here's a preliminary parser that doesn't even compile yet but it's
moving forward and fast:
https://github.com/philippeb8/root_ptr/tree/qt/example/js2cpp


Now it compiles, links and parses correctly.  I just need to fix the 
output and make it all work.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Thiago Macieira  wrote:
> On sexta-feira, 14 de julho de 2017 10:08:13 PDT Phil Bouchard wrote:
>>> Please read up a little on a subject before you make such an outlandish
>>> suggestion.
>> 
>> Yes sorry that was just a quick guess but in Linux you can run Linux
>> containers which do the same but with minimal overhead.
> 
> A container is not the same as a virtual machine. There is such a thing as 
> virtualised containers (see [1]), but they don't boot as fast as a regular 
> container. We've got it down to less than 200 milliseconds.
> 
> Browsers already use process separation and other things to avoid escalation 
> from JS. I do believe they also use the same technique as containers for 
> namespace separations. But that's for running a JS VM, not for running direct 
> native code that can make system calls and trigger hardware errata.
> 
> [1] https://clearlinux.org/features/intel%C2%AE-clear-containers

I understand but what's the problem with containers?  I think Linux
containers are also supported under Windows. Obviously some efforts will
have to be done to strip out some access to the hardware

>>> And second, standardising on one API (OpenGL ES) has benefits for game
>>> makers and other application deveopers, since they can use the very same
>>> on both desktop and mobile. It's probably of less value for gamek
>>> developers since the interaction is going to be very different from a
>>> desktop and a mobile phone or tablet, but other applications can benefit
>>> a lot from OpenGL ES.
>> 
>> I definitely agree OpenGL ES needs to be standardized.
> 
> It has always been a standard! That's what the Khronos Group is for in the 
> first place.

I meant Open GL and Open GL ES will have to be unified one day.

>> Anyway I'm just trying to help here. But Microsoft probably already
>> embraced and is extending this strategy as we speak now ;)
> 
> No, they went their own route and designed DirectX, though TBH Khronos was 
> dysfunctional at the time. WebGL is actually the best thing that happened to 
> the standard route because it forced Microsoft to implement OpenGL ES support 
> in their browsers in the form of WebGL.

BTW what did Microsoft really invent anyways?
- they extended the IBM OS 9
- they extended WordPerfect and Lotus
- they invested into Corel so that they get rid of Corel Linux when I was
there
- they copied my calculator
- they copied Google with their Bing
- they tried to copy iPhone with the Windows Phone
- DirectX never was better than OpenGL

Oh sorry they did invent Minesweeper and Basic, I give them that... Sorry I
had to spit it out.

But let's see what happens with WebGL.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On sexta-feira, 14 de julho de 2017 10:08:13 PDT Phil Bouchard wrote:
> > Please read up a little on a subject before you make such an outlandish
> > suggestion.
> 
> Yes sorry that was just a quick guess but in Linux you can run Linux
> containers which do the same but with minimal overhead.

A container is not the same as a virtual machine. There is such a thing as 
virtualised containers (see [1]), but they don't boot as fast as a regular 
container. We've got it down to less than 200 milliseconds.

Browsers already use process separation and other things to avoid escalation 
from JS. I do believe they also use the same technique as containers for 
namespace separations. But that's for running a JS VM, not for running direct 
native code that can make system calls and trigger hardware errata.

[1] https://clearlinux.org/features/intel%C2%AE-clear-containers

> > And second, standardising on one API (OpenGL ES) has benefits for game
> > makers and other application deveopers, since they can use the very same
> > on both desktop and mobile. It's probably of less value for gamek
> > developers since the interaction is going to be very different from a
> > desktop and a mobile phone or tablet, but other applications can benefit
> > a lot from OpenGL ES.
> 
> I definitely agree OpenGL ES needs to be standardized.

It has always been a standard! That's what the Khronos Group is for in the 
first place.

> Anyway I'm just trying to help here. But Microsoft probably already
> embraced and is extending this strategy as we speak now ;)

No, they went their own route and designed DirectX, though TBH Khronos was 
dysfunctional at the time. WebGL is actually the best thing that happened to 
the standard route because it forced Microsoft to implement OpenGL ES support 
in their browsers in the form of WebGL.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Thiago Macieira  wrote:
> On sexta-feira, 14 de julho de 2017 05:06:14 PDT Phil Bouchard wrote:
>>> Except for the fact that no browser would ever download and execute
>>> untrusted binaries like that.
>>> 
>>> The closest is Native Client (NaCl).
>> 
>> You force that Javascript executable (".jex" file) to run inside some
>> embedded virtual machine with restricted access to the system.
> 
> Virtual Machines (protected by hardware) run operating system kernels, not 
> simple executables. And it has a non-negligible memory overhead, since it 
> needs to do its own virtual paging table management.
> 
> Please read up a little on a subject before you make such an outlandish 
> suggestion.

Yes sorry that was just a quick guess but in Linux you can run Linux
containers which do the same but with minimal overhead.

 Because let's face it: WebGL is not going anywhere.  It had the slowest
 progress I have ever seen!
>>> 
>>> What progress does it need? It needs to implement the OpenGL ES API. Once
>>> that is done, they don't need to do anything. All the work is in the GL
>>> drivers and GPUs.
>> 
>> Where are the WebGL games then?  We don't need OpenGL ES on x86.
> 
> First, some exist. The difficult part in making games with JS is probably not 
> the GL part, but all the rest, including the code that manages the visible 
> screen area. 
> 
> I never said that JS isn't slow -- it is.
> 
> And second, standardising on one API (OpenGL ES) has benefits for game makers 
> and other application deveopers, since they can use the very same on both 
> desktop and mobile. It's probably of less value for gamek developers since 
> the 
> interaction is going to be very different from a desktop and a mobile phone 
> or 
> tablet, but other applications can benefit a lot from OpenGL ES.

I definitely agree OpenGL ES needs to be standardized.

Anyway I'm just trying to help here. But Microsoft probably already
embraced and is extending this strategy as we speak now ;)

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On sexta-feira, 14 de julho de 2017 05:06:14 PDT Phil Bouchard wrote:
> > Except for the fact that no browser would ever download and execute
> > untrusted binaries like that.
> > 
> > The closest is Native Client (NaCl).
> 
> You force that Javascript executable (".jex" file) to run inside some
> embedded virtual machine with restricted access to the system.

Virtual Machines (protected by hardware) run operating system kernels, not 
simple executables. And it has a non-negligible memory overhead, since it 
needs to do its own virtual paging table management.

Please read up a little on a subject before you make such an outlandish 
suggestion.

> >> Because let's face it: WebGL is not going anywhere.  It had the slowest
> >> progress I have ever seen!
> > 
> > What progress does it need? It needs to implement the OpenGL ES API. Once
> > that is done, they don't need to do anything. All the work is in the GL
> > drivers and GPUs.
> 
> Where are the WebGL games then?  We don't need OpenGL ES on x86.

First, some exist. The difficult part in making games with JS is probably not 
the GL part, but all the rest, including the code that manages the visible 
screen area. 

I never said that JS isn't slow -- it is.

And second, standardising on one API (OpenGL ES) has benefits for game makers 
and other application deveopers, since they can use the very same on both 
desktop and mobile. It's probably of less value for gamek developers since the 
interaction is going to be very different from a desktop and a mobile phone or 
tablet, but other applications can benefit a lot from OpenGL ES.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/14/2017 03:18 AM, Thiago Macieira wrote:

On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote:

You just helped me figure something out: people want speed, right?

- You offer a service which converts and compiles all Javascript files
for most popular architectures (i386, x86_64, ARM, MIPS, ...)
- You cache these executables on the webserver in question
- The client just downloads and caches the respective executable and
executes it in the browser


Except for the fact that no browser would ever download and execute untrusted
binaries like that.

The closest is Native Client (NaCl).


You force that Javascript executable (".jex" file) to run inside some 
embedded virtual machine with restricted access to the system.



Because let's face it: WebGL is not going anywhere.  It had the slowest
progress I have ever seen!


What progress does it need? It needs to implement the OpenGL ES API. Once that
is done, they don't need to do anything. All the work is in the GL drivers and
GPUs.


Where are the WebGL games then?  We don't need OpenGL ES on x86.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Edward Welbourne]

André Pönitz (13 July 2017 19:20)
> There's no sensible reason to postpone "compilation" to run-time
> on a million feeble devices if there's any sensible way to do it
> ahead of time once on a beefy developer machine.

On the other hand, doing run-time optimisation (which is one of the
benefits a JIT is meant to give you) *does* have value; having the
engine capable of spotting which paths through the code actually do get
taken in real live use (rather than guessing during compilation; no
matter how good your heuristics, or how much the developer annotates the
code to help, real-world run-time will do things differently than you
thought) lets the run-time engine optimise those paths at the expense of
others.

Then of course there's the issue of trust: the user trusts the browser
to run code sand-boxed; neither the browser nor the user should trust a
binary downloaded from the internet; so the benefits you can gain by
pre-compiling incur the cost of running untrusted code.  Java deals with
that by running the compiled code in a VM that's sand-boxed; modern
ECMAScript (a.k.a. javascript) deals with running native code by only
doing so when the native code in question is what it generated, within
constraints that keep it inside the interpreter's sand-box.  (Which is
still somewhat scary, as JITs are software and software has bugs, that
attackers shall exploit; in this case, to trick a JIT into doing
something that breaks the sand-box.  So modern browsers are aggressive
about updating themselves.)

Oh, and many of our hand-held devices are far from feeble - but perhaps
my standards are a bit odd.  My first job involved sending code to run
on a Cray 1 at £1000 per hour; we're all now wasting cycles on more
powerful computers whose non-wasted cycles are mostly used to alleviate
boredom,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

14.07.2017, 10:18, "Thiago Macieira" :
> On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote:
>>  You just helped me figure something out: people want speed, right?
>>
>>  - You offer a service which converts and compiles all Javascript files
>>  for most popular architectures (i386, x86_64, ARM, MIPS, ...)
>>  - You cache these executables on the webserver in question
>>  - The client just downloads and caches the respective executable and
>>  executes it in the browser
>
> Except for the fact that no browser would ever download and execute untrusted
> binaries like that.
>
> The closest is Native Client (NaCl).

Which is being phased out in favor of WebAssembly (JIT-based)

>
>>  Because let's face it: WebGL is not going anywhere. It had the slowest
>>  progress I have ever seen!
>
> What progress does it need? It needs to implement the OpenGL ES API. Once that
> is done, they don't need to do anything. All the work is in the GL drivers and
> GPUs.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote:
> You just helped me figure something out: people want speed, right?
> 
> - You offer a service which converts and compiles all Javascript files
> for most popular architectures (i386, x86_64, ARM, MIPS, ...)
> - You cache these executables on the webserver in question
> - The client just downloads and caches the respective executable and
> executes it in the browser

Except for the fact that no browser would ever download and execute untrusted 
binaries like that.

The closest is Native Client (NaCl).

> Because let's face it: WebGL is not going anywhere.  It had the slowest
> progress I have ever seen!

What progress does it need? It needs to implement the OpenGL ES API. Once that 
is done, they don't need to do anything. All the work is in the GL drivers and 
GPUs.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/13/2017 10:32 AM, Grégoire Barbier wrote:

Le 13/07/2017 à 14:33, Phil Bouchard a écrit :

Sérgio Martins  wrote:

On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard 
wrote:

Anyway I'm deviating from QNodePtr but I just don't understand the hype
about JIT when it doesn't seem it has been compared to a Javascript
compiler
because none exists up to now.


That's precisely the biggest advantage of JIT: It exists, while js2cpp
doesn't (or at least in a usable form for us).


I'm working on it; it shouldn't take too long.


<3


Here's a preliminary parser that doesn't even compile yet but it's 
moving forward and fast:

https://github.com/philippeb8/root_ptr/tree/qt/example/js2cpp


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/13/2017 10:32 AM, Grégoire Barbier wrote:

Le 13/07/2017 à 14:33, Phil Bouchard a écrit :


I'm working on it; it shouldn't take too long.


<3

« I have discovered a truly marvelous proof of this, which this margin
is too narrow to contain. »
Pierre de Fermat, 1637 A.D.

Took 356 years to be proven actually.

Anyway compiling JS to C++ was not your first goal if I undestand well.


I'm just killing two birds with one stone here.


Maybe getting rid of GC is possible without compiling JS. And it may be
interesting for compiled languages that do use a GC to, like C# or Java.


Swift, C# or Java are all proprietary languages now and they just 
embrace and extend whatever you do without giving you credit.  They 
already embraced and extended my Fornux PowerCalc with their Microsoft 
PowerToys after I had presented it to them using some web submission tool:

https://en.wikipedia.org/wiki/Microsoft_PowerToys#Included_applications


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/13/2017 01:20 PM, André Pönitz wrote:

On Wed, Jul 12, 2017 at 11:54:54PM -0400, Phil Bouchard wrote:

On 07/12/2017 10:28 PM, Thiago Macieira wrote:

On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote:

I don't know about you but a minimalist version of g++ embedded inside the
browser could be beneficial big time.


Such a thing exists, it's called JIT.


I was reading the Wiki page:
https://en.wikipedia.org/wiki/Just-in-time_compilation

And it says:
"thus in theory JIT compilation can yield faster execution than static
compilation"


Right, and in practice there's a reason why some people pronounce
it with [ʃ]

There's no sensible reason to postpone "compilation" to run-time
on a million feeble devices if there's any sensible way to do it
ahead of time once on a beefy developer machine.


You just helped me figure something out: people want speed, right?

- You offer a service which converts and compiles all Javascript files 
for most popular architectures (i386, x86_64, ARM, MIPS, ...)

- You cache these executables on the webserver in question
- The client just downloads and caches the respective executable and 
executes it in the browser


You can't have anything faster than that.  And once again we would be 
able to mix Javascript with C++ so you could import real OpenGL code in 
the executable and play let's say: "Unreal Tournament" in your own browser.


Because let's face it: WebGL is not going anywhere.  It had the slowest 
progress I have ever seen!



My 2 cents,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

André Pönitz  wrote:
> On Wed, Jul 12, 2017 at 11:54:54PM -0400, Phil Bouchard wrote:
> On 07/12/2017 10:28 PM, Thiago Macieira wrote:
> >On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote:
> >>I don't know about you but a minimalist version of g++ embedded inside the
> >>browser could be beneficial big time.
> >
> >Such a thing exists, it's called JIT.
> 
> I was reading the Wiki page:
> https://en.wikipedia.org/wiki/Just-in-time_compilation
> 
> And it says:
> "thus in theory JIT compilation can yield faster execution than static
> compilation"

Right, and in practice there's a reason why some people pronounce
it with [ʃ] 

There's no sensible reason to postpone "compilation" to run-time
on a million feeble devices if there's any sensible way to do it
ahead of time once on a beefy developer machine.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[André Pönitz]

On Wed, Jul 12, 2017 at 11:54:54PM -0400, Phil Bouchard wrote:
> On 07/12/2017 10:28 PM, Thiago Macieira wrote:
> >On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote:
> >>I don't know about you but a minimalist version of g++ embedded inside the
> >>browser could be beneficial big time.
> >
> >Such a thing exists, it's called JIT.
> 
> I was reading the Wiki page:
> https://en.wikipedia.org/wiki/Just-in-time_compilation
> 
> And it says:
> "thus in theory JIT compilation can yield faster execution than static
> compilation"

Right, and in practice there's a reason why some people pronounce
it with [ʃ] 

There's no sensible reason to postpone "compilation" to run-time
on a million feeble devices if there's any sensible way to do it
ahead of time once on a beefy developer machine.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Grégoire Barbier  wrote:
> Le 13/07/2017 à 14:33, Phil Bouchard a écrit :
> Sérgio Martins  wrote:
>> On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard  wrote:
>>> Anyway I'm deviating from QNodePtr but I just don't understand the hype
>>> about JIT when it doesn't seem it has been compared to a Javascript compiler
>>> because none exists up to now.
>> 
>> That's precisely the biggest advantage of JIT: It exists, while js2cpp
>> doesn't (or at least in a usable form for us).
> 
> I'm working on it; it shouldn't take too long.

<3

« I have discovered a truly marvelous proof of this, which this margin 
is too narrow to contain. »
Pierre de Fermat, 1637 A.D.

Took 356 years to be proven actually.

Anyway compiling JS to C++ was not your first goal if I undestand well. 
Maybe getting rid of GC is possible without compiling JS. And it may be 
interesting for compiled languages that do use a GC to, like C# or Java.

Regards.

-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Grégoire Barbier]

Le 13/07/2017 à 14:33, Phil Bouchard a écrit :

Sérgio Martins  wrote:

On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard  wrote:

Anyway I'm deviating from QNodePtr but I just don't understand the hype
about JIT when it doesn't seem it has been compared to a Javascript compiler
because none exists up to now.


That's precisely the biggest advantage of JIT: It exists, while js2cpp
doesn't (or at least in a usable form for us).


I'm working on it; it shouldn't take too long.


<3

« I have discovered a truly marvelous proof of this, which this margin 
is too narrow to contain. »

Pierre de Fermat, 1637 A.D.

Took 356 years to be proven actually.

Anyway compiling JS to C++ was not your first goal if I undestand well. 
Maybe getting rid of GC is possible without compiling JS. And it may be 
interesting for compiled languages that do use a GC to, like C# or Java.


Regards.

--
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Sérgio Martins  wrote:
> On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard  wrote:
>> Anyway I'm deviating from QNodePtr but I just don't understand the hype
>> about JIT when it doesn't seem it has been compared to a Javascript compiler
>> because none exists up to now.
> 
> That's precisely the biggest advantage of JIT: It exists, while js2cpp
> doesn't (or at least in a usable form for us).

I'm working on it; it shouldn't take too long.

> The problem is that JavaScript is a "do whatever you want" type of
> language, which doesn't translate well to C++.

The net speed makes all the difference between who gets chosen amongst Qt /
Blink / WebKit / WPE.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Sérgio Martins]

On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard  wrote:
> Anyway I'm deviating from QNodePtr but I just don't understand the hype
> about JIT when it doesn't seem it has been compared to a Javascript compiler
> because none exists up to now.

That's precisely the biggest advantage of JIT: It exists, while js2cpp
doesn't (or at least in a usable form for us).

The problem is that JavaScript is a "do whatever you want" type of
language, which doesn't translate well to C++.

Regards,
Sergio Martins
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/13/2017 04:09 AM, Konstantin Tokarev wrote:



13.07.2017, 02:39, "Phil Bouchard" :

On 07/12/2017 07:25 PM, Phil Bouchard wrote:

 On 07/12/2017 04:56 PM, Konstantin Tokarev wrote:

 Now add time of compilation to the sum


 So I just did benchmark the following C++ file featuring a loop within
 the code (the loop was at the bash shell level previously):
 https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

 With the exact equivalent in Javascript:
 https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js

 And the executable generated by g++ is still 1.7 times faster than by
 using Node.JS. For small Javascript perhaps the net speed are the same
 but the more complex the code is then the generated binary by g++ simply
 is faster when compared to the Node.JS interpreter.


The browser should "cache" these temporary executables anyway.


A you were following development of WebKit and JavaScriptCore, you should be
aware of story of using LLVM (i.e. "real" compiler) as a final JIT tier, and 
how did it
end up.

https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/


Thanks I'll read that today but also I forgot to mention "if" we were 
using a converter followed by a compiler then we could mix the two 
languages which in turns could take advantage of high performance when 
necessary (C++) and higher level algorithms (Javascript).



-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

13.07.2017, 02:39, "Phil Bouchard" :
> On 07/12/2017 07:25 PM, Phil Bouchard wrote:
>>  On 07/12/2017 04:56 PM, Konstantin Tokarev wrote:
>>>  Now add time of compilation to the sum
>>
>>  So I just did benchmark the following C++ file featuring a loop within
>>  the code (the loop was at the bash shell level previously):
>>  
>> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp
>>
>>  With the exact equivalent in Javascript:
>>  
>> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js
>>
>>  And the executable generated by g++ is still 1.7 times faster than by
>>  using Node.JS. For small Javascript perhaps the net speed are the same
>>  but the more complex the code is then the generated binary by g++ simply
>>  is faster when compared to the Node.JS interpreter.
>
> The browser should "cache" these temporary executables anyway.

A you were following development of WebKit and JavaScriptCore, you should be
aware of story of using LLVM (i.e. "real" compiler) as a final JIT tier, and 
how did it
end up.

https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/

>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/13/2017 12:13 AM, Thiago Macieira wrote:


Third, only 1.8 times faster? That's actually a very impressive JIT. I'd have
expected a much worse number.


Yes but the longer the loop lasts in the example, the greater the 
difference is between the executable and Node.JS.  The "speed slope" is 
more inclined in the case of the executable.


But if my browser is always 1.8 faster (2.2 faster when using cache) I 
personally would take it.



-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quarta-feira, 12 de julho de 2017 20:54:54 PDT Phil Bouchard wrote:
> On 07/12/2017 10:28 PM, Thiago Macieira wrote:
> > On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote:
> >> I don't know about you but a minimalist version of g++ embedded inside
> >> the
> >> browser could be beneficial big time.
> > 
> > Such a thing exists, it's called JIT.
> 
> I was reading the Wiki page:
> https://en.wikipedia.org/wiki/Just-in-time_compilation
> 
> And it says:
> "thus in theory JIT compilation can yield faster execution than static
> compilation"
> 
> But in practice a g++ compilation sequence followed by execution still
> is 1.8 times faster in the aforementioned test.  Maybe if you have
> pieces of code that are never executed then JIT would have a lead but
> serious/game engines for example stresses 100% of the code as far as I know.

That's not a fair comparison. First of all, the quote from Wikipedia is saying 
"in theory". That's because the JIT can actually optimise based on actual 
execution, the same way that PGO can do it.

Second, you're comparing one case.

Third, only 1.8 times faster? That's actually a very impressive JIT. I'd have 
expected a much worse number.

> The problem with JIT is its support also.  You need an army of coders to
> support the conversion from bytecode to assembly language, updates, etc.

The same can be said about the compiler. In the past year, there have been 
7700 commis by 164 different people in the GCC repository. This does not 
include binutils.

> Anyway I'm deviating from QNodePtr but I just don't understand the hype
> about JIT when it doesn't seem it has been compared to a Javascript
> compiler because none exists up to now.

JavaScript can't be entirely compiled since the types and behaviours of 
variables can change at runtime. And then there's the "eval" command.

> > There's also a tool to precompile a QML file. You should compare to that.
> 
> I know QML files can be compiled but I think the Qt Quick Compiler is
> being replaced by something else right now.  I'll have to investigate.

It's not.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/12/2017 07:25 PM, Phil Bouchard wrote:

On 07/12/2017 04:56 PM, Konstantin Tokarev wrote:


Now add time of compilation to the sum


So I just did benchmark the following C++ file featuring a loop within
the code (the loop was at the bash shell level previously):
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp


With the exact equivalent in Javascript:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js


And the executable generated by g++ is still 1.7 times faster than by
using Node.JS.  For small Javascript perhaps the net speed are the same
but the more complex the code is then the generated binary by g++ simply
is faster when compared to the Node.JS interpreter.


The browser should "cache" these temporary executables anyway.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/12/2017 10:58 AM, Phil Bouchard wrote:

Phil Bouchard  wrote:

On 07/11/2017 04:02 AM, Tim Blechmann wrote:

On the other hand, I have good news as I think I have found a way to
simulate functions that return a function.


how to you cope with structures like:

function foo( outObject )
{
var object = {}
outObject.object = object
outObject.result = function() { return object }
return function() { return bar( object ) }
}


I just manually wrote an emulation of Javascript code in C++ here:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp


I'll do some code cleanup tonight; it'll be much more readable regarding
return values.


The code is much more readable now:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/12/2017 04:56 PM, Konstantin Tokarev wrote:



12.07.2017, 22:35, "Phil Bouchard" :

Phil Bouchard  wrote:

 On 07/11/2017 06:36 AM, Konstantin Tokarev wrote:

 10.07.2017, 21:56, "Phil Bouchard" :

 Phil Bouchard  wrote:

 BTW converting Javascript into C++ seems very easy to do


 In fact, is it me or it would seem that:
 - converting the Javascript code into C++ on-the-fly
 - compiling the resulting C++ code


 This approach would have abysmal performance


 Would be a more efficient alternative than all these JIT tools?


 Not at all


 Maybe we can benchmark all this stuff once I'm done... just out of
 curiosity.


Actually I just did a benchmark of my "js2cpp" tool and interpreting the
code using Node.JS and js2cpp generates an executable that is 34 times
faster!


Now add time of compilation to the sum


So I just did benchmark the following C++ file featuring a loop within 
the code (the loop was at the bash shell level previously):

https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

With the exact equivalent in Javascript:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js

And the executable generated by g++ is still 1.7 times faster than by 
using Node.JS.  For small Javascript perhaps the net speed are the same 
but the more complex the code is then the generated binary by g++ simply 
is faster when compared to the Node.JS interpreter.



Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

12.07.2017, 22:35, "Phil Bouchard" :
> Phil Bouchard  wrote:
>>  On 07/11/2017 06:36 AM, Konstantin Tokarev wrote:
>>>  10.07.2017, 21:56, "Phil Bouchard" :
  Phil Bouchard  wrote:
>  BTW converting Javascript into C++ seems very easy to do

  In fact, is it me or it would seem that:
  - converting the Javascript code into C++ on-the-fly
  - compiling the resulting C++ code
>>>
>>>  This approach would have abysmal performance
>>>
  Would be a more efficient alternative than all these JIT tools?
>>>
>>>  Not at all
>>
>>  Maybe we can benchmark all this stuff once I'm done... just out of
>>  curiosity.
>
> Actually I just did a benchmark of my "js2cpp" tool and interpreting the
> code using Node.JS and js2cpp generates an executable that is 34 times
> faster!

Now add time of compilation to the sum

>
> I don't know about you but a minimalist version of g++ embedded inside the
> browser could be beneficial big time.
>
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Phil Bouchard  wrote:
> On 07/11/2017 06:36 AM, Konstantin Tokarev wrote:
>> 
>> 
>> 10.07.2017, 21:56, "Phil Bouchard" :
>>> Phil Bouchard  wrote:
 BTW converting Javascript into C++ seems very easy to do
>>> 
>>> In fact, is it me or it would seem that:
>>> - converting the Javascript code into C++ on-the-fly
>>> - compiling the resulting C++ code
>> 
>> This approach would have abysmal performance
>> 
>>> 
>>> Would be a more efficient alternative than all these JIT tools?
>> 
>> Not at all
> 
> Maybe we can benchmark all this stuff once I'm done... just out of 
> curiosity.

Actually I just did a benchmark of my "js2cpp" tool and interpreting the
code using Node.JS and js2cpp generates an executable that is 34 times
faster!

I don't know about you but a minimalist version of g++ embedded inside the
browser could be beneficial big time.


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Phil Bouchard  wrote:
> On 07/11/2017 04:02 AM, Tim Blechmann wrote:
>>> On the other hand, I have good news as I think I have found a way to
>>> simulate functions that return a function.
>> 
>> how to you cope with structures like:
>> 
>> function foo( outObject )
>> {
>> var object = {}
>> outObject.object = object
>> outObject.result = function() { return object }
>> return function() { return bar( object ) }
>> }
> 
> I just manually wrote an emulation of Javascript code in C++ here:
> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

I'll do some code cleanup tonight; it'll be much more readable regarding
return values.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT 5.9. Issues with QWebEngine

[Sudhir Sharma]

Hi Kai,

Thanks for your prompt response.

Before loading any URL In QWebEngine, I am making it use System Proxy 
Configuration by following code;

QNetworkProxyFactory::setUseSystemConfiguration(true);

After this if I query the proxy, I get correct proxy address which is 
configured in Web Browser.
But with this setting I cannot load local URLs in QWebEngine.

Regards,
Sudhir

-Original Message-
From: Kai Koehne [mailto:kai.koe...@qt.io] 
Sent: Wednesday, July 12, 2017 4:37 PM
To: Sudhir Sharma ; development@qt-project.org
Subject: RE: QT 5.9. Issues with QWebEngine

* You are receiving this mail from an external source *

Hi Sudhir,

This is best discussed on bugreports.qt.io, in a bug report for component 
"WebEngine" in project "Qt".

Please include on how you want to set a (non-local) proxy:
- through the system settings or
- through QNetworkProxy::applicationProxy

Regards

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Sudhir Sharma
> Sent: Mittwoch, 12. Juli 2017 12:18
> To: development@qt-project.org
> Subject: [Development] QT 5.9. Issues with QWebEngine
>
> HI,
>
>
>
> QWebEngine does not take exact proxy settings from System (as done in 
> internet browsers like Chrome)
>
> Internet client is configured to use proxy for internet addresses and 
> bypass it for local addresses.
>
>
>
> But it does not happen. QWebEngine fails to bypass proxy for local urls.
>
>
>
> Scenarios:
>
>
>
> -  Remove proxy in Browser. -> webengine is able to load local urls 
> but
> NOT internet URLs
>
> -  Add proxy in browser -> webengine is able to load  internet URLs 
> but
> NOT local URLs
>
> -  If I set the proxy in browser and check to ignore local addresses,
> browser works fine for both local and internet addresses. I am 
> expecting same functionality from QWebEngine.
>
>
>
> Please suggest if it is possible.
>
>
>
> Regarsds,
>
> Sudhir
>
>
>
>
>
>
> 
>
>
> http://www.mindtree.com/email/disclaimer.html

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT 5.9. Issues with QWebEngine

[Kai Koehne]

Hi Sudhir,

This is best discussed on bugreports.qt.io, in a bug report for component 
"WebEngine" in project "Qt". 

Please include on how you want to set a (non-local) proxy:
- through the system settings or
- through QNetworkProxy::applicationProxy

Regards

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Sudhir Sharma
> Sent: Mittwoch, 12. Juli 2017 12:18
> To: development@qt-project.org
> Subject: [Development] QT 5.9. Issues with QWebEngine
> 
> HI,
> 
> 
> 
> QWebEngine does not take exact proxy settings from System (as done in
> internet browsers like Chrome)
> 
> Internet client is configured to use proxy for internet addresses and bypass 
> it
> for local addresses.
> 
> 
> 
> But it does not happen. QWebEngine fails to bypass proxy for local urls.
> 
> 
> 
> Scenarios:
> 
> 
> 
> -  Remove proxy in Browser. -> webengine is able to load local urls 
> but
> NOT internet URLs
> 
> -  Add proxy in browser -> webengine is able to load  internet URLs 
> but
> NOT local URLs
> 
> -  If I set the proxy in browser and check to ignore local addresses,
> browser works fine for both local and internet addresses. I am expecting
> same functionality from QWebEngine.
> 
> 
> 
> Please suggest if it is possible.
> 
> 
> 
> Regarsds,
> 
> Sudhir
> 
> 
> 
> 
> 
> 
> 
> 
> 
> http://www.mindtree.com/email/disclaimer.html

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Grégoire Barbier]

Le 11/07/2017 à 13:49, Phil Bouchard a écrit :

On 07/11/2017 04:02 AM, Tim Blechmann wrote:

On the other hand, I have good news as I think I have found a way to
simulate functions that return a function.


how to you cope with structures like:

function foo( outObject )
{
var object = {}
outObject.object = object
outObject.result = function() { return object }
return function() { return bar( object ) }
}


I'm looking into stuff like that so I am mimicking a run-time stack in 
my example:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp 



Meanwhile please define bar();


IMHO it become especially interesting in terms of root_ptr if bar is a 
function which:

- stores object in a global variable,
- or affect it as property values to several different QML items with 
different lifecycles,
- or even send it to C++ through a signal the slot being able of calling 
QQmlEngine::setObjectOwnership() if it wants, or add the object as a 
global variable from C++ using, for instance 
QJSEngine::globalObject().setProperty().


Regards.

--
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/11/2017 06:36 AM, Konstantin Tokarev wrote:



10.07.2017, 21:56, "Phil Bouchard" :

Phil Bouchard  wrote:

 BTW converting Javascript into C++ seems very easy to do


In fact, is it me or it would seem that:
- converting the Javascript code into C++ on-the-fly
- compiling the resulting C++ code


This approach would have abysmal performance



Would be a more efficient alternative than all these JIT tools?


Not at all


Maybe we can benchmark all this stuff once I'm done... just out of 
curiosity.



-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/11/2017 04:02 AM, Tim Blechmann wrote:

On the other hand, I have good news as I think I have found a way to
simulate functions that return a function.


how to you cope with structures like:

function foo( outObject )
{
var object = {}
outObject.object = object
outObject.result = function() { return object }
return function() { return bar( object ) }
}


I just manually wrote an emulation of Javascript code in C++ here:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

And I have the following output:
int main(): BEGIN
main()::__lambda1
main()::__lambda1::__lambda3
main()::__lambda0
int main(): END

Note that I just realized it's impossible the variable lookups in 
Javascript are instantaneous and it must be done the way it's done in my 
example because it's all run-time in the Javascript engine.



Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Simon Hausmann <simon.hausm...@qt.io> wrote:
> 
> bar shall be a global variable that is callable (i.e. somebody
> initialized it with a function closure). When invoked it shall return
> either a primitive value or a JavaScript object and takes one arbitrary 
> parameter.
> 
> 
> It is an implementation detail whether it returns the parameter provided,
> or "42" (either as string or number :) and the behavior may change at 
> run-time.
> 
> 
> So at the compilation time of this snippet, all we basically know is
> 
> 
> var bar;
> 
> 
> It could be that bar was initialized to "100", in which case I think an
> exception would be thrown at the attempt of calling it.
> 
> 
> Simon
> 
> 
> From: Development
> <development-bounces+simon.hausmann=qt...@qt-project.org> on behalf of Phil 
> Bouchard
> <philipp...@gmail.com>
> Sent: Tuesday, July 11, 2017 1:49:05 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.9's new garbage collector documentation? + 
> root_ptr
> 
> On 07/11/2017 04:02 AM, Tim Blechmann wrote:
>>> On the other hand, I have good news as I think I have found a way to
>>> simulate functions that return a function.
>> 
>> how to you cope with structures like:
>> 
>> function foo( outObject )
>> {
>> var object = {}
>> outObject.object = object
>> outObject.result = function() { return object }
>> return function() { return bar( object ) }
>> }
> 
> I'm looking into stuff like that so I am mimicking a run-time stack in
> my example:
> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp
> 
> Meanwhile please define bar();
> 
> 
> Thanks,
> -Phil
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> --_000_VI1PR02MB10065F354A27556625565A498CAE0VI1PR02MB1006eurp_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
> 
> 
> <!-- .EmailQuote { margin-left: 1pt;
> padding-left: 4pt; border-left: #80 2px solid; } -->
> 
> 
> 
> 
> <!--
> p
>   {margin-top:0;
>   margin-bottom:0}
> -->
> 
> 
> 
> 
> 
> bar shall be a global variable that is callable (i.e. somebody
> initialized it with a function closure). When invoked it shall
> returneither a
> primitive value or a JavaScript
> object and takes one arbitrary
> parameter.
> 
> 
> It is an implementation detail whether it returns the parameter
> provided, or 42 (either as string or number :) and the
> behavior may change at run-time.
> 
> 
> So at the compilation time of this snippet, all we basically know is
> 
> 
>   var bar;
> 
> 
> It could be that bar was initialized to 100, in which case
> I think an exception would be thrown at the attempt of calling it.
> 
> 
> Simon
> 
> 
>  color="#00" style="font-size:11pt">From: Development
> development-bouncessimon.hausmann=qt...@qt-project.org on
> behalf of Phil Bouchard philipp...@gmail.com
> Sent: Tuesday, July 11, 2017 1:49:05 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.9's new garbage collector
> documentation?  root_ptr
> 
> 
> 
> 
> On 07/11/2017 04:02 AM, Tim Blechmann wrote:
>  On the other hand, I have good news as I think I have found a way 
> to
>  simulate functions that return a function.
> 
>  how to you cope with structures like:
> 
>  function foo( outObject )
>  {
>  var object = {}
>  outObject.object = object
>  outObject.result = function() { return object 
> }
>  return function() { return bar( object ) }
>  }
> 
> I'm looking into stuff like that so I am mimicking a run-time stack in 
> my example:
>  href="https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp;>https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp
> 
> Meanwhile please define bar();
> 
> 
> Thanks,
> -Phil
> 
> ___
> Development mailing list
> Development@qt-project.org
>  href="http://lists.qt-project.org/mailman/listinfo/development;>http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> 
> 
> --_000_VI1PR02MB10065F354A27556625565A498CAE0VI1PR02MB1006eurp_--

Ok thanks. I'm confident it'll work.


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Simon Hausmann]

bar shall be a global variable that is callable (i.e. somebody initialized it 
with a function closure). When invoked it shall return either a primitive value 
or a JavaScript object and takes one arbitrary parameter.


It is an implementation detail whether it returns the parameter provided, or 
"42" (either as string or number :) and the behavior may change at run-time.


So at the compilation time of this snippet, all we basically know is


var bar;


It could be that bar was initialized to "100", in which case I think an 
exception would be thrown at the attempt of calling it.


Simon


From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> on 
behalf of Phil Bouchard <philipp...@gmail.com>
Sent: Tuesday, July 11, 2017 1:49:05 PM
To: development@qt-project.org
Subject: Re: [Development] Qt 5.9's new garbage collector documentation? + 
root_ptr

On 07/11/2017 04:02 AM, Tim Blechmann wrote:
>> On the other hand, I have good news as I think I have found a way to
>> simulate functions that return a function.
>
> how to you cope with structures like:
>
> function foo( outObject )
> {
> var object = {}
> outObject.object = object
> outObject.result = function() { return object }
> return function() { return bar( object ) }
> }

I'm looking into stuff like that so I am mimicking a run-time stack in
my example:
https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

Meanwhile please define bar();


Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/11/2017 04:02 AM, Tim Blechmann wrote:

On the other hand, I have good news as I think I have found a way to
simulate functions that return a function.


how to you cope with structures like:

function foo( outObject )
{
var object = {}
outObject.object = object
outObject.result = function() { return object }
return function() { return bar( object ) }
}


I'm looking into stuff like that so I am mimicking a run-time stack in 
my example:

https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp

Meanwhile please define bar();


Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

10.07.2017, 21:56, "Phil Bouchard" :
> Phil Bouchard  wrote:
>>  BTW converting Javascript into C++ seems very easy to do
>
> In fact, is it me or it would seem that:
> - converting the Javascript code into C++ on-the-fly
> - compiling the resulting C++ code

This approach would have abysmal performance

>
> Would be a more efficient alternative than all these JIT tools?

Not at all

>
> My 2 cents,
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

11.07.2017, 07:52, "Phil Bouchard" :
> On 07/10/2017 05:08 PM, Thiago Macieira wrote:
>>  On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote:
>>>  Phil Bouchard  wrote:
  BTW converting Javascript into C++ seems very easy to do
>>>
>>>  In fact, is it me or it would seem that:
>>>  - converting the Javascript code into C++ on-the-fly
>>>  - compiling the resulting C++ code
>>>
>>>  Would be a more efficient alternative than all these JIT tools?
>>
>>  No. That would require having a C++ compiler with all the dependent 
>> libraries
>>  on every user's device.
>>
>>  You must run the JS as provided and interact with the plugins as they exist
>>  today.
>
> Indeed Javascript is not made to run heavy CPU algorithms anyways.

Really? 

http://browserbench.org/JetStream/

>
> On the other hand, I have good news as I think I have found a way to
> simulate functions that return a function. I know a Javascript to C++
> converter is not what we're looking for but it helps me understand these
> cases better.
>
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Tim Blechmann]

> On the other hand, I have good news as I think I have found a way to
> simulate functions that return a function.

how to you cope with structures like:

function foo( outObject )
{
var object = {}
outObject.object = object
outObject.result = function() { return object }
return function() { return bar( object ) }
}

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/10/2017 05:08 PM, Thiago Macieira wrote:

On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote:

Phil Bouchard  wrote:

BTW converting Javascript into C++ seems very easy to do


In fact, is it me or it would seem that:
- converting the Javascript code into C++ on-the-fly
- compiling the resulting C++ code

Would be a more efficient alternative than all these JIT tools?


No. That would require having a C++ compiler with all the dependent libraries
on every user's device.

You must run the JS as provided and interact with the plugins as they exist
today.


Indeed Javascript is not made to run heavy CPU algorithms anyways.

On the other hand, I have good news as I think I have found a way to 
simulate functions that return a function.  I know a Javascript to C++ 
converter is not what we're looking for but it helps me understand these 
cases better.



-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote:
> Phil Bouchard  wrote:
> > BTW converting Javascript into C++ seems very easy to do
> 
> In fact, is it me or it would seem that:
> - converting the Javascript code into C++ on-the-fly
> - compiling the resulting C++ code
> 
> Would be a more efficient alternative than all these JIT tools?

No. That would require having a C++ compiler with all the dependent libraries 
on every user's device.

You must run the JS as provided and interact with the plugins as they exist 
today.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Sérgio Martins]

On Wed, Jul 5, 2017 at 5:03 AM, Phil Bouchard  wrote:
> Hi,
>
> I read Qt 5.9 is using a new garbage collector that is more predictable.
> First good job and second I was wondering if there is any documentation on
> that garbage collector in question.

The documentation is probably this:
https://codereview.qt-project.org/#/c/180739/, git log is also good,
setting breakpoints and looking at the stack trace is also useful to
learn complicated code bases.

> I guess if there is any interests to make the garbage collector perfectly
> deterministic then root_ptr could be relatively easily integrated at this
> stage.

Interest will only come when people see a QML app running on it. The
maintainer(s) won't invest much time helping if he doesn't believe in
the idea.

If you try and fail, at least you'll learn a lot about QML and V4 and
probably find other types of improvements.


Regards,
Sergio Martins
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Phil Bouchard  wrote:
> 
> BTW converting Javascript into C++ seems very easy to do

In fact, is it me or it would seem that:
- converting the Javascript code into C++ on-the-fly
- compiling the resulting C++ code

Would be a more efficient alternative than all these JIT tools?


My 2 cents,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Thiago Macieira  wrote:
> On domingo, 9 de julho de 2017 21:13:33 PDT Phil Bouchard wrote:
>> On 07/09/2017 10:22 PM, Phil Bouchard wrote:
>>> On 07/09/2017 06:35 PM, Phil Bouchard wrote:
 I'm sure there is an equivalent in
 Qt but I'll need some pointers to speed things up.
>>> 
>>> I think QAtomicInt is the perfect replacement:
>>> http://doc.qt.io/qt-4.8/qatomicint.html#details
>> 
>> I started another branch reserved for Qt here:
>> https://github.com/philippeb8/root_ptr/tree/qt
> 
> Just to be clear: writing the pointer class is not enough. Someone has to 
> port 
> the JS engine.

BTW converting Javascript into C++ seems very easy to do; but I'll need to
analyze the JS engine first with some help from some expert if I want to
integrate it, thanks.

Also I will revert the change I made which "upscales the scope of a
variable". That change was wrong and the manager will be like it was before
(better).


Regards,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On domingo, 9 de julho de 2017 15:35:43 PDT Phil Bouchard wrote:
> > You'll also need to disentangle it from Boost before it can be used in Qt.
> > Move it to independent headers depending only on the C++98 standard
> > library ( C++11 core language features are ok).
> 
> The licenses are incompatible?  I think I was relying heavily on
>  because Peter Dimov wrote a
> portable atomic reference counter.  I'm sure there is an equivalent in
> Qt but I'll need some pointers to speed things up.

No, it's not a licensing problem, just that of dependency. We will not depend 
on a prior Boost installation.

If you're looking for a reference counter, we have QRefCount, not to mention 
QAtomicInt. We've had those for longer than they existed in the C++ standard.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On sábado, 8 de julho de 2017 15:57:50 PDT Phil Bouchard wrote:
> https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_examp
> le1.cpp
> 
> The application outputs:
> Scope 0: BEGIN
> Scope 1: BEGIN
> A::A(const boost::node_proxy&)
> A::A(const boost::node_proxy&)
> A::~A()
> Scope 1: END
> A::~A()
> Scope 0: END

Why are there two A::A and two A::~A in the output if the source has four 
objects created?

> Which is exactly what we want.  Note that I didn't stress tested it yet.
>   If you don't mind I will start a new thread with the Boost mailing
> list to see their opinion.

You'll also need to disentangle it from Boost before it can be used in Qt. 
Move it to independent headers depending only on the C++98 standard library (
C++11 core language features are ok).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/08/2017 12:42 AM, Phil Bouchard wrote:

On 07/07/2017 10:14 PM, Phil Bouchard wrote:


But if I can do a deep copy then I can certainly "re-set" the variable
(change the set the variable is owned by).  If I can do that then we
won't need any deep copy.

I just need to think a little bit... thanks for your patience.


Yes of course: I just need to add some metadata so the re-setting can
propagate in a specific variable.

I'll work on an engine to demonstrate its validity.


Alright I already got something.  If we mimic the Javascript function 
scope in C++ then we'll have the following:

https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_example1.cpp

The application outputs:
Scope 0: BEGIN
Scope 1: BEGIN
A::A(const boost::node_proxy&)
A::A(const boost::node_proxy&)
A::~A()
Scope 1: END
A::~A()
Scope 0: END

Which is exactly what we want.  Note that I didn't stress tested it yet. 
 If you don't mind I will start a new thread with the Boost mailing 
list to see their opinion.



Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Tim Blechmann]

> - the parameters of the function will remain unaffected if they are used as 
> r-values
> - the parameters of the function will require a deep copy of the expression 
> if they are used as l-values 

https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing


function foo( arg )
{
  var img = readImage( arg.source );
  arg.result = img;
  return img;
}

required semantics: arg.result and the return value refer to the same
object.

--

btw, it may be interesting for you to read a bit about escape analysis.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On sexta-feira, 7 de julho de 2017 06:30:22 PDT Phil Bouchard wrote:
> > how do you solve the situation that an object might be referenced by
> > multiple roots?
> 
> Please elaborate because as far as I know variables in Javascript have a
> function scope and functions can be nested (waterfall parent-child
> hierarchy). So child functions can access the parent variables because the
> root_ptr of the child will be deleted before its parent.

Both in HTML and in QML, JS objects may be used to interchange data between 
multiple pages. That means the object belongs to both pages and should not be 
freed until both of them stop referencing it.

> Thus all I need to do is:
> - add some implicit parameter to functions which will represent return
> variables
> - remove the ability of root_ptr from unifying with other sets

You're speaking in abstract terms. We actually need code.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Tim Blechmann  wrote:
>> If there is one root_ptr per
>> Javascript function then all local variables are guaranteed to be
>> destroyed.  And closures aren't too big of a deal either because child
>> objects can easily refer to their parent.
>> 
>> But returning local variables might need some work on root_ptr such as
>> "unlisting" the variable from one set in order to "enlist" it to the
>> parent set.
> 
> how do you solve the situation that an object might be referenced by
> multiple roots?
> 

Please elaborate because as far as I know variables in Javascript have a
function scope and functions can be nested (waterfall parent-child
hierarchy). So child functions can access the parent variables because the
root_ptr of the child will be deleted before its parent.

Thus all I need to do is:
- add some implicit parameter to functions which will represent return
variables
- remove the ability of root_ptr from unifying with other sets


Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

Phil Bouchard  wrote:
> On 07/07/2017 04:39 AM, Edward Welbourne wrote:
>> Phil Bouchard (7 July 2017 04:15)
>>> 
>>> Anything that goes in that HTML page or QML window we don't care.  The
>>> reference counted property of root_ptr (node_ptr) will handle it and
>>> the associated root_ptr will clean up the mess when it is destroyed.
>> 
>> You'd need to apply root_ptr on a finer granularity than the top-level
>> HTML page or QML window.  For example, when a function gets called in an
>> interpreted language, there's something like a "stack frame" created,
>> within the context of which the function executes, finally returning
>> some value to the caller.  To complicate life, that frame may survive
>> the return as a closure (e.g. if the return values is a function object
>> that references locals of the frame).  In C++, exiting a scope (which
>> corresponds to such a frame) calls destructors on all the objects
>> declared in the scope; but that doesn't happen in JavaScript, which
>> relies on the garbage-collector to catch those objects after they've
>> passed out of scope.  If you can convincingly exhibit an interpreted
>> language using root_ptr for each of those frames, without causing
>> breakage (you'll need to make sure the returned value can't end up
>> holding any references to values owned by that frame; and you'll need to
>> interact correctly with closures), you'll have a more convincing case
>> for your innovation.
>> 
>> As long as you pitch your idea in terms of the top-level HTML page or
>> QML window, you aren't convincing - because we *know* that'll leave huge
>> amounts of transiently-used memory that doesn't get released until the
>> page or window is closed, which is *far* too late.  Show that you can
>> make it work at the level where it would actually reclaim memory sooner
>> than a garbage collector would.  Then folk might listen.
> 
> Ok thanks for the detailed analysis.  If there is one root_ptr per 
> Javascript function then all local variables are guaranteed to be 
> destroyed.  And closures aren't too big of a deal either because child 
> objects can easily refer to their parent.
> 
> But returning local variables might need some work on root_ptr such as 
> "unlisting" the variable from one set in order to "enlist" it to the 
> parent set.  I also will need to remove the ability from root_ptr to 
> "unify" sets when one of its node_ptr refers to an object from another set.
> 
> If I can do that then there is no need to create a new language.
> 
> 
> Thanks,
> -Phil
> 

Actually all that is needed to be done for that return value is to threat
that return value like an implicit parameter. Ex.:

var res;
function foo(res)
{
res = 1;
}
alert((foo(res), res)); // outputs 1

Which is the same as:
function foo()
{
return 1;
}
alert(foo()); // outputs 1


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Tim Blechmann]

> If there is one root_ptr per
> Javascript function then all local variables are guaranteed to be
> destroyed.  And closures aren't too big of a deal either because child
> objects can easily refer to their parent.
> 
> But returning local variables might need some work on root_ptr such as
> "unlisting" the variable from one set in order to "enlist" it to the
> parent set.

how do you solve the situation that an object might be referenced by
multiple roots?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/07/2017 04:39 AM, Edward Welbourne wrote:

Phil Bouchard (7 July 2017 04:15)


Anything that goes in that HTML page or QML window we don't care.  The
reference counted property of root_ptr (node_ptr) will handle it and
the associated root_ptr will clean up the mess when it is destroyed.


You'd need to apply root_ptr on a finer granularity than the top-level
HTML page or QML window.  For example, when a function gets called in an
interpreted language, there's something like a "stack frame" created,
within the context of which the function executes, finally returning
some value to the caller.  To complicate life, that frame may survive
the return as a closure (e.g. if the return values is a function object
that references locals of the frame).  In C++, exiting a scope (which
corresponds to such a frame) calls destructors on all the objects
declared in the scope; but that doesn't happen in JavaScript, which
relies on the garbage-collector to catch those objects after they've
passed out of scope.  If you can convincingly exhibit an interpreted
language using root_ptr for each of those frames, without causing
breakage (you'll need to make sure the returned value can't end up
holding any references to values owned by that frame; and you'll need to
interact correctly with closures), you'll have a more convincing case
for your innovation.

As long as you pitch your idea in terms of the top-level HTML page or
QML window, you aren't convincing - because we *know* that'll leave huge
amounts of transiently-used memory that doesn't get released until the
page or window is closed, which is *far* too late.  Show that you can
make it work at the level where it would actually reclaim memory sooner
than a garbage collector would.  Then folk might listen.


Ok thanks for the detailed analysis.  If there is one root_ptr per 
Javascript function then all local variables are guaranteed to be 
destroyed.  And closures aren't too big of a deal either because child 
objects can easily refer to their parent.


But returning local variables might need some work on root_ptr such as 
"unlisting" the variable from one set in order to "enlist" it to the 
parent set.  I also will need to remove the ability from root_ptr to 
"unify" sets when one of its node_ptr refers to an object from another set.


If I can do that then there is no need to create a new language.


Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Harri Porten]

On Thu, 6 Jul 2017, Thiago Macieira wrote:


By the way, how does it break the cycle?


Like I was saying before, node_ptr enlists each pointee object to the
associated root_ptr and when the root_ptr is destroyed then everything
gets wiped out.


See above. Your answer is "it doesn't break the cycle".


Right. And from first hand experience I can report: I've tried hard to 
make a deterministic and quick deletion work in a JS engine (through 
reference counting, etc.) but always ended up with leaks.


The scope of JS objects is sometimes also not limited to a single 
container like a HTML page. Often data can be passed/accessed to/from 
other containers. Thus breaking the concept of a isolated roots.


Harri.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Edward Welbourne]

On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote:
>>> It's all memory usage and bad programming habits vs execution speed.
>>> Why would you want to add objects that are never used?  A minimum
>>> programming skills set is required here.  You're saying the actual
>>> garbage collector should compensate for programming errors when I'm
>>> saying that's the programmer's responsibility.

That's not what garbage collection is about.  It's about objects that
are used transiently (e.g. in evaluating expressions) by some long-lived
entity (whose root_ptr thus won't go away any time soon).  After they've
been used, the garbage collector notices they're no longer in use and
tidies them away, well within the life-time of the entity that used
them.  Memory is thus released significantly earlier than it would be if
you rely on a root_ptr associated with that long-lived entity.

On 07/06/2017 11:10 AM, Thiago Macieira wrote:
>> I'm saying that the garbage collector has to compensate for language
>> requirements. Do you even know JavaScript? Temporary variables are
>> created all the time in the process of any algorithm; global state
>> variables could be cleared depending on usage; etc.
>>
>> The point is that the *language* requires us to have a garbage
>> collector to operate like that. So explain to me how root_ptr will
>> work in that context.

Phil Bouchard (7 July 2017 04:15)
> As you know in Javascript temporary unnamed variables from a primitive
> type are no different than local variables and even if global
> variables are not encouraged then they will be destroyed when the HTML
> page or QML window is killed.

This is far too late; the garbage collector gets much sooner after they
drop out of use, particularly when the HTML page or QML window *is* the
application, that's going to run for days.

> All root_ptr requires is to draw the line and isolate "entities" which
> have a birth and a certain death.  That is the case with HTML pages
> and QML windows and we can take advantage of that.
>
> Anything that goes in that HTML page or QML window we don't care.  The
> reference counted property of root_ptr (node_ptr) will handle it and
> the associated root_ptr will clean up the mess when it is destroyed.

You'd need to apply root_ptr on a finer granularity than the top-level
HTML page or QML window.  For example, when a function gets called in an
interpreted language, there's something like a "stack frame" created,
within the context of which the function executes, finally returning
some value to the caller.  To complicate life, that frame may survive
the return as a closure (e.g. if the return values is a function object
that references locals of the frame).  In C++, exiting a scope (which
corresponds to such a frame) calls destructors on all the objects
declared in the scope; but that doesn't happen in JavaScript, which
relies on the garbage-collector to catch those objects after they've
passed out of scope.  If you can convincingly exhibit an interpreted
language using root_ptr for each of those frames, without causing
breakage (you'll need to make sure the returned value can't end up
holding any references to values owned by that frame; and you'll need to
interact correctly with closures), you'll have a more convincing case
for your innovation.

As long as you pitch your idea in terms of the top-level HTML page or
QML window, you aren't convincing - because we *know* that'll leave huge
amounts of transiently-used memory that doesn't get released until the
page or window is closed, which is *far* too late.  Show that you can
make it work at the level where it would actually reclaim memory sooner
than a garbage collector would.  Then folk might listen.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quinta-feira, 6 de julho de 2017 20:48:27 PDT Phil Bouchard wrote:
> > How well does root_ptr operate when there are cyclic references?
> > JavaScript
> > objects can refer to each other, so how do you propose the engine handle
> > that case?
> 
> It's very easy.  Every time a node_ptr is created, it enlists the
> pointee object to its associated root_ptr.  When the root_ptr is
> destroyed then all associated objects in that list are destroyed as
> well.  This is how cyclic references are guaranteed to be destroyed
> deterministically.

In other words, "it doesn"t".

In the JS world, if those two objects refer to each other and nothing else 
refers to them, then they both can be garbage-collected.

> > Nor are we. Show us that it working and we'll take a chance. A theoretical
> > solution with no real-life implementation is not for us.
> > 
> > Have you impemented any engine for garbage collected languages using
> > root_ptr? How well does root_ptr work with the Python engine? Or a Java
> > VM? Lua? Ruby? Any scripting language VMs implemented using it?
> 
> No but it works well with neural networks which I think is a good
> example of a worse case situation:
> https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp

No, I don't think it's a good analogy. I'dl ike to see it in the engine of a 
scripted language.

> > If the order of destruction according to the language is undefined, then
> > the order in which root_ptr destroys it is not relevant and it can't be
> > considered a plus. In fact, having it deterministic could be a negative
> > asset, since someone writing this code will never be exposed to
> > undefinedness of their code.
> I certainly think it's a plus for debugging purposes.  And I fail to
> understand the advantage of the undefinedness of the code.

The other engines are the problem. Granted, that won't happen for QML, since 
there's only one engine. But for JS, developers have to cope with the 
differences in behaviour.

> > By the way, how does it break the cycle?
> 
> Like I was saying before, node_ptr enlists each pointee object to the
> associated root_ptr and when the root_ptr is destroyed then everything
> gets wiped out.

See above. Your answer is "it doesn't break the cycle".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/06/2017 10:57 PM, Thiago Macieira wrote:

On quinta-feira, 6 de julho de 2017 19:15:02 PDT Phil Bouchard wrote:


As you know in Javascript temporary unnamed variables from a primitive
type are no different than local variables and even if global variables
are not encouraged then they will be destroyed when the HTML page or QML
window is killed.


That is too late. QML pages are meant to be open for a long time, like the
application's main screen. There are even web pages that operate like that
today -- I certainly have a few always-interacting and always-on webpages open
on my Chrome. If the garbage collector did not run, I'm sure the memory use
would be higher.


Well then you scale down the usage of root_ptr to containers like a 
listview which is constantly refreshed for most applications.  It's the 
same with a Gmail webpage which has a listview that is constantly 
refreshed because you keep pressing on the Inbox button to refresh it.



Anything that goes in that HTML page or QML window we don't care.  The
reference counted property of root_ptr (node_ptr) will handle it and the
associated root_ptr will clean up the mess when it is destroyed.


How well does root_ptr operate when there are cyclic references? JavaScript
objects can refer to each other, so how do you propose the engine handle that
case?


It's very easy.  Every time a node_ptr is created, it enlists the 
pointee object to its associated root_ptr.  When the root_ptr is 
destroyed then all associated objects in that list are destroyed as 
well.  This is how cyclic references are guaranteed to be destroyed 
deterministically.



Well I'm here to help Qt because I know quite well that WebKit for
Wayland is the number 1 rendering engine and Javascript processor.


Your motivation is at odds with your objective. We don't maintain WebKit.
There's barely any participation from us at all.

And the QML engine is neither WebKit's (JSC) nor Blink's (V8). It's our own.


Sorry I meant that I'm here to help Qt to have a better product than the 
competition.



The
problem with WebKit is that their garbage collector is inlaid with the
code of WebKit, making it impossible to throw away the garbage
collector.  And WebKit is an engineering product which means they are
not interested into innovative theoretical libraries that just came out
of the oven.


Nor are we. Show us that it working and we'll take a chance. A theoretical
solution with no real-life implementation is not for us.

Have you impemented any engine for garbage collected languages using root_ptr?
How well does root_ptr work with the Python engine? Or a Java VM? Lua? Ruby?
Any scripting language VMs implemented using it?


No but it works well with neural networks which I think is a good 
example of a worse case situation:

https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp


On the other hand it seems quite possible to upgrade or change the
garbage collector in the Qt library and if we analyze the integration of
root_ptr carefully then it should be done quickly.


Again, QtQml engine is really tied to JavaScript. I don't think you can get
out of having a garbage collector at all.


I guess we could ask Qt's garbage collector experts.


If the order of destruction according to the language is undefined, then the
order in which root_ptr destroys it is not relevant and it can't be considered
a plus. In fact, having it deterministic could be a negative asset, since
someone writing this code will never be exposed to undefinedness of their code.


I certainly think it's a plus for debugging purposes.  And I fail to 
understand the advantage of the undefinedness of the code.



By the way, how does it break the cycle?


Like I was saying before, node_ptr enlists each pointee object to the 
associated root_ptr and when the root_ptr is destroyed then everything 
gets wiped out.



All that is required here is to analyze the situation carefully and
we'll have a faster Javascript engine instead of just trying to patch
the existing GC.  And the GC should be an abstraction we can replace and
it shouldn't be part of the definition of Javascript.


No, all that is required is that someone actually write the code. Are you
volunteering or do you have anyone who understands root_ptr that is?


Nobody really understands root_ptr despite all the documentation I 
wrote.  I think the only one most familiar with it is Peter Dimov; the 
author of shared_ptr.


Fortunately I am almost done with the following projects:
http://www.finitetheory.com
https://www.actatabula.com

So I am volunteering but I can't compile the whole Qt library on my 
laptop so I'll need stripped out packages and some Q so that I can 
first understand what is so special with the GC.



Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quinta-feira, 6 de julho de 2017 19:15:02 PDT Phil Bouchard wrote:
> > The point is that the *language* requires us to have a garbage collector
> > to
> > operate like that. So explain to me how root_ptr will work in that
> > context.
> 
> As you know in Javascript temporary unnamed variables from a primitive
> type are no different than local variables and even if global variables
> are not encouraged then they will be destroyed when the HTML page or QML
> window is killed.

That is too late. QML pages are meant to be open for a long time, like the 
application's main screen. There are even web pages that operate like that 
today -- I certainly have a few always-interacting and always-on webpages open 
on my Chrome. If the garbage collector did not run, I'm sure the memory use 
would be higher.

> All root_ptr requires is to draw the line and isolate "entities" which
> have a birth and a certain death.  That is the case with HTML pages and
> QML windows and we can take advantage of that.

Sorry, not workable.

> Anything that goes in that HTML page or QML window we don't care.  The
> reference counted property of root_ptr (node_ptr) will handle it and the
> associated root_ptr will clean up the mess when it is destroyed.

How well does root_ptr operate when there are cyclic references? JavaScript 
objects can refer to each other, so how do you propose the engine handle that 
case?

> > Sure. A choice of different engines, completely different APIs. If the
> > user
> > wants root_ptr, they can write their application using something other
> > than
> > QtQml. Nothing is stopping them from it.
> 
> Well I'm here to help Qt because I know quite well that WebKit for
> Wayland is the number 1 rendering engine and Javascript processor.

Your motivation is at odds with your objective. We don't maintain WebKit. 
There's barely any participation from us at all.

And the QML engine is neither WebKit's (JSC) nor Blink's (V8). It's our own.

> The
> problem with WebKit is that their garbage collector is inlaid with the
> code of WebKit, making it impossible to throw away the garbage
> collector.  And WebKit is an engineering product which means they are
> not interested into innovative theoretical libraries that just came out
> of the oven.

Nor are we. Show us that it working and we'll take a chance. A theoretical 
solution with no real-life implementation is not for us.

Have you impemented any engine for garbage collected languages using root_ptr? 
How well does root_ptr work with the Python engine? Or a Java VM? Lua? Ruby? 
Any scripting language VMs implemented using it?

> On the other hand it seems quite possible to upgrade or change the
> garbage collector in the Qt library and if we analyze the integration of
> root_ptr carefully then it should be done quickly.

Again, QtQml engine is really tied to JavaScript. I don't think you can get 
out of having a garbage collector at all.

> > No, it isn't. The JS order is the important order. If you do it outsiide
> > of
> > the order that the language requires, then it's just plain wrong.
> 
> What do you mean exactly by the JS order?  If you have a function:
> 
> function()
> {
>  var objA =
>  {
>  prop: "foo",
>  next: null
>  };
> 
>  var objB =
>  {
>  prop: "foo",
>  prev: null
>  };
> 
>  objA.next = objB;
>  objB.prev = objA;  // cycle
> }
> 
> Then the order of destruction of var objA and objB is undefined in
> Javascript whereas root_ptr guarantees that objB will get destroyed
> before objA.  But there is rule regarding the order of destruction in
> Javascript already so we can't break anything.

If the order of destruction according to the language is undefined, then the 
order in which root_ptr destroys it is not relevant and it can't be considered 
a plus. In fact, having it deterministic could be a negative asset, since 
someone writing this code will never be exposed to undefinedness of their code.

By the way, how does it break the cycle?

> Regarding root_ptr and Javascript then all we have to do is to define
> exactly where isolated entities are given birth and die.  In other words
> we just need to know where root_ptr will be put.  Do you agree that an
> HTML page and a QML window represent exactly this?  

I do not. See above.

> In the latter the
> only way a QML window can communicate with the outside world is by
> sending a signal (if you write directly in a parent window then that is
> bad programming and it shouldn't be allowed).
> 
> All that is required here is to analyze the situation carefully and
> we'll have a faster Javascript engine instead of just trying to patch
> the existing GC.  And the GC should be an abstraction we can replace and
> it shouldn't be part of the definition of Javascript.

No, all that is required is that someone actually write the code. Are you 
volunteering or do you have anyone who understands root_ptr that is?

-- 
Thiago Macieira - 

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/06/2017 11:10 AM, Thiago Macieira wrote:

On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote:


It's all memory usage and bad programming habits vs execution speed.
Why would you want to add objects that are never used?  A minimum
programming skills set is required here.  You're saying the actual
garbage collector should compensate for programming errors when I'm
saying that's the programmer's responsibility.


I'm saying that the garbage collector has to compensate for language
requirements. Do you even know JavaScript? Temporary variables are created all
the time in the process of any algorithm; global state variables could be
cleared depending on usage; etc.

The point is that the *language* requires us to have a garbage collector to
operate like that. So explain to me how root_ptr will work in that context.


As you know in Javascript temporary unnamed variables from a primitive 
type are no different than local variables and even if global variables 
are not encouraged then they will be destroyed when the HTML page or QML 
window is killed.


All root_ptr requires is to draw the line and isolate "entities" which 
have a birth and a certain death.  That is the case with HTML pages and 
QML windows and we can take advantage of that.


Anything that goes in that HTML page or QML window we don't care.  The 
reference counted property of root_ptr (node_ptr) will handle it and the 
associated root_ptr will clean up the mess when it is destroyed.



Or perhaps it should be a choice on whether the user wants to use the
garbage collector or root_ptr and he can decide by himself what is more
convenient for him according to his context.


Sure. A choice of different engines, completely different APIs. If the user
wants root_ptr, they can write their application using something other than
QtQml. Nothing is stopping them from it.


Well I'm here to help Qt because I know quite well that WebKit for 
Wayland is the number 1 rendering engine and Javascript processor.  The 
problem with WebKit is that their garbage collector is inlaid with the 
code of WebKit, making it impossible to throw away the garbage 
collector.  And WebKit is an engineering product which means they are 
not interested into innovative theoretical libraries that just came out 
of the oven.


On the other hand it seems quite possible to upgrade or change the 
garbage collector in the Qt library and if we analyze the integration of 
root_ptr carefully then it should be done quickly.



- The objects are destroyed is the exact reverse order they were
constructed thus this will help debugging.


But unnecessary, since the order they are constructed is irrelevant. The
JS
order matters.


It's a plus.


No, it isn't. The JS order is the important order. If you do it outsiide of
the order that the language requires, then it's just plain wrong.


What do you mean exactly by the JS order?  If you have a function:

function()
{
var objA =
{
prop: "foo",
next: null
};

var objB =
{
prop: "foo",
prev: null
};

objA.next = objB;
objB.prev = objA;  // cycle
}

Then the order of destruction of var objA and objB is undefined in 
Javascript whereas root_ptr guarantees that objB will get destroyed 
before objA.  But there is rule regarding the order of destruction in 
Javascript already so we can't break anything.



Please explain to me how root_ptr works for a garbage-collected language
interpreter. Particularly if you have any studies on a JS interpreter.


Javacript is not very complicated to understand for people who wrote 
interpreters.  I happen to write a parser for mathematical equations in 
my scientific calculator using my good old friendly mutable_ptr:

http://www.fornux.com

And it's the same for Javascript except that they have more advanced 
standards.


Regarding root_ptr and Javascript then all we have to do is to define 
exactly where isolated entities are given birth and die.  In other words 
we just need to know where root_ptr will be put.  Do you agree that an 
HTML page and a QML window represent exactly this?  In the latter the 
only way a QML window can communicate with the outside world is by 
sending a signal (if you write directly in a parent window then that is 
bad programming and it shouldn't be allowed).


All that is required here is to analyze the situation carefully and 
we'll have a faster Javascript engine instead of just trying to patch 
the existing GC.  And the GC should be an abstraction we can replace and 
it shouldn't be part of the definition of Javascript.



Thanks,
-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote:
> On 07/06/2017 01:01 AM, Thiago Macieira wrote:
> > On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote:
> >> - Well with root_ptr the behavior is 100% predictable thus you won't
> >> have these rendering lags at random times.
> > 
> > So explain to me how the QML engine should collect JS items that have gone
> > unused and unreferenced during the exection. Predictable execution isn't
> > good enough if it involves never garbage collecting and thus using a lot
> > more memory.
> 
> It's all memory usage and bad programming habits vs execution speed.
> Why would you want to add objects that are never used?  A minimum
> programming skills set is required here.  You're saying the actual
> garbage collector should compensate for programming errors when I'm
> saying that's the programmer's responsibility.

I'm saying that the garbage collector has to compensate for language 
requirements. Do you even know JavaScript? Temporary variables are created all 
the time in the process of any algorithm; global state variables could be 
cleared depending on usage; etc.

The point is that the *language* requires us to have a garbage collector to 
operate like that. So explain to me how root_ptr will work in that context.

> We want the fastest executable in the end given an extensible level of
> complexity of the executable.  If the garbage collector stops you from
> doing that then there's is no light at the end of the tunnel.

Agreed. People should stop using *languages* that require this type of garbage 
collector. But until that happens, we'll be forced to have GCs.

> Or perhaps it should be a choice on whether the user wants to use the
> garbage collector or root_ptr and he can decide by himself what is more
> convenient for him according to his context.

Sure. A choice of different engines, completely different APIs. If the user 
wants root_ptr, they can write their application using something other than 
QtQml. Nothing is stopping them from it.

> 
> >> - The objects are destroyed is the exact reverse order they were
> >> constructed thus this will help debugging.
> > 
> > But unnecessary, since the order they are constructed is irrelevant. The
> > JS
> > order matters.
> 
> It's a plus.

No, it isn't. The JS order is the important order. If you do it outsiide of 
the order that the language requires, then it's just plain wrong.

Please explain to me how root_ptr works for a garbage-collected language 
interpreter. Particularly if you have any studies on a JS interpreter.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/06/2017 01:01 AM, Thiago Macieira wrote:

On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote:

- Well with root_ptr the behavior is 100% predictable thus you won't
have these rendering lags at random times.


So explain to me how the QML engine should collect JS items that have gone
unused and unreferenced during the exection. Predictable execution isn't good
enough if it involves never garbage collecting and thus using a lot more
memory.


It's all memory usage and bad programming habits vs execution speed. 
Why would you want to add objects that are never used?  A minimum 
programming skills set is required here.  You're saying the actual 
garbage collector should compensate for programming errors when I'm 
saying that's the programmer's responsibility.


We want the fastest executable in the end given an extensible level of 
complexity of the executable.  If the garbage collector stops you from 
doing that then there's is no light at the end of the tunnel.


Or perhaps it should be a choice on whether the user wants to use the 
garbage collector or root_ptr and he can decide by himself what is more 
convenient for him according to his context.



- The objects are destroyed is the exact reverse order they were
constructed thus this will help debugging.


But unnecessary, since the order they are constructed is irrelevant. The JS
order matters.


It's a plus.


-Phil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote:
> - Well with root_ptr the behavior is 100% predictable thus you won't
> have these rendering lags at random times.

So explain to me how the QML engine should collect JS items that have gone 
unused and unreferenced during the exection. Predictable execution isn't good 
enough if it involves never garbage collecting and thus using a lot more 
memory.

> - The code of Qt will be much simpler.

We can make it even simpler by never free()ing or deleting. That doesn't mean 
it's correct.

> - You won't need a separate thread reserved for the garbage collector if
> that is already the case.

It's not.

> - The objects are destroyed is the exact reverse order they were
> constructed thus this will help debugging.

But unnecessary, since the order they are constructed is irrelevant. The JS 
order matters.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On quarta-feira, 5 de julho de 2017 15:31:28 PDT Phil Bouchard wrote:
> For example in HTML we could have 1 root_ptr for each HTML page and when
> this page is destroyed then the root_ptr guarantees all associated nodes
> will be destructed as well.  When I refer to a node I mean the
> representation of an atomic variable or a function in Javascript which
> is pointed to by a reference counted pointer.  So you can have all the
> mess you want in Javascript, when the page is destroyed then all memory
> associated to that page is freed.
> 
> It's the same thing with QML and its windows.  When a window is
> destroyed then all associated variables will vanish as well, cyclic or
> not.  From my experience, the only way a window can return a value is
> either by sending a signal with its parameters passed by value or by
> storing them in some local database.  But the parent shouldn't have any
> pointer connection of QML / Javascript type with its child window
> (downstream) otherwise it's bad programming.  Ex.:

What's the advantage compared to the current model where the GC runs 
periodically and frees unused objects before the window is closed?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Ed Leaver]

On 07/05/2017 06:31 PM, Phil Bouchard wrote:

On 07/05/2017 02:29 AM, Thiago Macieira wrote:

On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote:

Hi,

I read Qt 5.9 is using a new garbage collector that is more 
predictable.

  First good job and second I was wondering if there is any
documentation on that garbage collector in question.


That might be in the QML engine VM. The rest of Qt does not use garbage
collectors.


I guess if there is any interests to make the garbage collector
perfectly deterministic then root_ptr could be relatively easily
integrated at this stage.


How does root_ptr work with JavaScript semantics?


(So as you can see in the file attached I have revamped my Javascript 
skills.  And so with the QML.)


But first of all root_ptr is as you know a "set" of reference counted 
pointers, where the "set" vanished from existence when the destructor 
of the associated root_ptr is called.


For example in HTML we could have 1 root_ptr for each HTML page and 
when this page is destroyed then the root_ptr guarantees all 
associated nodes will be destructed as well.  When I refer to a node I 
mean the representation of an atomic variable or a function in 
Javascript which is pointed to by a reference counted pointer. So you 
can have all the mess you want in Javascript, when the page is 
destroyed then all memory associated to that page is freed.


It's the same thing with QML and its windows.  When a window is 
destroyed then all associated variables will vanish as well, cyclic or 
not.  From my experience, the only way a window can return a value is 
either by sending a signal with its parameters passed by value or by 
storing them in some local database.  But the parent shouldn't have 
any pointer connection of QML / Javascript type with its child window 
(downstream) otherwise it's bad programming.  Ex.:


   Window 1
   -
   |   |   Window 2
   |   | ---
   |  root_ptr2->| |
   |   | ---
root_ptr1->|   |
   |   |   Window 3
   |   | ---
   |  root_ptr3->| |
   |   | ---
   -

Here when root_ptr2 gets deleted from the list of Window 1's childs 
then everything inside Window 2 will get destroyed.  The same for 
root_ptr3 / Window 3.  If root_ptr1 gets destroyed then the whole app 
is guaranteed to vanish.



Regards,
-Phil
https://github.com/philippeb8/root_ptr

It may be just a matter of semantics. What you describe is pretty much 
how C++ QtWidgets work. One doesn't ordinarily think of convenient but 
informed use of smart pointers to be garbage collection. One doesn't 
ordinarily think of QtWidgets themselves as being particularly "smart" 
pointers, either. (But they've been enough to fool me!)


C++ QObjects do support "real" smart pointers in guise of 
QScopedPointer, QSharedPointer, and QWeakPointer, plus a few others. So 
Qt certainly knows how to do what you describe without Java-style 
garbage collection.


That's the C++ side, which I understand to underlie much of QML. I hope 
Thiago can correct my own mis-perceptions, and elaborate more.


Regards,
Ed Leaver


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

On 07/05/2017 02:29 AM, Thiago Macieira wrote:

On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote:

Hi,

I read Qt 5.9 is using a new garbage collector that is more predictable.
  First good job and second I was wondering if there is any
documentation on that garbage collector in question.


That might be in the QML engine VM. The rest of Qt does not use garbage
collectors.


I guess if there is any interests to make the garbage collector
perfectly deterministic then root_ptr could be relatively easily
integrated at this stage.


How does root_ptr work with JavaScript semantics?


(So as you can see in the file attached I have revamped my Javascript 
skills.  And so with the QML.)


But first of all root_ptr is as you know a "set" of reference counted 
pointers, where the "set" vanished from existence when the destructor of 
the associated root_ptr is called.


For example in HTML we could have 1 root_ptr for each HTML page and when 
this page is destroyed then the root_ptr guarantees all associated nodes 
will be destructed as well.  When I refer to a node I mean the 
representation of an atomic variable or a function in Javascript which 
is pointed to by a reference counted pointer.  So you can have all the 
mess you want in Javascript, when the page is destroyed then all memory 
associated to that page is freed.


It's the same thing with QML and its windows.  When a window is 
destroyed then all associated variables will vanish as well, cyclic or 
not.  From my experience, the only way a window can return a value is 
either by sending a signal with its parameters passed by value or by 
storing them in some local database.  But the parent shouldn't have any 
pointer connection of QML / Javascript type with its child window 
(downstream) otherwise it's bad programming.  Ex.:


   Window 1
   -
   |   |   Window 2
   |   | ---
   |  root_ptr2->| |
   |   | ---
root_ptr1->|   |
   |   |   Window 3
   |   | ---
   |  root_ptr3->| |
   |   | ---
   -

Here when root_ptr2 gets deleted from the list of Window 1's childs then 
everything inside Window 2 will get destroyed.  The same for root_ptr3 / 
Window 3.  If root_ptr1 gets destroyed then the whole app is guaranteed 
to vanish.



Regards,
-Phil
https://github.com/philippeb8/root_ptr
<>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Thiago Macieira]

On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote:
> Hi,
> 
> I read Qt 5.9 is using a new garbage collector that is more predictable.
>   First good job and second I was wondering if there is any
> documentation on that garbage collector in question.

That might be in the QML engine VM. The rest of Qt does not use garbage 
collectors.

> I guess if there is any interests to make the garbage collector
> perfectly deterministic then root_ptr could be relatively easily
> integrated at this stage.

How does root_ptr work with JavaScript semantics?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 beta4 available

[Oleg Yadrov]

There is also another regression QTBUG-59704 which is still unsolved.

--
Oleg Yadrov
oleg.yad...@qt.io

> On May 16, 2017, at 1:14 PM, Robin Burchell  wrote:
> 
> Thanks for the report. I'll take a look at finishing this tonight.
> 
> -- 
>  Robin Burchell
>  ro...@crimson.no
> 
> On Tue, May 16, 2017, at 06:43 PM, Тимур Артиков wrote:
>> Hi,
>> I believe, QTBUG-60547 should be fixed before the release.
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 beta4 available

[Robin Burchell]

Thanks for the report. I'll take a look at finishing this tonight.

-- 
  Robin Burchell
  ro...@crimson.no

On Tue, May 16, 2017, at 06:43 PM, Тимур Артиков wrote:
> Hi,
> I believe, QTBUG-60547 should be fixed before the release.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 beta4 available

[Тимур Артиков]

Hi,
I believe, QTBUG-60547 should be fixed before the release.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 beta2 available

[Eike Ziller]

> On Apr 24, 2017, at 13:45, Martin Koller  wrote:
> 
> On Freitag, 21. April 2017 09:08:00 CEST Jani Heikkinen wrote:
>> Hi all,
>> 
>> Qt 5.9 beta2 is now available. Instructions how to get the release are here: 
>> https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first 
>> beta can be found as an attachment.
>> 
>> Please test the release and report your effort via 
>> https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each 
>> platform in the table to get full coverage & good understanding where we are.
> 
> It seems qttools/src/assistant is missing clucene in the packages.
> Is there a reason for it (intentional) or was that forgotten ?

Assistant no longer uses clucene.
e.g. https://codereview.qt-project.org/186659

Br, Eike

> 
> -- 
> Best regards/Schöne Grüße
> 
> Martin
> 
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
> 
> There is no cloud, just other people’s computers.
> 
> This mail was not scanned before sending.
> It was sent from a secure Linux desktop.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 beta2 available

[Martin Koller]

On Freitag, 21. April 2017 09:08:00 CEST Jani Heikkinen wrote:
> Hi all,
> 
> Qt 5.9 beta2 is now available. Instructions how to get the release are here: 
> https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first 
> beta can be found as an attachment.
> 
> Please test the release and report your effort via 
> https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each 
> platform in the table to get full coverage & good understanding where we are.

It seems qttools/src/assistant is missing clucene in the packages.
Is there a reason for it (intentional) or was that forgotten ?

-- 
Best regards/Schöne Grüße

Martin

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

There is no cloud, just other people’s computers.

This mail was not scanned before sending.
It was sent from a secure Linux desktop.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Edward Welbourne]

Lars Knoll (21 April 2017 10:10)
> Let us know once the updated diffs are available. No point doing the review 
> on the old diffs.

Done :-)

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Lars Knoll]

> On 21 Apr 2017, at 10:08, Edward Welbourne  wrote:
> 
> Lars Knoll (20 April 2017 12:19)
>> Some of the diffs don’t look like they are 100% up to date. Eddy?
> 
> Indeed, I've just been updating them on request.
> I do plan on a bulk update today.

Thanks! Let us know once the updated diffs are available. No point doing the 
review on the old diffs.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Edward Welbourne]

Lars Knoll (20 April 2017 12:19)
> Some of the diffs don’t look like they are 100% up to date. Eddy?

Indeed, I've just been updating them on request.
I do plan on a bulk update today.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Lars Knoll]

Some of the diffs don’t look like they are 100% up to date. Eddy?

Lars

> On 20 Apr 2017, at 11:43, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> It is time to do official Header diff for Qt 5.9 APIs (compared to Qt 5.8.0)
> 
> From here you can find the diffs: 
> https://codereview.qt-project.org/#/q/branch:5.9+topic:%22API+Review%22,n,z 
> (thanks to Eddy!)
> 
> Please do the review now if not done yet. We should get '+2' for each 
> submodule as soon as possible, hoping already during next week but latest 
> before Qt 5.9.0 RC
> 
> br,
> Jani
> 
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ?

[Thiago Marcos P. Santos]

> But what desktop platform (if any) is most stable right now for mapboxgl?


We tested it on OSX, Linux (Ubuntu, but CI bot is passing on RHL and
Yocto too), iOS and Android.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 API review

[Edward Welbourne]

Jani Heikkinen (28 February 2017 11:09):

> It seems Qt 5.9 API review is still badly ongoing, see
[snip]

FTR, we have some on-going fixes in progress in qtbase.

> Please finalize the reviews & do needed fixes as soon as possible so that we 
> will be ready for beta early enough.

If your module has had updates to fix any API issues found by the review
so far, please do let me know (no need to Cc the list) and I'll update
its API review,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 API review

[Sean Harmer]

On Tuesday 28 February 2017 10:09:13 Jani Heikkinen wrote:
> Hi all,
> 
> It seems Qt 5.9 API review is still badly ongoing, see

> https://codereview.qt-project.org/184392qt3d

We went through this last week and resulted in:

https://bugreports.qt.io/secure/RapidBoard.jspa?rapidView=48

We're now working through those as best we can. We may need another pass on 
the animation stuff but that's a tech preview for 5.9 so not absolutely 
critical.

Cheers,

Sean

> Please finalize the reviews & do needed fixes as soon as possible so that we
> will be ready for beta early enough.
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ?

[Alexander Ivash]

>> but we are unsure if we'll be able to ship the mapboxgl plugin for windows 
>> with 5.9
Thank you for reply Paolo, will keep fingers crossed then.

But what desktop platform (if any) is most stable right now for mapboxgl?

Regards, Alexander

2017-02-27 23:11 GMT+03:00 Paolo Angelelli :
> Hi Alexander,
>
> we are trying, but we are unsure if we'll be able to ship the mapboxgl plugin 
> for windows with 5.9.
> In any case, i believe that, if not, mapbox might make it available outside 
> the qt sdk as an additional plugin.
>
> regards
> 
> From: Development [development-bounces+paolo.angelelli=qt...@qt-project.org] 
> on behalf of Alexander Ivash [elder...@gmail.com]
> Sent: Monday, February 27, 2017 6:44 PM
> To: development@qt-project.org
> Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ?
>
> Is it planned to enable mapbox-gl-native building for windows? If yes,
> then when?
>
> Alexander
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ?

[Paolo Angelelli]

Hi Alexander,

we are trying, but we are unsure if we'll be able to ship the mapboxgl plugin 
for windows with 5.9.
In any case, i believe that, if not, mapbox might make it available outside the 
qt sdk as an additional plugin.

regards

From: Development [development-bounces+paolo.angelelli=qt...@qt-project.org] on 
behalf of Alexander Ivash [elder...@gmail.com]
Sent: Monday, February 27, 2017 6:44 PM
To: development@qt-project.org
Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ?

Is it planned to enable mapbox-gl-native building for windows? If yes,
then when?

Alexander
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 feature freeze

[Thiago Macieira]

Em terça-feira, 24 de janeiro de 2017, às 08:29:42 PST, mark diener escreveu:
> Jani:
> 
> Qt shipped 5.8.0. Qt Lite shipped. Nice Job.
> 
> Maybe Qt should actually define "Feature Freeze" as the following:
> 
> Qt will now FREEZE new development and task dev staff 100% for 2
> months to clean out all the bugs that are P2 important and up
> and get caught up on bug fixing.

We can't tell people not to work on something. But they can't push new 
development to the 5.9 branch. From the FF onwards, all changes to the 5.9 
branch are related to stabilisation and bugfixing.

New features can go to dev, which will be 5.10.

> At the end of 2 months, we will release 5.8.1 and then begin new
> development on 5.9 based on the bug fixed 5.8 branch.

Ah, no. That's extremely unlikely.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 feature freeze

[mark diener]

Jani:

Qt shipped 5.8.0. Qt Lite shipped. Nice Job.

Maybe Qt should actually define "Feature Freeze" as the following:

Qt will now FREEZE new development and task dev staff 100% for 2
months to clean out all the bugs that are P2 important and up
and get caught up on bug fixing.

At the end of 2 months, we will release 5.8.1 and then begin new
development on 5.9 based on the bug fixed 5.8 branch.

https://bugreports.qt.io/browse/QTBUG-46298

Version 5.2.1?  Really?

Why even report bugs if they are not going to get fixed for YEARS.

There there is this glaring FONT omission:

https://bugreports.qt.io/browse/QTBUG-58002

How did this make it past any sort of QA?

A coherent Qt reply appreciated:

md

















On Tue, Jan 24, 2017 at 4:27 AM, Jani Heikkinen  wrote:
> Hi all,
>
> Only one week left. And we should start soft branching from 'dev' to '5.9' 
> already tomorrow & finalize it 1.2.2017 to be able to have the FF as planned.
> Please update new features page as soon as possible; 
> https://wiki.qt.io/New_Features_in_Qt_5.9 is quite empty still...
>
> br,
> Jani
>
> 
> From: Jani Heikkinen
> Sent: Monday, January 16, 2017 1:26 PM
> To: development@qt-project.org
> Subject: Re: Qt 5.9 feature freeze
>
> Kindly reminder: there is a bit more than two weeks left before FF is in 
> effect. So please finalize new features now.
> Is there new submolules coming in for 5.9? If there is those should be added 
> in qt5.git now...
>
> br,
> Jani
>
> 
> From: Jani Heikkinen
> Sent: Monday, January 2, 2017 12:26 PM
> To: development@qt-project.org
> Subject: Qt 5.9 feature freeze
>
> Hi all,
>
> Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to 
> finalize all new features for Qt 5.9
>
> Let's this time make sure we will keep the schedule (see 
> https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight 
> with ff. So if you already now see that some feature won't be ready early 
> enough please postpone it to 5.10 instead.
>
> Make sure all new features are visible in new feature page 
> (https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria 
> (https://wiki.qt.io/Qt_5_Feature_Freeze)
>
> br,
> Jani Heikkinen
> Release Manager
>
>
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 feature freeze

[Jani Heikkinen]

Hi all,

Only one week left. And we should start soft branching from 'dev' to '5.9' 
already tomorrow & finalize it 1.2.2017 to be able to have the FF as planned. 
Please update new features page as soon as possible; 
https://wiki.qt.io/New_Features_in_Qt_5.9 is quite empty still...

br,
Jani


From: Jani Heikkinen
Sent: Monday, January 16, 2017 1:26 PM
To: development@qt-project.org
Subject: Re: Qt 5.9 feature freeze

Kindly reminder: there is a bit more than two weeks left before FF is in 
effect. So please finalize new features now.
Is there new submolules coming in for 5.9? If there is those should be added in 
qt5.git now...

br,
Jani


From: Jani Heikkinen
Sent: Monday, January 2, 2017 12:26 PM
To: development@qt-project.org
Subject: Qt 5.9 feature freeze

Hi all,

Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to 
finalize all new features for Qt 5.9

Let's this time make sure we will keep the schedule (see 
https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight 
with ff. So if you already now see that some feature won't be ready early 
enough please postpone it to 5.10 instead.

Make sure all new features are visible in new feature page 
(https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria 
(https://wiki.qt.io/Qt_5_Feature_Freeze)

br,
Jani Heikkinen
Release Manager






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 feature freeze

[Jani Heikkinen]

Kindly reminder: there is a bit more than two weeks left before FF is in 
effect. So please finalize new features now. 
Is there new submolules coming in for 5.9? If there is those should be added in 
qt5.git now...

br,
Jani


From: Jani Heikkinen
Sent: Monday, January 2, 2017 12:26 PM
To: development@qt-project.org
Subject: Qt 5.9 feature freeze

Hi all,

Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to 
finalize all new features for Qt 5.9

Let's this time make sure we will keep the schedule (see 
https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight 
with ff. So if you already now see that some feature won't be ready early 
enough please postpone it to 5.10 instead.

Make sure all new features are visible in new feature page 
(https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria 
(https://wiki.qt.io/Qt_5_Feature_Freeze)

br,
Jani Heikkinen
Release Manager






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development