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
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 /
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.
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
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
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
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
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
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.
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
>> 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
___
> 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
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
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
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
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
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
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
>>
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
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
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
>
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,
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
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
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
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
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
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
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
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
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
>>>
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
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
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
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++
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
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
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
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):
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:
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
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
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
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 )
>> {
>>
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 = {}
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
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
...@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
e attempt of calling it.
Simon
From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> on
behalf of Phil Bouchard <philipp...@gmail.com>
Sent: Tuesday, July 11, 2017 1:49:05 PM
To: development@qt-project.org
Subject: Re: [Development
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
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
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
> 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
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
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
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
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
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
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
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()
>
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...
> - 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
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
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
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
> 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
>
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.
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
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
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
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
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
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.
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
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
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
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
>
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
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.
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.
80 matches
Mail list logo