Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr
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
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
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
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
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
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
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
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
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
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
>> 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
On 07/15/2017 01:34 PM, Tim Blechmann wrote: Oh sorry they did invent Minesweeper and Basic, I give them that... https://en.wikipedia.org/wiki/Dartmouth_BASIC Lol. 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. ___ 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. 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. 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. 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. -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
On 07/12/2017 07:25 PM, Phil Bouchard wrote: And the executable generated by g++ is still 1.7 times faster than by using Node.JS. Make that 1.8 times faster when using a main precompiled header. ___ 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
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. There's also a tool to precompile a QML file. You should compare to that. -- 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
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
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
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
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 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 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
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
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
[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
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
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
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
Simon Hausmann 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 > on behalf of Phil > Bouchard > > 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 > 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 > > > color="#00" style="font-size:11pt">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: > 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
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 on behalf of Phil Bouchard 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
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
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
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
> 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
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
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
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 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
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
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. -- 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
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
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 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
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 -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
On 07/09/2017 05:40 PM, Thiago Macieira wrote: 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? I updated javascript_example1.cpp so the aforementioned output is out of sync with the source file. I should have copied and pasted the source. Please see the last thread [root_ptr]... for today's updates regarding it. 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). 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. But thanks again, I really appreciate. 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
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
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
> - 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
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. -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
On 07/07/2017 09:55 PM, Thiago Macieira wrote: On sexta-feira, 7 de julho de 2017 18:25:19 PDT Phil Bouchard wrote: JavaScript has no such thing as l or rvalues. Please define use proper terms for the language in question. I get your point but those are just shortcuts to the following definitions: l-value: write variable r-value: read-only variable I don't see a problem with variables being modified. But I do see a problem if a parameter is copied to a global variable. Requiring a deep copy is wasteful when the current code requires no such thing. So now you have to prove that htis extra waste is offset by the benefits of using root_ptr elsewhere. function foo(source) { var image = new Image(); image.height = 100; image.title = file.name; image.src = source; // parameter used as an r-value will remain unaffected return image; // return value will require 'image' to be a deep copy }, So if this Image object opened a 4K image @ 3840x2160 (= just under 32 MB), you're suggesting that all 32 MB be copied? For this proposal, yes. 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. ___ 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
On sexta-feira, 7 de julho de 2017 18:25:19 PDT Phil Bouchard wrote: > So if for each function there is 1 root_ptr pointing to a list of local > variables then: > - 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 > - closures of the function will remain unaffected if they are used as > r-values > - closures of the function will require a deep copy of the expression if > they are used as l-values > - return values will be deep copies. JavaScript has no such thing as l or rvalues. Please define use proper terms for the language in question. I don't see a problem with variables being modified. But I do see a problem if a parameter is copied to a global variable. Requiring a deep copy is wasteful when the current code requires no such thing. So now you have to prove that htis extra waste is offset by the benefits of using root_ptr elsewhere. > function foo(source) > { > var image = new Image(); > image.height = 100; > image.title = file.name; > image.src = source; // parameter used as an r-value will remain > unaffected > return image; // return value will require 'image' to be a deep copy > }, So if this Image object opened a 4K image @ 3840x2160 (= just under 32 MB), you're suggesting that all 32 MB be copied? -- 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
On 07/07/2017 12:44 PM, Phil Bouchard wrote: Thiago Macieira wrote: You're speaking in abstract terms. We actually need code. Ok I can reuse my Fornux Calculator parser and mimic a function call in Javascript. Actually I can predict what is going to happen if I was to integrate the actual root_ptr with the ability to unify sets implicitly, removed. So if for each function there is 1 root_ptr pointing to a list of local variables then: - 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 - closures of the function will remain unaffected if they are used as r-values - closures of the function will require a deep copy of the expression if they are used as l-values - return values will be deep copies. Example 1) function foo(source) { var image = new Image(); image.height = 100; image.title = file.name; image.src = source; // parameter used as an r-value will remain unaffected return image; // return value will require 'image' to be a deep copy }, Example 2) function previewFiles() { var preview = document.querySelector('#preview'); var files = document.querySelector('input[type=file]').files; function readAndPreview(file) { var reader1 = new FileReader(); reader1.addEventListener ( "load", function () { var image = new Image(); image.height = 100; image.title = file.name; image.src = this.result; preview.appendChild(image); // closure used as an l-value will require its parameter 'image' to be a deep copy }, false ); reader1.readAsDataURL(file); } if (files) { [].forEach.call(files, readAndPreview); } } In these examples I am using an image because that is a worse case scenario but 99% of the time parameters and closures will be simple integers and strings. This way there can be no cyclic reference left alone. See? We're getting somewhere. Thank you all for your input BTW; it helped me came to the aforementioned conclusion. 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 wrote: > 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. > Ok I can reuse my Fornux Calculator parser and mimic a function call in Javascript. ___ 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
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
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 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
> 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
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
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
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
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
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&A 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
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 - thiago.maci
Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr
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
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
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
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
On 07/05/2017 08:25 PM, Thiago Macieira wrote: 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? - Well with root_ptr the behavior is 100% predictable thus you won't have these rendering lags at random times. It happened to me before when I had relatively complex listitems using shadows and a nested list of pictures for each item; the scrolling speed wasn't constant and I think that's a good way to measure this problem. With root_ptr the complexity will remain linear O(n). - The code of Qt will be much simpler. - You won't need a separate thread reserved for the garbage collector if that is already the case. - The objects are destroyed is the exact reverse order they were constructed thus this will help debugging. -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
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
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
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
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
[Development] Qt 5.9's new garbage collector documentation? + root_ptr
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. 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. Regards, -Phil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.9 RC2 released
Hi all, Qt 5.9 RC2 is available. It is Qt 5.9 RC + https://codereview.qt-project.org/#/c/195341/ At this time RC2 is available via online installers only, instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. And because there is only one change after official RC we should be able to release final Qt 5.9.0 this Wed (31.5.2017) as planned. 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 beta4 available
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