Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/27/2018 12:22 PM, Phil Bouchard wrote:


Also I did my fair amount of contributions to science with:
- the root_ptr memory manager
- the astrophysics theory currently being peer-reviewed by the “Monthly
Notices of the Royal Astronomical Society”


Correction:
- the astrophysics theory is now peer-reviewed by the "International 
Conference of Theoretical Physics" (in NY this August) and it was 
accepted for publication in their proceeding.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 05/14/2018 06:22 AM, Konstantin Tokarev wrote:



14.05.2018, 01:45, "Phil Bouchard" :

On 05/13/2018 06:35 PM, Alexander Nassian wrote:

  OMFG, besides that these are not the most difficult problems in programming, 
... that computer voice that just reads what the presentation says. Youtube 
Videos are not the messias, if it’s just a written down text, publish it as 
text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve 
slow it down you would at least get money from ads :D


Some people are auditory while other are visual. And a synthesized voice
because I skip the squelch detection process of the background noice
coming from a human recorded voice.


You just need to buy a good mic and a good sound card to get rid of noise.

You can also suppress noise by applying filter, any recording software can do 
that.


I do have a professional microphone but I still need to use some 
filtering software.


Here is the proof I have tried it in the past and Tamara's voice was 
distorted:

https://youtu.be/0aBrmRS1TRQ

(BTW you can also see I am the first one who came up with the: "Make 
America Great Again" slogan -- 2:58)


But thanks for your advice, I will do what you suggest in the future.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Konstantin Tokarev]

14.05.2018, 01:45, "Phil Bouchard" :
> On 05/13/2018 06:35 PM, Alexander Nassian wrote:
>>  OMFG, besides that these are not the most difficult problems in 
>> programming, ... that computer voice that just reads what the presentation 
>> says. Youtube Videos are not the messias, if it’s just a written down text, 
>> publish it as text. Why a voice that reads 1:1 what is visible on the 
>> screen? If you would‘ve slow it down you would at least get money from ads :D
>
> Some people are auditory while other are visual. And a synthesized voice
> because I skip the squelch detection process of the background noice
> coming from a human recorded voice.

You just need to buy a good mic and a good sound card to get rid of noise.

You can also suppress noise by applying filter, any recording software can do 
that.

-- 
Regards,
Konstantin

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 05/13/2018 06:35 PM, Alexander Nassian wrote:

OMFG, besides that these are not the most difficult problems in programming, 
... that computer voice that just reads what the presentation says. Youtube 
Videos are not the messias, if it’s just a written down text, publish it as 
text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve 
slow it down you would at least get money from ads :D


Some people are auditory while other are visual. And a synthesized voice 
because I skip the squelch detection process of the background noice 
coming from a human recorded voice.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Alexander Nassian]

OMFG, besides that these are not the most difficult problems in programming, 
... that computer voice that just reads what the presentation says. Youtube 
Videos are not the messias, if it’s just a written down text, publish it as 
text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve 
slow it down you would at least get money from ads :D

> Am 13.05.2018 um 23:26 schrieb Phil Bouchard :
> 
>> On 04/26/2018 12:35 AM, Phil Bouchard wrote:
>> On 04/25/2018 12:36 PM, Edward Welbourne wrote:
 memory leaks are the most difficult problems to solve.
>>> 
>>> Well, no, they're not.
>>> I've fixed *lots and lots* of memory leaks.
>>> Some of them were a little tricky: most were trivial.
>>> I can *see* memory leaks just by reading code.
>>> It's one of the reasons code review makes memory leaks rare.
>>> That and nice sensible disciplines like RAII.
>>> 
>>> Use-after-free is usually harder to solve than a leak.
>>> Deadlocks are almost always harder to solve.
>> You're right:
>> 1) Deadlocks are much more difficult to find
>> 2) Then comes the use-after-free but they can be easily detected by throwing 
>> an exception with root_ptr
>> 3) Then we have the memory leaks...
> 
> I made a mistake here: use-after-free problems are actually easily solved by 
> FCXXSS because it discards all explicit calls to "delete" and implicitly use 
> them where they belong. So it's impossible to face that problem.
> 
> In fact I have prepared a summary of our discussion and you can see the 
> execution of my previous example in real-time here:
> https://youtu.be/vZL5X2FlZKU
> 
> 
> Regards,
> -Phil
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 













—


bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach

Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747

Geschäftsführer: Alexander Nassian, Markus Pfaffinger



http://www.bitshift-dynamics.de 


Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90


Allgemeine Anfragen: 
i...@bitshift-dynamics.com 
Technischer 
Support: supp...@bitshift-dynamics.com 

Buchhaltung: 
invo...@bitshift-dynamics.com 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/26/2018 12:35 AM, Phil Bouchard wrote:

On 04/25/2018 12:36 PM, Edward Welbourne wrote:

memory leaks are the most difficult problems to solve.


Well, no, they're not.
I've fixed *lots and lots* of memory leaks.
Some of them were a little tricky: most were trivial.
I can *see* memory leaks just by reading code.
It's one of the reasons code review makes memory leaks rare.
That and nice sensible disciplines like RAII.

Use-after-free is usually harder to solve than a leak.
Deadlocks are almost always harder to solve.


You're right:
1) Deadlocks are much more difficult to find
2) Then comes the use-after-free but they can be easily detected by 
throwing an exception with root_ptr

3) Then we have the memory leaks...


I made a mistake here: use-after-free problems are actually easily 
solved by FCXXSS because it discards all explicit calls to "delete" and 
implicitly use them where they belong. So it's impossible to face that 
problem.


In fact I have prepared a summary of our discussion and you can see the 
execution of my previous example in real-time here:

https://youtu.be/vZL5X2FlZKU


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Thiago Macieira  wrote:
> On Wednesday, 2 May 2018 13:45:46 PDT Phil Bouchard wrote:
>> So what do you think Qt? Are you:
>> 
>> 1) Not interested or whatsoever
>> 2) Interested to give a trial version a shot
>> 3) You get the idea already and might consider it
> 
> Probably (1).

Ok well live long and prosper!


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Thiago Macieira]

On Wednesday, 2 May 2018 13:45:46 PDT Phil Bouchard wrote:
> So what do you think Qt? Are you:
> 
> 1) Not interested or whatsoever
> 2) Interested to give a trial version a shot
> 3) You get the idea already and might consider it

Probably (1).

-- 
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] Fornux C++ Superset

[Phil Bouchard]

Phil Bouchard  wrote:

On the other hand I am more targeting QML because QWidgets are fine already
so I assume:
- QML compiler converts QML into C++
- Fornux C++ Superset could then inject its memory manager
- Compile the resulting code

It’s just a matter of making sure QML doesn’t use nested structures.

So what do you think Qt? Are you:

1) Not interested or whatsoever
2) Interested to give a trial version a shot
3) You get the idea already and might consider it


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 05/01/2018 09:27 AM, Phil Bouchard wrote:

Michael Corcoran  wrote:

It's not really a "superset" if it doesn't support all of the features of
the original language, much less core features such as nested structs...
You may like to revisit that naming choice.


I agree but I will first see what I can do with the C++ ISO standards.


I already submitted the request:
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/M0G7AhsggmE


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Michael Corcoran  wrote:
> On 05/01/2018 11:18 AM, Phil Bouchard wrote:
>> I just tried to support nested structures and given nested structures
>> and template specializations aren't commutative then it's not possible
>> to support them if you want to respect the access scope at the same
>> time. If you give up the nested declaration and therefore the access
>> scope privileges then it'll be fine. Ex:
> ...
>> The day the C++ language will support nested forward declarations
>> correctly then it'll be possible but not for now.
> ...
>> Regards,
>> -Phil
> 
> It's not really a "superset" if it doesn't support all of the features of
> the original language, much less core features such as nested structs...
> You may like to revisit that naming choice.

I agree but I will first see what I can do with the C++ ISO standards. On
the other hand I am more targeting QML because QWidgets are fine already so
I assume:
- QML compiler converts QML into C++
- Fornux C++ Superset could then inject its memory manager
- Compile the resulting code

It’s just a matter of making sure QML doesn’t use nested structures.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Michael Corcoran]

On 05/01/2018 11:18 AM, Phil Bouchard wrote:
> I just tried to support nested structures and given nested structures
> and template specializations aren't commutative then it's not possible
> to support them if you want to respect the access scope at the same
> time. If you give up the nested declaration and therefore the access
> scope privileges then it'll be fine. Ex:
...
> The day the C++ language will support nested forward declarations
> correctly then it'll be possible but not for now.
...
> Regards,
> -Phil

It's not really a "superset" if it doesn't support all of the features of the 
original language, much less core features such as nested structs... You may 
like to revisit that naming choice.

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/25/2018 08:02 AM, Phil Bouchard wrote:
Support for nested structures is easy to fix and will just take a day or 
two to do so. For example:


struct A
{
   struct B
   {
   };
};

Will be converted into the following so that I can have their 
specialization in a top-level namespace:


struct A__B
{
};

struct A
{
};

Since there is no hidden catch then I will tell you right now that:
- NULL C pointers will need to be typed
- pointer casts to their encompassing structure needs to use 
_containerof() macro

- C-style array parameters needs to be converted to pointers
- Types instantiated in the same statement need not be different (Ex.: 
int * i, j[4]; // needs to be 2 different statements)


That's about it. It took me 1 week to adapt "libarchive" to follow the 
aforementioned rules:
https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b 


I just tried to support nested structures and given nested structures 
and template specializations aren't commutative then it's not possible 
to support them if you want to respect the access scope at the same 
time. If you give up the nested declaration and therefore the access 
scope privileges then it'll be fine. Ex:


struct A
{
static int i;

struct B
{
} b; // can access i
};

// Would be converted to:

struct A__B
{
};

struct A
{
static int i;

A__B b; // cannot access i
};

The day the C++ language will support nested forward declarations 
correctly then it'll be possible but not for now. Ex.:


struct A::B::C;

Honestly it took me 1 week to patch libarchive and Fornux C++ Superset 
was able to fix the leaks they were living with for the last 3 years.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/25/2018 11:35 PM, Phil Bouchard wrote:

template
void foo(int (&array)[N]) ?


Since I just started testing C++98 as of last week, I haven't yet had a 
chance to test templates thoroughly. So this one is buggy and I'll have 
to fix it.


I already fixed the problem. The following code:

template 
void foo(T (&array)[S])
{
cout << __PRETTY_FUNCTION__ << endl;
}

int main()
{
int array[10];

foo(array);

return 0;
}

Now correctly outputs:
void foo(const boost::node_proxy &, boost::root_array, 
10> (&))



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Edward Welbourne  wrote:
> Phil Bouchard (27 April 2018 15:36)
>> - It’s always better to patent important algorithms
> 
> Those of us who believe in the freedom of ideas disagree.  It is better
> to publish important algorithms, so that no-one else can patent them.

Good point but I personally believe a balance between capitalism and
socialism is the best approach because it’s a case by case situation. For
example the military don’t want their code to be outsourced and competition
in general speeds up development but “has been” word processors can
definitely be outsourced.

Also I did my fair amount of contributions to science with:
- the root_ptr memory manager
- the astrophysics theory currently being peer-reviewed by the “Monthly
Notices of the Royal Astronomical Society”

So having a commercial parser is natural. The Clang team encourages it.

>> - But outside North-America and Europe, companies do not care about
>> copyrights and patents
> 
> Even in Europe and North America, companies will get away with what they
> can.  However, if they're copying your code in a reverse-engineerable
> language, reverse-engineering of their code will reveal the copying.

We don’t live in a perfect world and therefore all we can do is minimize
the chances we get plagiarized, specially by some random hacker.

>> - That’s why there are tools to protect your software from being reverse
>> engineered such as:
>> https://www.intertrust.com/products/application-shielding/
> 
> I confess I have not looked at it.  I am profoundly sceptical of its
> ability to be more than a speed-bump to the genuinely committed reverse
> engineer, just like DRM on music and movies.  Copy-protection is pretty
> much always futile, if you're putting a copy into the hands of the user,
> no matter how much you obfuscate it.
> 
>> I would then suggest GC languages should be optional and not mandatory. At
>> the present time, QML forces us to use JS.
> 
> I believe it is entirely possible to write purely declarative QML, which
> makes no use of JS.  By judicious use of C++ classes below the bonnet,
> you can get all the complexity of behaviour that JS would bring.
> However, you'll almost certainly get to this state faster by first
> prototyping in JS and then coding C++ classes to make the JS that leaves
> you with redundant.

Good to know.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Edward Welbourne]

Phil Bouchard (27 April 2018 15:36)
> - It’s always better to patent important algorithms

Those of us who believe in the freedom of ideas disagree.  It is better
to publish important algorithms, so that no-one else can patent them.

> - But outside North-America and Europe, companies do not care about
> copyrights and patents

Even in Europe and North America, companies will get away with what they
can.  However, if they're copying your code in a reverse-engineerable
language, reverse-engineering of their code will reveal the copying.

> - That’s why there are tools to protect your software from being reverse
> engineered such as:
> https://www.intertrust.com/products/application-shielding/

I confess I have not looked at it.  I am profoundly sceptical of its
ability to be more than a speed-bump to the genuinely committed reverse
engineer, just like DRM on music and movies.  Copy-protection is pretty
much always futile, if you're putting a copy into the hands of the user,
no matter how much you obfuscate it.

> I would then suggest GC languages should be optional and not mandatory. At
> the present time, QML forces us to use JS.

I believe it is entirely possible to write purely declarative QML, which
makes no use of JS.  By judicious use of C++ classes below the bonnet,
you can get all the complexity of behaviour that JS would bring.
However, you'll almost certainly get to this state faster by first
prototyping in JS and then coding C++ classes to make the JS that leaves
you with redundant.

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Edward Welbourne  wrote:
> Phil Bouchard  wrote:
 - Fornux C++ Superset
> 
> On 04/27/2018 04:18 AM, Edward Welbourne wrote:
>>> Nothing as yet persuades me that we need this one.  Of course, once your
>>> compiler can handle Qt's C++ code, you'll be at liberty to combine the
>>> first three above with whatever you like, including your favourite AI
>>> engine.
> 
> Phil Bouchard (27 April 2018 14:20)
>> I'm just trying to help speeding up development here.
> 
> It remains that you have failed to persuade folk on this list that
> Fornux would in fact speed up development.

That’s because:
- I am putting the cart before the horse and I haven’t provided a trial
version yet
- The projects need to be reasonably complex to notice a divergence in
development speed

 I think that’s much better than wasting your time supporting Python or
 Javascript that can be easily reverse engineered because of their
 interpreted nature.
>>> 
>>> Your obsession with not being easy to reverse engineer suggests you
>>> don't really understand the nature of Free Software; our source code is
>>> publicly available, so who would need to reverse-engineer it ?
>>> We gladly share it and save them the bother,
> 
>> I'm referring to Qt's customers who wants to release commercial apps;
>> they won't like to know part of their code can be deciphered.
> 
> Well, first: copyright protects their work.  The fact that someone else
> can decipher it is incidental - even if they publish their source code,
> no-one else can *use* that without their permission.  Beyond that, as
> long as the code runs on users' computers, some form or another of the
> code is out there and the folk who are any good at reverse engineering
> are going to discover its secrets, if they care to do so.  Trying to
> keep your implementation secret is consequently mostly pointless.

- It’s always better to patent important algorithms
- But outside North-America and Europe, companies do not care about
copyrights and patents
- That’s why there are tools to protect your software from being reverse
engineered such as:
https://www.intertrust.com/products/application-shielding/

>> Performance does play a role as well; you don't want to bottleneck the
>> app with any garbage collector at all.
> 
> Garbage collectors have their advantages and their costs; the principal
> advantage is that developing in a garbage-collected language is
> significantly easier (you have fewer irrelevancies to pay attention to),
> which means a broader pool of authors can contribute - notably, those
> who are good at UX/UI design aren't always also good at the finicky
> details of keeping track of memory allocations.  So garbage-collected
> laguages tend to be good for rapid prototyping.  That's good, because
> you get to ship a useful (and useable) product sooner than your
> competitors.
> 
> Of course, the haphazard timing of garbage-collection runs can be an
> issue, although many garbage-collected systems seem to manage this
> without ever causing me annoyance (e.g. web browser ECMAScript engines,
> most obviously).  Java programs sporadically annoy me with this.

I would then suggest GC languages should be optional and not mandatory. At
the present time, QML forces us to use JS.

> Still, with QML, you then have the option of moving the
> performance-critical parts of the code (once the UX-competent developers
> have prototyped it) from interpreted JavaScript to compiled C++.  So you
> get the advantages of rapid development and deployment, combined with
> the ability to fix the performance issues that go with
> garbage-collection.  Python, similarly, lets one recode a module in C.
> 
> Performance of your development team (getting a useful product to market
> quickly) is at least as important as performance of your run-time
> program: and, with an interpreted language layered on top of an engine
> that you can augment in a compiled language, you can have both in
> practice,

Agreed.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Edward Welbourne]

Phil Bouchard  wrote:
>>> - Fornux C++ Superset

On 04/27/2018 04:18 AM, Edward Welbourne wrote:
>> Nothing as yet persuades me that we need this one.  Of course, once your
>> compiler can handle Qt's C++ code, you'll be at liberty to combine the
>> first three above with whatever you like, including your favourite AI
>> engine.

Phil Bouchard (27 April 2018 14:20)
> I'm just trying to help speeding up development here.

It remains that you have failed to persuade folk on this list that
Fornux would in fact speed up development.

>>> I think that’s much better than wasting your time supporting Python or
>>> Javascript that can be easily reverse engineered because of their
>>> interpreted nature.
>>
>> Your obsession with not being easy to reverse engineer suggests you
>> don't really understand the nature of Free Software; our source code is
>> publicly available, so who would need to reverse-engineer it ?
>> We gladly share it and save them the bother,

> I'm referring to Qt's customers who wants to release commercial apps;
> they won't like to know part of their code can be deciphered.

Well, first: copyright protects their work.  The fact that someone else
can decipher it is incidental - even if they publish their source code,
no-one else can *use* that without their permission.  Beyond that, as
long as the code runs on users' computers, some form or another of the
code is out there and the folk who are any good at reverse engineering
are going to discover its secrets, if they care to do so.  Trying to
keep your implementation secret is consequently mostly pointless.

> Performance does play a role as well; you don't want to bottleneck the
> app with any garbage collector at all.

Garbage collectors have their advantages and their costs; the principal
advantage is that developing in a garbage-collected language is
significantly easier (you have fewer irrelevancies to pay attention to),
which means a broader pool of authors can contribute - notably, those
who are good at UX/UI design aren't always also good at the finicky
details of keeping track of memory allocations.  So garbage-collected
laguages tend to be good for rapid prototyping.  That's good, because
you get to ship a useful (and useable) product sooner than your
competitors.

Of course, the haphazard timing of garbage-collection runs can be an
issue, although many garbage-collected systems seem to manage this
without ever causing me annoyance (e.g. web browser ECMAScript engines,
most obviously).  Java programs sporadically annoy me with this.

Still, with QML, you then have the option of moving the
performance-critical parts of the code (once the UX-competent developers
have prototyped it) from interpreted JavaScript to compiled C++.  So you
get the advantages of rapid development and deployment, combined with
the ability to fix the performance issues that go with
garbage-collection.  Python, similarly, lets one recode a module in C.

Performance of your development team (getting a useful product to market
quickly) is at least as important as performance of your run-time
program: and, with an interpreted language layered on top of an engine
that you can augment in a compiled language, you can have both in
practice,

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/27/2018 04:18 AM, Edward Welbourne wrote:

Phil Bouchard  wrote:

And I put Qt on top of the list because you already have all the
necessary layers to jump start to the next level.


Phil Bouchard (27 April 2018 00:06)

What I meant by that is Qt could create the ultimate “holodeck” with a
mixture of:
- Virtual reality headsets
- WebAssembly
- Qt / QML supporting 3D effects


Well, those are all, in some sense, on their way.


Nice...


- Some external AI engine


We might just leave the folk with the AI engines to work out how to use
Qt to give them nice UIs.


Definitely.


- Fornux C++ Superset


Nothing as yet persuades me that we need this one.  Of course, once your
compiler can handle Qt's C++ code, you'll be at liberty to combine the
first three above with whatever you like, including your favourite AI
engine.


I'm just trying to help speeding up development here.


I think that’s much better than wasting your time supporting Python or
Javascript that can be easily reverse engineered because of their
interpreted nature.


Your obsession with not being easy to reverse engineer suggests you
don't really understand the nature of Free Software; our source code is
publicly available, so who would need to reverse-engineer it ?
We gladly share it and save them the bother,


I'm referring to Qt's customers who wants to release commercial apps; 
they won't like to know part of their code can be deciphered. 
Performance does play a role as well; you don't want to bottleneck the 
app with any garbage collector at all.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Edward Welbourne]

Phil Bouchard  wrote:
>> And I put Qt on top of the list because you already have all the
>> necessary layers to jump start to the next level.

Phil Bouchard (27 April 2018 00:06)
> What I meant by that is Qt could create the ultimate “holodeck” with a
> mixture of:
> - Virtual reality headsets
> - WebAssembly
> - Qt / QML supporting 3D effects

Well, those are all, in some sense, on their way.

> - Some external AI engine

We might just leave the folk with the AI engines to work out how to use
Qt to give them nice UIs.

> - Fornux C++ Superset

Nothing as yet persuades me that we need this one.  Of course, once your
compiler can handle Qt's C++ code, you'll be at liberty to combine the
first three above with whatever you like, including your favourite AI
engine.

> I think that’s much better than wasting your time supporting Python or
> Javascript that can be easily reverse engineered because of their
> interpreted nature.

Your obsession with not being easy to reverse engineer suggests you
don't really understand the nature of Free Software; our source code is
publicly available, so who would need to reverse-engineer it ? 
We gladly share it and save them the bother,

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Phil Bouchard  wrote:
> And I put Qt on top of the list because you already have all the 
> necessary layers to jump start to the next level.

What I meant by that is Qt could create the ultimate “holodeck” with a
mixture of:
- Virtual reality headsets
- WebAssembly
- Qt / QML supporting 3D effects
- Some external AI engine
- Fornux C++ Superset

I think that’s much better than wasting your time supporting Python or
Javascript that can be easily reverse engineered because of their
interpreted nature.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/25/2018 12:36 PM, Edward Welbourne wrote:

memory leaks are the most difficult problems to solve.


Well, no, they're not.
I've fixed *lots and lots* of memory leaks.
Some of them were a little tricky: most were trivial.
I can *see* memory leaks just by reading code.
It's one of the reasons code review makes memory leaks rare.
That and nice sensible disciplines like RAII.

Use-after-free is usually harder to solve than a leak.
Deadlocks are almost always harder to solve.


You're right:
1) Deadlocks are much more difficult to find
2) Then comes the use-after-free but they can be easily detected by 
throwing an exception with root_ptr

3) Then we have the memory leaks...

You're a smart person there's no doubt about that and I respect that but 
people like you aren't cheap either.


- Your salary could easily be up to $300k in New York or San Francisco.
- It's going to take at least 6 months to learn the code base correctly.
- Then you can start doing code reviews once a month for 4 different 
authors.


The software I propose is 1% of the price and works right off the bat 
with no learning curve for as much authors as you want.


Furthermore wouldn't you rather do "constructive programming" like 
coding a solid 3D web engine using WebAssembly or an AI engine than 
fixing memory leaks on the iPhone? The industry needs to jump start to 
the next level!



Also do you really want to spend time running Valgrind on iPhones or
Androids to find these problems? First Valgrind won't fix the problem,
second it is not giving always the same answer and third it doesn't run
on all embedded devices.


Well, your life is a lot easier if most of your code is cross-platform,
so that your builds for desktop are using most of the same code that
your device builds use; that way, Valgrind testing on desktop will fix
all the memory leaks in the cross-platform code and you only need to
find the leaks in your device-specific code.


The software for radios used by the military for example cannot be 
tested on the desktop; it needs to be tested on the device itself. 
Furthermore the desktop, the Android and the iPhone don't use the same 
memory management so we have flaky results.



Meanwhile, before I'd ever heard of Valgrind, I was hunting subtle
memory abuses on bitty little devices (compared to which Android and iOS
are luxurious palaces) where gdbserver was my friend and judicious
output streamed over netcat helped us to track down what was going
wrong.  Leaks were less of an issue than use-after-free and kindred
abuses of pointers.  Oh, and image-handling code that assumes it's
running on a little-endian processor.


Luckily gdbserver worked in your case because it mostly always hung in mine.


I believe you over-estimate the difficulty of finding memory leaks, or
of *avoiding writing them in the first place*, which is usually a better
plan.  Mature software development teams have solved this problem.
We don't need garbage-collection: we can do it in C++ or C just fine;
it's all a matter of appropriate discipline.  Meanwhile, the many other
kinds of bugs may be more troublesome than the authors you quote
understand,


Most of the college graduates these days don't even know C++ very well 
because they think it's old fashioned and they don't want to deal with 
these types of memory problems. I am offering a solution to this problem 
so that the entire industry can focus on efficient "constructive 
programming".


And I put Qt on top of the list because you already have all the 
necessary layers to jump start to the next level.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/25/2018 09:45 AM, Eric Lemanisser wrote:

What about
void foo(int (&array)[3])


This one works fine:

void foo(int (&array)[10])
{
cout << __PRETTY_FUNCTION__ << endl;
}

int main()
{
int array[10];

foo(array);

return 0;
}

Correctly outputs:
void foo(const boost::node_proxy &, boost::root_array, 
10> (&))



and
template
void foo(int (&array)[N]) ?


Since I just started testing C++98 as of last week, I haven't yet had a 
chance to test templates thoroughly. So this one is buggy and I'll have 
to fix it.


Both of these functions make sure the caller and the callee use the same 
array size at compile time. I don't see anybody giving away this kind of 
security, especially fro functions called across translation units. Does 
your system store the length of the array next to the pointer at runtime 
? What is the cost of this ?


root_array<> looks like this:

template 
class root_array : public boost::root_ptr
{
typedef boost::root_ptr base;

public:
root_array(base const & p) : base(p)
{
}

root_array(boost::node_proxy const & __y) : base(__y, "", 
boost::create()(__y, S))

{
}

[...]
};

So it knows the length of the array at compile-time but it really 
creates a root_ptr pointing to a std::vector of size S allocated at 
runtime. This is the lowest common factor necessary to make a smooth 
conversion to a root_ptr.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Edward Welbourne]

Phil Bouchard (24 April 2018 19:05)
>>> I’m not sure if you read the link I posted about static analysis but a
>>> software bug can cause billion dollar projects like space shuttles to fail.
>>> Maybe MS Word was a bad example but they can be very costly.

On 04/25/2018 04:46 AM, Edward Welbourne wrote:
>> The Columbia crash wasn't a (computer) software issue.  One can think of
>> the organisational failure that lead to it as a (human) software issue,
>> but I don't think we have static analysis software for that.  The
>> closest you'll get is an ISO 9000 compliance auditor.
>
>> The Ariane 5 crash was a software error, but it wasn't a memory abuse;
>> it was using an under-sized integer to hold a value that overflowed.
>> With luck, static analysis would find that, but it's a pointer abuse.
>
>> The loss of the Mars Climate Orbiter involved a software bug, but it was
>> a wrong choice of units rather than a pointer abuse.  Mixing archaic
>> silly units with sensible SI ones has caused more grief for space
>> missions than pointer abuses.

Phil Bouchard (25 April 2018 14:02)
> You need to see the big picture;

Fun fact: when someone gives an example and I debunk it completely, they
always claim that I'm looking at the wrong example.
I'm never impressed.

Now, as concerns looking at "big pictures": I've been working in the
software industry for three decades (spread over three dozen years), in
a wide diversity of sub-industries, so I will hazard a guess that I have
a better grasp of the big picture than you're exhibiting.  In
particular, the market realities of the software industry are (by no
means the whole of, but still) a pretty important part of the big
picture.

If you ship something tolerably usable that solves problems for real
users today, you can use feed-back and/or revenue from those users to
improve your product rapidly, which wins the loyalty of users, while
your competitors who are still obsessing about not shipping until they
can't find any more bugs are getting no users and shall have an inferior
feature-set by the time they do ship; and may well have more bugs, that
they didn't find but the users will, than yours (in which you fixed the
bugs the users found already).  Buggy, useful and in the app-store today
beats vapourware that claims it'll be bug-free and along "real soon",
especially after the latter has been making those claims for any length
of time.

I note that C++ and Qt are "in the app store today".

> memory leaks are the most difficult problems to solve.

Well, no, they're not.
I've fixed *lots and lots* of memory leaks.
Some of them were a little tricky: most were trivial.
I can *see* memory leaks just by reading code.
It's one of the reasons code review makes memory leaks rare.
That and nice sensible disciplines like RAII.

Use-after-free is usually harder to solve than a leak.
Deadlocks are almost always harder to solve.

Some software teams (perhaps because their managers fear the costs)
don't adopt the widely-understood best practices that make leaks rare
and easy to solve.  Those teams end up with leaky code; and the leaks
are their biggest problem.  However, extrapolating from these poorly run
teams to the whole industry is misguided.  Those who've endured such
teams surely think leaks are the worst, but that's only because they've
taken a false economy: the (modest, up-front) cost of Doing The Job
Right In The First Place is dwarfed by the price of cutting corners.
The Dunning-Kruger effect then promises us that they'll write articles
in which they tell the rest of us that the consequences of their own
incompetence are the biggest problem facing the industry today.
They are, none the less, wrong.

> In the labs you stress-test your software for a few days but in real
> life your software is going to run for a few months consecutively.

I've had to fix the time-reporting code on a web server so that it
correctly handled DST transitions as they happened (without burdening
its performance in between transitions); this was necessary because we
measured expected uptime in years.  We did not have problems with memory
leaks.  We had problems with log messages with timestamps off by an hour
for half of each year (until I fixed this).

Incidentally, getting *that* right was also harder than fixing memory
leaks.  (If you think it's easy - just send a message to the right code
to tzset() just after the next transition - you've forgotten that the
date of next transition is controlled by capricious politicians who may
have moved the transition before that event triggers.  I coded round
that.)

> I was working for a WebKit-based browser for TVs for a software company
> and the browser kept crashing after a day of usage because of memory
> leaks. I mean how are you supposed to watch TV if you need to reboot the
> set-top box every day at a random time?

I worked on the Opera browser, back when its engine was Presto, and we
fixed our share of leaks; which is one of the things that prom

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Eric Lemanisser  wrote:
> What about
> void foo(int (&array)[3])
> and
> template
> void foo(int (&array)[N]) ?
> Both of these functions make sure the caller and the callee use the same
> array size at compile time. I don't see anybody giving away this kind of
> security, especially fro functions called across translation units. Does
> your system store the length of the array next to the pointer at runtime ?
> What is the cost of this ?

I think it’ll be fine but let me confirm tonight. Thanks.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Konstantin Tokarev]

25.04.2018, 16:46, "Eric Lemanisser" :
> What about
> void foo(int (&array)[3])
> and
> template
> void foo(int (&array)[N]) ?
> Both of these functions make sure the caller and the callee use the same 
> array size at compile time. I don't see anybody giving away this kind of 
> security, especially fro functions called across translation units. Does your 
> system store the length of the array next to the pointer at runtime ? What is 
> the cost of this ?

Also, compiler might do additional optimizations for arrays when everything 
happens in the same translation unit, or when LTO is used.

>
> Le mer. 25 avr. 2018 à 14:58, Phil Bouchard  a écrit :
>> Eric Lemanisser  wrote:
>>> Le mer. 25 avr. 2018 à 14:03, Phil Bouchard  a écrit :
>>>
 On 04/25/2018 04:46 AM, Edward Welbourne wrote:
> Phil Bouchard (24 April 2018 19:05)
>> I’m not sure if you read the link I posted about static analysis but a
>> software bug can cause billion dollar projects like space shuttles to
 fail.
>> Maybe MS Word was a bad example but they can be very costly.
>
> The Columbia crash wasn't a (computer) software issue.  One can think of
> the organisational failure that lead to it as a (human) software issue,
> but I don't think we have static analysis software for that.  The
> closest you'll get is an ISO 9000 compliance auditor.
>
> The Ariane 5 crash was a software error, but it wasn't a memory abuse;
> it was using an under-sized integer to hold a value that overflowed.
> With luck, static analysis would find that, but it's a pointer abuse.
>
> The loss of the Mars Climate Orbiter involved a software bug, but it was
> a wrong choice of units rather than a pointer abuse.  Mixing archaic
> silly units with sensible SI ones has caused more grief for space
> missions than pointer abuses.

 You need to see the big picture; memory leaks are the most difficult
 problems to solve. In the labs you stress-test your software for a few
 days but in real life your software is going to run for a few months
 consecutively.

 I was working for a WebKit-based browser for TVs for a software company
 and the browser kept crashing after a day of usage because of memory
 leaks. I mean how are you supposed to watch TV if you need to reboot the
 set-top box every day at a random time?

 Also do you really want to spend time running Valgrind on iPhones or
 Androids to find these problems? First Valgrind won't fix the problem,
 second it is not giving always the same answer and third it doesn't run
 on all embedded devices.

 There is more you can read about the subject here:

 "Real Production Issue - Hard to find memory leaks"
 https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh

 And BTW:

 "Garbage collection is out the window, because you cannot know when it
 is going to happen or how long it will take, which leads to stuttering
 frame rates."

 https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games

> So bugs can have disastrous consequences, sure; but fixing all pointer
> abuses won't stop that from being the case.  Meanwhile, in the world of
> most programmers, most bugs are more or less endurable and most users
> would sooner have something that ships today with a few endurable bugs
> than not have the software that helps them do whatever it is they do
> until someone is sure there are no bugs in it.  Buts aren't the only
> thing that can cause a software project to fail.
>
>> Also it is possible for me to support nested structures by prefixing
 class
>> names so that their meta-data fits into the top-level namespace but for
 the
>> moment they’re not. But those are personal preferences like not using
>> underscores in function names, etc.
>
> Well, if you can support nested structures, you might have a better
> chance of persuading folk to port to your new language; but those with
> large code-bases aren't about to re-write them to eliminate nested
> structures just because you regard that choice as a personal preference.
> I note that Qt has plenty of nested structures.
> I'm not volunteering to refactor them away.

 Support for nested structures is easy to fix and will just take a day or
 two to do so. For example:

 struct A
 {
 struct B
 {
 };
 };

 Will be converted into the following so that I can have their
 specialization in a top-level namespace:

 struct A__B
 {
 };

 struct A
 {
 };


>>> This would break existing code, as name lookup from nested class should
>>> visit first enclosing class before visiting namespace. Also, the nested
>>> class must have access to all names (private, protected, etc) to which the
>>> en

Re: [Development] Fornux C++ Superset

[Eric Lemanisser]

What about
void foo(int (&array)[3])
and
template
void foo(int (&array)[N]) ?
Both of these functions make sure the caller and the callee use the same
array size at compile time. I don't see anybody giving away this kind of
security, especially fro functions called across translation units. Does
your system store the length of the array next to the pointer at runtime ?
What is the cost of this ?

Le mer. 25 avr. 2018 à 14:58, Phil Bouchard  a écrit :

> Eric Lemanisser  wrote:
> > Le mer. 25 avr. 2018 à 14:03, Phil Bouchard  a
> écrit :
> >
> >> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
> >>> Phil Bouchard (24 April 2018 19:05)
>  I’m not sure if you read the link I posted about static analysis but a
>  software bug can cause billion dollar projects like space shuttles to
> >> fail.
>  Maybe MS Word was a bad example but they can be very costly.
> >>>
> >>> The Columbia crash wasn't a (computer) software issue.  One can think
> of
> >>> the organisational failure that lead to it as a (human) software issue,
> >>> but I don't think we have static analysis software for that.  The
> >>> closest you'll get is an ISO 9000 compliance auditor.
> >>>
> >>> The Ariane 5 crash was a software error, but it wasn't a memory abuse;
> >>> it was using an under-sized integer to hold a value that overflowed.
> >>> With luck, static analysis would find that, but it's a pointer abuse.
> >>>
> >>> The loss of the Mars Climate Orbiter involved a software bug, but it
> was
> >>> a wrong choice of units rather than a pointer abuse.  Mixing archaic
> >>> silly units with sensible SI ones has caused more grief for space
> >>> missions than pointer abuses.
> >>
> >> You need to see the big picture; memory leaks are the most difficult
> >> problems to solve. In the labs you stress-test your software for a few
> >> days but in real life your software is going to run for a few months
> >> consecutively.
> >>
> >> I was working for a WebKit-based browser for TVs for a software company
> >> and the browser kept crashing after a day of usage because of memory
> >> leaks. I mean how are you supposed to watch TV if you need to reboot the
> >> set-top box every day at a random time?
> >>
> >> Also do you really want to spend time running Valgrind on iPhones or
> >> Androids to find these problems? First Valgrind won't fix the problem,
> >> second it is not giving always the same answer and third it doesn't run
> >> on all embedded devices.
> >>
> >> There is more you can read about the subject here:
> >>
> >> "Real Production Issue - Hard to find memory leaks"
> >> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
> >>
> >> And BTW:
> >>
> >> "Garbage collection is out the window, because you cannot know when it
> >> is going to happen or how long it will take, which leads to stuttering
> >> frame rates."
> >>
> >>
> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
> >>
> >>> So bugs can have disastrous consequences, sure; but fixing all pointer
> >>> abuses won't stop that from being the case.  Meanwhile, in the world of
> >>> most programmers, most bugs are more or less endurable and most users
> >>> would sooner have something that ships today with a few endurable bugs
> >>> than not have the software that helps them do whatever it is they do
> >>> until someone is sure there are no bugs in it.  Buts aren't the only
> >>> thing that can cause a software project to fail.
> >>>
>  Also it is possible for me to support nested structures by prefixing
> >> class
>  names so that their meta-data fits into the top-level namespace but
> for
> >> the
>  moment they’re not. But those are personal preferences like not using
>  underscores in function names, etc.
> >>>
> >>> Well, if you can support nested structures, you might have a better
> >>> chance of persuading folk to port to your new language; but those with
> >>> large code-bases aren't about to re-write them to eliminate nested
> >>> structures just because you regard that choice as a personal
> preference.
> >>> I note that Qt has plenty of nested structures.
> >>> I'm not volunteering to refactor them away.
> >>
> >> Support for nested structures is easy to fix and will just take a day or
> >> two to do so. For example:
> >>
> >> struct A
> >> {
> >> struct B
> >> {
> >> };
> >> };
> >>
> >> Will be converted into the following so that I can have their
> >> specialization in a top-level namespace:
> >>
> >> struct A__B
> >> {
> >> };
> >>
> >> struct A
> >> {
> >> };
> >>
> >>
> > This would break existing code, as name lookup from nested class should
> > visit first enclosing class before visiting namespace. Also, the nested
> > class must have access to all names (private, protected, etc) to which
> the
> > enclosing class has access (
> > http://en.cppreference.com/w/cpp/language/nested_types)
> >
> > Since there is no hidden catch then I will tell you right now that:
> >> - NULL C pointers will n

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Eric Lemanisser  wrote:
> Le mer. 25 avr. 2018 à 14:03, Phil Bouchard  a écrit :
> 
>> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
>>> Phil Bouchard (24 April 2018 19:05)
 I’m not sure if you read the link I posted about static analysis but a
 software bug can cause billion dollar projects like space shuttles to
>> fail.
 Maybe MS Word was a bad example but they can be very costly.
>>> 
>>> The Columbia crash wasn't a (computer) software issue.  One can think of
>>> the organisational failure that lead to it as a (human) software issue,
>>> but I don't think we have static analysis software for that.  The
>>> closest you'll get is an ISO 9000 compliance auditor.
>>> 
>>> The Ariane 5 crash was a software error, but it wasn't a memory abuse;
>>> it was using an under-sized integer to hold a value that overflowed.
>>> With luck, static analysis would find that, but it's a pointer abuse.
>>> 
>>> The loss of the Mars Climate Orbiter involved a software bug, but it was
>>> a wrong choice of units rather than a pointer abuse.  Mixing archaic
>>> silly units with sensible SI ones has caused more grief for space
>>> missions than pointer abuses.
>> 
>> You need to see the big picture; memory leaks are the most difficult
>> problems to solve. In the labs you stress-test your software for a few
>> days but in real life your software is going to run for a few months
>> consecutively.
>> 
>> I was working for a WebKit-based browser for TVs for a software company
>> and the browser kept crashing after a day of usage because of memory
>> leaks. I mean how are you supposed to watch TV if you need to reboot the
>> set-top box every day at a random time?
>> 
>> Also do you really want to spend time running Valgrind on iPhones or
>> Androids to find these problems? First Valgrind won't fix the problem,
>> second it is not giving always the same answer and third it doesn't run
>> on all embedded devices.
>> 
>> There is more you can read about the subject here:
>> 
>> "Real Production Issue - Hard to find memory leaks"
>> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
>> 
>> And BTW:
>> 
>> "Garbage collection is out the window, because you cannot know when it
>> is going to happen or how long it will take, which leads to stuttering
>> frame rates."
>> 
>> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
>> 
>>> So bugs can have disastrous consequences, sure; but fixing all pointer
>>> abuses won't stop that from being the case.  Meanwhile, in the world of
>>> most programmers, most bugs are more or less endurable and most users
>>> would sooner have something that ships today with a few endurable bugs
>>> than not have the software that helps them do whatever it is they do
>>> until someone is sure there are no bugs in it.  Buts aren't the only
>>> thing that can cause a software project to fail.
>>> 
 Also it is possible for me to support nested structures by prefixing
>> class
 names so that their meta-data fits into the top-level namespace but for
>> the
 moment they’re not. But those are personal preferences like not using
 underscores in function names, etc.
>>> 
>>> Well, if you can support nested structures, you might have a better
>>> chance of persuading folk to port to your new language; but those with
>>> large code-bases aren't about to re-write them to eliminate nested
>>> structures just because you regard that choice as a personal preference.
>>> I note that Qt has plenty of nested structures.
>>> I'm not volunteering to refactor them away.
>> 
>> Support for nested structures is easy to fix and will just take a day or
>> two to do so. For example:
>> 
>> struct A
>> {
>> struct B
>> {
>> };
>> };
>> 
>> Will be converted into the following so that I can have their
>> specialization in a top-level namespace:
>> 
>> struct A__B
>> {
>> };
>> 
>> struct A
>> {
>> };
>> 
>> 
> This would break existing code, as name lookup from nested class should
> visit first enclosing class before visiting namespace. Also, the nested
> class must have access to all names (private, protected, etc) to which the
> enclosing class has access (
> http://en.cppreference.com/w/cpp/language/nested_types)
> 
> Since there is no hidden catch then I will tell you right now that:
>> - NULL C pointers will need to be typed
>> - pointer casts to their encompassing structure needs to use
>> _containerof() macro
>> - C-style array parameters needs to be converted to pointers
>> 
> What for ? you loose the size information by doing so.

No:

void foo(int array[])
{...}

void foo(int * array)
{...}

Are the same thing.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Philippe]

>> memory leaks are the most difficult problems to solve

Really NOT !

Philippe

On Wed, 25 Apr 2018 08:02:54 -0400
Phil Bouchard  wrote:

> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
> > Phil Bouchard (24 April 2018 19:05)
> >> I’m not sure if you read the link I posted about static analysis but a
> >> software bug can cause billion dollar projects like space shuttles to fail.
> >> Maybe MS Word was a bad example but they can be very costly.
> >
> > The Columbia crash wasn't a (computer) software issue.  One can think of
> > the organisational failure that lead to it as a (human) software issue,
> > but I don't think we have static analysis software for that.  The
> > closest you'll get is an ISO 9000 compliance auditor.
> >
> > The Ariane 5 crash was a software error, but it wasn't a memory abuse;
> > it was using an under-sized integer to hold a value that overflowed.
> > With luck, static analysis would find that, but it's a pointer abuse.
> >
> > The loss of the Mars Climate Orbiter involved a software bug, but it was
> > a wrong choice of units rather than a pointer abuse.  Mixing archaic
> > silly units with sensible SI ones has caused more grief for space
> > missions than pointer abuses.
> 
> You need to see the big picture; memory leaks are the most difficult problems 
> to solve. In the labs you stress-test your software for a few days but in 
> real life your software is going to run for a few months consecutively.
> 
> I was working for a WebKit-based browser for TVs for a software company and 
> the browser kept crashing after a day of usage because of memory leaks. I 
> mean how are you supposed to watch TV if you need to reboot the set-top box 
> every day at a random time?
> 
> Also do you really want to spend time running Valgrind on iPhones or Androids 
> to find these problems? First Valgrind won't fix the problem, second it is 
> not giving always the same answer and third it doesn't run on all embedded 
> devices.
> 
> There is more you can read about the subject here:
> 
> "Real Production Issue - Hard to find memory leaks"
> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
> 
> And BTW:
> 
> "Garbage collection is out the window, because you cannot know when it is 
> going to happen or how long it will take, which leads to stuttering frame 
> rates."
> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
> 
> > So bugs can have disastrous consequences, sure; but fixing all pointer
> > abuses won't stop that from being the case.  Meanwhile, in the world of
> > most programmers, most bugs are more or less endurable and most users
> > would sooner have something that ships today with a few endurable bugs
> > than not have the software that helps them do whatever it is they do
> > until someone is sure there are no bugs in it.  Buts aren't the only
> > thing that can cause a software project to fail.
> >
> >> Also it is possible for me to support nested structures by prefixing class
> >> names so that their meta-data fits into the top-level namespace but for the
> >> moment they’re not. But those are personal preferences like not using
> >> underscores in function names, etc.
> >
> > Well, if you can support nested structures, you might have a better
> > chance of persuading folk to port to your new language; but those with
> > large code-bases aren't about to re-write them to eliminate nested
> > structures just because you regard that choice as a personal preference.
> > I note that Qt has plenty of nested structures.
> > I'm not volunteering to refactor them away.
> 
> Support for nested structures is easy to fix and will just take a day or two 
> to do so. For example:
> 
> struct A
> {
>struct B
>{
>};
> };
> 
> Will be converted into the following so that I can have their specialization 
> in a top-level namespace:
> 
> struct A__B
> {
> };
> 
> struct A
> {
> };
> 
> Since there is no hidden catch then I will tell you right now that:
> - NULL C pointers will need to be typed
> - pointer casts to their encompassing structure needs to use _containerof() 
> macro
> - C-style array parameters needs to be converted to pointers
> - Types instantiated in the same statement need not be different (Ex.: int * 
> i, j[4]; // needs to be 2 different statements)
> 
> That's about it. It took me 1 week to adapt "libarchive" to follow the 
> aforementioned rules:
> https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b
> 
> 
> Regards,
> -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] Fornux C++ Superset

[Phil Bouchard]

On 04/25/2018 08:17 AM, Eric Lemanisser wrote:


Support for nested structures is easy to fix and will just take a
day or
two to do so. For example:

struct A
{
    struct B
    {
    };
};

Will be converted into the following so that I can have their
specialization in a top-level namespace:

struct A__B
{
};

struct A
{
};


This would break existing code, as name lookup from nested class should 
visit first enclosing class before visiting namespace. Also, the nested 
class must have access to all names (private, protected, etc) to which 
the enclosing class has access 
(http://en.cppreference.com/w/cpp/language/nested_types)


I forgot to mention that these rewritten structures are used to hold 
meta-data only, used internally.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Eric Lemanisser]

Le mer. 25 avr. 2018 à 14:03, Phil Bouchard  a écrit :

> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
> > Phil Bouchard (24 April 2018 19:05)
> >> I’m not sure if you read the link I posted about static analysis but a
> >> software bug can cause billion dollar projects like space shuttles to
> fail.
> >> Maybe MS Word was a bad example but they can be very costly.
> >
> > The Columbia crash wasn't a (computer) software issue.  One can think of
> > the organisational failure that lead to it as a (human) software issue,
> > but I don't think we have static analysis software for that.  The
> > closest you'll get is an ISO 9000 compliance auditor.
> >
> > The Ariane 5 crash was a software error, but it wasn't a memory abuse;
> > it was using an under-sized integer to hold a value that overflowed.
> > With luck, static analysis would find that, but it's a pointer abuse.
> >
> > The loss of the Mars Climate Orbiter involved a software bug, but it was
> > a wrong choice of units rather than a pointer abuse.  Mixing archaic
> > silly units with sensible SI ones has caused more grief for space
> > missions than pointer abuses.
>
> You need to see the big picture; memory leaks are the most difficult
> problems to solve. In the labs you stress-test your software for a few
> days but in real life your software is going to run for a few months
> consecutively.
>
> I was working for a WebKit-based browser for TVs for a software company
> and the browser kept crashing after a day of usage because of memory
> leaks. I mean how are you supposed to watch TV if you need to reboot the
> set-top box every day at a random time?
>
> Also do you really want to spend time running Valgrind on iPhones or
> Androids to find these problems? First Valgrind won't fix the problem,
> second it is not giving always the same answer and third it doesn't run
> on all embedded devices.
>
> There is more you can read about the subject here:
>
> "Real Production Issue - Hard to find memory leaks"
> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
>
> And BTW:
>
> "Garbage collection is out the window, because you cannot know when it
> is going to happen or how long it will take, which leads to stuttering
> frame rates."
>
> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
>
> > So bugs can have disastrous consequences, sure; but fixing all pointer
> > abuses won't stop that from being the case.  Meanwhile, in the world of
> > most programmers, most bugs are more or less endurable and most users
> > would sooner have something that ships today with a few endurable bugs
> > than not have the software that helps them do whatever it is they do
> > until someone is sure there are no bugs in it.  Buts aren't the only
> > thing that can cause a software project to fail.
> >
> >> Also it is possible for me to support nested structures by prefixing
> class
> >> names so that their meta-data fits into the top-level namespace but for
> the
> >> moment they’re not. But those are personal preferences like not using
> >> underscores in function names, etc.
> >
> > Well, if you can support nested structures, you might have a better
> > chance of persuading folk to port to your new language; but those with
> > large code-bases aren't about to re-write them to eliminate nested
> > structures just because you regard that choice as a personal preference.
> > I note that Qt has plenty of nested structures.
> > I'm not volunteering to refactor them away.
>
> Support for nested structures is easy to fix and will just take a day or
> two to do so. For example:
>
> struct A
> {
>struct B
>{
>};
> };
>
> Will be converted into the following so that I can have their
> specialization in a top-level namespace:
>
> struct A__B
> {
> };
>
> struct A
> {
> };
>
>
This would break existing code, as name lookup from nested class should
visit first enclosing class before visiting namespace. Also, the nested
class must have access to all names (private, protected, etc) to which the
enclosing class has access (
http://en.cppreference.com/w/cpp/language/nested_types)

Since there is no hidden catch then I will tell you right now that:
> - NULL C pointers will need to be typed
> - pointer casts to their encompassing structure needs to use
> _containerof() macro
> - C-style array parameters needs to be converted to pointers
>
What for ? you loose the size information by doing so.

> - Types instantiated in the same statement need not be different (Ex.:
> int * i, j[4]; // needs to be 2 different statements)
>
> That's about it. It took me 1 week to adapt "libarchive" to follow the
> aforementioned rules:
>
> https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b
>
>
> Regards,
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
__

Re: [Development] Fornux C++ Superset

[Viktor Engelmann]

On 25.04.2018 14:02, Phil Bouchard wrote:
> You need to see the big picture; memory leaks are the most difficult
> problems to solve.

You have clearly never solved a cycle-lock.

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
viktor.engelm...@qt.io
+49 151 26784521
http://qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/25/2018 04:46 AM, Edward Welbourne wrote:

Phil Bouchard (24 April 2018 19:05)

I’m not sure if you read the link I posted about static analysis but a
software bug can cause billion dollar projects like space shuttles to fail.
Maybe MS Word was a bad example but they can be very costly.


The Columbia crash wasn't a (computer) software issue.  One can think of
the organisational failure that lead to it as a (human) software issue,
but I don't think we have static analysis software for that.  The
closest you'll get is an ISO 9000 compliance auditor.

The Ariane 5 crash was a software error, but it wasn't a memory abuse;
it was using an under-sized integer to hold a value that overflowed.
With luck, static analysis would find that, but it's a pointer abuse.

The loss of the Mars Climate Orbiter involved a software bug, but it was
a wrong choice of units rather than a pointer abuse.  Mixing archaic
silly units with sensible SI ones has caused more grief for space
missions than pointer abuses.


You need to see the big picture; memory leaks are the most difficult 
problems to solve. In the labs you stress-test your software for a few 
days but in real life your software is going to run for a few months 
consecutively.


I was working for a WebKit-based browser for TVs for a software company 
and the browser kept crashing after a day of usage because of memory 
leaks. I mean how are you supposed to watch TV if you need to reboot the 
set-top box every day at a random time?


Also do you really want to spend time running Valgrind on iPhones or 
Androids to find these problems? First Valgrind won't fix the problem, 
second it is not giving always the same answer and third it doesn't run 
on all embedded devices.


There is more you can read about the subject here:

"Real Production Issue - Hard to find memory leaks"
https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh

And BTW:

"Garbage collection is out the window, because you cannot know when it 
is going to happen or how long it will take, which leads to stuttering 
frame rates."

https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games


So bugs can have disastrous consequences, sure; but fixing all pointer
abuses won't stop that from being the case.  Meanwhile, in the world of
most programmers, most bugs are more or less endurable and most users
would sooner have something that ships today with a few endurable bugs
than not have the software that helps them do whatever it is they do
until someone is sure there are no bugs in it.  Buts aren't the only
thing that can cause a software project to fail.


Also it is possible for me to support nested structures by prefixing class
names so that their meta-data fits into the top-level namespace but for the
moment they’re not. But those are personal preferences like not using
underscores in function names, etc.


Well, if you can support nested structures, you might have a better
chance of persuading folk to port to your new language; but those with
large code-bases aren't about to re-write them to eliminate nested
structures just because you regard that choice as a personal preference.
I note that Qt has plenty of nested structures.
I'm not volunteering to refactor them away.


Support for nested structures is easy to fix and will just take a day or 
two to do so. For example:


struct A
{
  struct B
  {
  };
};

Will be converted into the following so that I can have their 
specialization in a top-level namespace:


struct A__B
{
};

struct A
{
};

Since there is no hidden catch then I will tell you right now that:
- NULL C pointers will need to be typed
- pointer casts to their encompassing structure needs to use 
_containerof() macro

- C-style array parameters needs to be converted to pointers
- Types instantiated in the same statement need not be different (Ex.: 
int * i, j[4]; // needs to be 2 different statements)


That's about it. It took me 1 week to adapt "libarchive" to follow the 
aforementioned rules:

https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Edward Welbourne]

Phil Bouchard (24 April 2018 19:05)
> I’m not sure if you read the link I posted about static analysis but a
> software bug can cause billion dollar projects like space shuttles to fail.
> Maybe MS Word was a bad example but they can be very costly.

The Columbia crash wasn't a (computer) software issue.  One can think of
the organisational failure that lead to it as a (human) software issue,
but I don't think we have static analysis software for that.  The
closest you'll get is an ISO 9000 compliance auditor.

The Ariane 5 crash was a software error, but it wasn't a memory abuse;
it was using an under-sized integer to hold a value that overflowed.
With luck, static analysis would find that, but it's a pointer abuse.

The loss of the Mars Climate Orbiter involved a software bug, but it was
a wrong choice of units rather than a pointer abuse.  Mixing archaic
silly units with sensible SI ones has caused more grief for space
missions than pointer abuses.

So bugs can have disastrous consequences, sure; but fixing all pointer
abuses won't stop that from being the case.  Meanwhile, in the world of
most programmers, most bugs are more or less endurable and most users
would sooner have something that ships today with a few endurable bugs
than not have the software that helps them do whatever it is they do
until someone is sure there are no bugs in it.  Buts aren't the only
thing that can cause a software project to fail.

> Also it is possible for me to support nested structures by prefixing class
> names so that their meta-data fits into the top-level namespace but for the
> moment they’re not. But those are personal preferences like not using
> underscores in function names, etc.

Well, if you can support nested structures, you might have a better
chance of persuading folk to port to your new language; but those with
large code-bases aren't about to re-write them to eliminate nested
structures just because you regard that choice as a personal preference.
I note that Qt has plenty of nested structures.
I'm not volunteering to refactor them away.

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Edward Welbourne  wrote:
> On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:
 Remember when Wordperfect kept crashing in Windows 3.1 for some strange
 reason back in the days? People ended up using MS Word. The same with
 Netscape...
> 
> On 04/23/2018 10:34 PM, Thiago Macieira wrote:
>>> There are a lot of reasons why people chose MS Word, not just crashes on
>>> Wordperfect. Not to mention that Word crashes too.
> 
> Phil Bouchard (24 April 2018 07:35)
>> Well crashes don't help either.
> 
> None the less, "1 crash makes your application worthless" grossly
> exaggerates the severity of a crash.  A crash that happens reliably on
> start-up makes an application useless, to be sure, but I have often
> learned to not do that one thing that triggers a crash in a piece of
> software that I routinely find very useful (despite the fact that I have
> to take care to not do that one thing).  Meanwhile, many defects that
> aren't crashes limit the value of software by significantly more - these
> needn't even be bugs; simply not doing a thing that I find too useful to
> do without, even if it's omitted for a Good Reason, is enough to make a
> piece of software useless - at least in the presence of a competitor
> which does the thing it doesn't.  Speaking of which:
> 
>> - There are minor rules you need to follow to make the code compile
>> correctly, like nested structures aren't supported, etc. but you'll get
>> the errors at compile-time thus when it runs then it cannot crash.
> 
> That is not a minor rule.
> That is a show-stoppper.
> We're not about to give up nested structures !
> 
> I think you'll find there are *many* programmers who would sooner have a
> few sporadic crashes than limit themselves to the programs they can
> write without nested structures (either in their own code or in any
> libraries their code is a client of).  So the lack of that feature is a
> prime example of a defect in software that's worse than a crash - your
> users would sooner inflict sporadic crashes on their users than live
> without this feature.  Furthermore, the vast majority of users would
> sooner have a program that sporadically crashes, as long as it's
> tolerably rare, than have one with fewer features because it was written
> by a programmer who was missing a language feature that would have made
> it easier to do more with less.
> 
> The reason why the software industry is a bit slap-dash about bugs is
> that the market encourages shipping something that works adequately to
> do something more useful, for the user, than the competition offers:
> those who ship something useful (but a bit buggy) get large market share
> before those who ship (less useful but) bug-free software even get their
> products to market - which, in fact, they seldom do.  I know one or two
> programmers who, when they promise to deliver bug-free software, can
> actually be trusted to do so (they'll also be charging highly for that;
> and promising to, in the event of any bug, give back all the money and
> fix the bug); but most programmers are *not capable* of that, for any
> non-trivial program, and I doubt any software team of any size can be
> confident of delivering entirely bug-free software.  As it happens,
> delivering engaging, useful software - that delivers value to its users
> - tends to take a fairly large team (or take so long that the market has
> been captured by someone else, who had a large team, before you ship).
> 
>   Eddy.
> 

I’m not sure if you read the link I posted about static analysis but a
software bug can cause billion dollar projects like space shuttles to fail.
Maybe MS Word was a bad example but they can be very costly.

Also it is possible for me to support nested structures by prefixing class
names so that their meta-data fits into the top-level namespace but for the
moment they’re not. But those are personal preferences like not using
underscores in function names, etc.


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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

Thiago Macieira  wrote:
> On Tuesday, 24 April 2018 06:13:39 PDT Phil Bouchard wrote:
>>> I can tell you right now Qt is not interested in switching languages.
>> 
>> You mean switching Javascript? I already started working in a compiled
>> language to replace Javascript in the past, so perhaps I can resume
>> these efforts.
>> 
>> Anyway I have high hopes for Qt as I am using it since January 2000.
> 
> I meant C++.
> 
> We'll continue using C++ and have no intention of changing.
> 
> Your solution is technically a new language.
> 

It sure is a new language as it adds meta-data in a top-level namespace and
solves what the committee is looking for in the long term.

I understand the changes required are non-negligible for Qt and that’s
unfortunate. But thanks for your time I really appreciate and good luck to
Qt!


Regards,
-Phil


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

Re: [Development] Fornux C++ Superset

[Thiago Macieira]

On Tuesday, 24 April 2018 06:13:39 PDT Phil Bouchard wrote:
> > I can tell you right now Qt is not interested in switching languages.
> 
> You mean switching Javascript? I already started working in a compiled
> language to replace Javascript in the past, so perhaps I can resume
> these efforts.
> 
> Anyway I have high hopes for Qt as I am using it since January 2000.

I meant C++.

We'll continue using C++ and have no intention of changing.

Your solution is technically a new language.

-- 
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] Fornux C++ Superset

[Phil Bouchard]

On 04/24/2018 01:51 AM, Thiago Macieira wrote:

On Monday, 23 April 2018 22:35:36 PDT Phil Bouchard wrote:

On 04/23/2018 10:34 PM, Thiago Macieira wrote:

On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:

- QML is an interpreted language thus it can be reverse engineered and
plagiarized quite easily.


There's a QML compiler.


Which is great but does it compile the Javascript code as well?


Yes, to an extent.


Okay but one way or the other it'll always use the garbage collector as
a backend.


Correct. But that has nothing to do with your argument of reverse engineering.


I am extending my arguments because they weren't well articulated.


My point is: I doubt that you have solved all crashes. You have not. Your
framework may be a huge improvement over a lot of techniques people use
today, but your claims are not believable. You should be more precise in
your wording.


Here are the different ways to make an application crash:
http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes
-in-c/


Here are better summaries:
https://www.ibm.com/developerworks/aix/library/au-toughgame/
https://software.intel.com/en-us/inspector-user-guide-windows-problem-type-reference


Dereferencing dangling pointers is not the only way to cause crashes. In fact,
depending on when it happens, that usually has no effect.

Memory overruns cause way more problems. Your solution won't fix that.


I am trying quickly to find the crash statistics and according to the 
following research: "Memory leaks are one of the primary causes of 
software aging.":

https://www.researchgate.net/publication/319980827_Detection_of_Memory_Leaks_in_CC_Code_via_Machine_Learning


Use of uninitialised memory almost always causes immediate crashes. Your
solution won't fix that because, by definition, those cause *because* they
happened before your solution. There's always more code that you need to
interface with, so unless you convert EVERYTHING to a safe language (and you
won't), you won't fix all crashes.


All structures and all atomic types are properly initialized to their 
default values with the parser... even for C apps.



Crashes also happen because of use of improper instructions. That has nothing
to do with memory.


- The code that was modified by the parser interacts perfectly well with
system headers or external libraries that weren't modified at all.


Which can crash.


There is only 1 std C call that uses malloc() under the hood that is 
problematic, like strdup(), but it is overwritten by the parser. Other C 
calls like printf() are properly handled. Again, worse case you will get 
compilation errors, not run-time errors.



The generated code keeps headers that aren't part of your project as
include statements so your compiler / cross-compiler will expand these
headers normally.


I can tell you right now Qt is not interested in switching languages.


You mean switching Javascript? I already started working in a compiled 
language to replace Javascript in the past, so perhaps I can resume 
these efforts.


Anyway I have high hopes for Qt as I am using it since January 2000.


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Edward Welbourne]

On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:
>>> Remember when Wordperfect kept crashing in Windows 3.1 for some strange
>>> reason back in the days? People ended up using MS Word. The same with
>>> Netscape...

On 04/23/2018 10:34 PM, Thiago Macieira wrote:
>> There are a lot of reasons why people chose MS Word, not just crashes on
>> Wordperfect. Not to mention that Word crashes too.

Phil Bouchard (24 April 2018 07:35)
> Well crashes don't help either.

None the less, "1 crash makes your application worthless" grossly
exaggerates the severity of a crash.  A crash that happens reliably on
start-up makes an application useless, to be sure, but I have often
learned to not do that one thing that triggers a crash in a piece of
software that I routinely find very useful (despite the fact that I have
to take care to not do that one thing).  Meanwhile, many defects that
aren't crashes limit the value of software by significantly more - these
needn't even be bugs; simply not doing a thing that I find too useful to
do without, even if it's omitted for a Good Reason, is enough to make a
piece of software useless - at least in the presence of a competitor
which does the thing it doesn't.  Speaking of which:

> - There are minor rules you need to follow to make the code compile
> correctly, like nested structures aren't supported, etc. but you'll get
> the errors at compile-time thus when it runs then it cannot crash.

That is not a minor rule.
That is a show-stoppper.
We're not about to give up nested structures !

I think you'll find there are *many* programmers who would sooner have a
few sporadic crashes than limit themselves to the programs they can
write without nested structures (either in their own code or in any
libraries their code is a client of).  So the lack of that feature is a
prime example of a defect in software that's worse than a crash - your
users would sooner inflict sporadic crashes on their users than live
without this feature.  Furthermore, the vast majority of users would
sooner have a program that sporadically crashes, as long as it's
tolerably rare, than have one with fewer features because it was written
by a programmer who was missing a language feature that would have made
it easier to do more with less.

The reason why the software industry is a bit slap-dash about bugs is
that the market encourages shipping something that works adequately to
do something more useful, for the user, than the competition offers:
those who ship something useful (but a bit buggy) get large market share
before those who ship (less useful but) bug-free software even get their
products to market - which, in fact, they seldom do.  I know one or two
programmers who, when they promise to deliver bug-free software, can
actually be trusted to do so (they'll also be charging highly for that;
and promising to, in the event of any bug, give back all the money and
fix the bug); but most programmers are *not capable* of that, for any
non-trivial program, and I doubt any software team of any size can be
confident of delivering entirely bug-free software.  As it happens,
delivering engaging, useful software - that delivers value to its users
- tends to take a fairly large team (or take so long that the market has
been captured by someone else, who had a large team, before you ship).

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

Re: [Development] Fornux C++ Superset

[Thiago Macieira]

On Monday, 23 April 2018 22:35:36 PDT Phil Bouchard wrote:
> On 04/23/2018 10:34 PM, Thiago Macieira wrote:
> > On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:
>  - QML is an interpreted language thus it can be reverse engineered and
>  plagiarized quite easily.
> >>> 
> >>> There's a QML compiler.
> >> 
> >> Which is great but does it compile the Javascript code as well?
> > 
> > Yes, to an extent.
> 
> Okay but one way or the other it'll always use the garbage collector as
> a backend.

Correct. But that has nothing to do with your argument of reverse engineering. 

> > My point is: I doubt that you have solved all crashes. You have not. Your
> > framework may be a huge improvement over a lot of techniques people use
> > today, but your claims are not believable. You should be more precise in
> > your wording.
> 
> Here are the different ways to make an application crash:
> http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes
> -in-c/

Dereferencing dangling pointers is not the only way to cause crashes. In fact, 
depending on when it happens, that usually has no effect.

Memory overruns cause way more problems. Your solution won't fix that.

Use of uninitialised memory almost always causes immediate crashes. Your 
solution won't fix that because, by definition, those cause *because* they 
happened before your solution. There's always more code that you need to 
interface with, so unless you convert EVERYTHING to a safe language (and you 
won't), you won't fix all crashes.

Crashes also happen because of use of improper instructions. That has nothing 
to do with memory.

> - The code that was modified by the parser interacts perfectly well with
> system headers or external libraries that weren't modified at all.

Which can crash.

> The generated code keeps headers that aren't part of your project as
> include statements so your compiler / cross-compiler will expand these
> headers normally.

I can tell you right now Qt is not interested in switching languages.

-- 
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] Fornux C++ Superset

[Bogdan Vatra]

Hi,

În ziua de marți, 24 aprilie 2018, la 04:08:19 EEST, Phil Bouchard a scris:
> Greetings,
> 
> Because Qt is very powerful, I would like to clarify the importance of
> the following problems despite my previous informal attempts:
> - The recent Qt 5.10.1 still randomly crashes for apps written on the
> iPhone and for the Android as well.

Is there any bug report(s) on this matter? 
Can you please provide some links(s) to the bug reports and a way to 
"randomly" reproduce these problems?
[...]

Cheers,
BogDan.


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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/23/2018 10:34 PM, Thiago Macieira wrote:

On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:

- QML is an interpreted language thus it can be reverse engineered and
plagiarized quite easily.


There's a QML compiler.


Which is great but does it compile the Javascript code as well?


Yes, to an extent.


Okay but one way or the other it'll always use the garbage collector as 
a backend.



Remember when Wordperfect kept crashing in Windows 3.1 for some strange
reason back in the days? People ended up using MS Word. The same with
Netscape...


There are a lot of reasons why people chose MS Word, not just crashes on
Wordperfect. Not to mention that Word crashes too.


Well crashes don't help either.


I have a solution that solves those problems and it's called: "Fornux



C++ Superset":

I doubt it.


As you know I have tested it with a much more complex software called:
"libarchive" and it works flawlessly:
https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7
d191829d5a9b


My point is: I doubt that you have solved all crashes. You have not. Your
framework may be a huge improvement over a lot of techniques people use today,
but your claims are not believable. You should be more precise in your
wording.


Here are the different ways to make an application crash:
http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes-in-c/

- You are free to modify the provided headers to throw an exception on 
buffer overflows and the dereferencing of null pointers but I prefer to 
keep the provided headers free from exceptions to favor speed.


- Explicit free() or delete are ignored and handled implicitly by the 
generated code.


- The code that was modified by the parser interacts perfectly well with 
system headers or external libraries that weren't modified at all.


- There are minor rules you need to follow to make the code compile 
correctly, like nested structures aren't supported, etc. but you'll get 
the errors at compile-time thus when it runs then it cannot crash.


- You are free to write any kernel module, AI engine, etc. without any 
explicit call to free() and the parser will handle it correctly.



- Fornux C++ Superset harnesses the power of Clang.


Does it mean other compilers are not supported? That's a showstopper.


No it's just a Clang-based layer that injects complex C++ code into
existing C & C++98 projects. You can use any C++11 compiler to compile
the resulting code.


So I need Clang to parse my code. Will it parse Microsoft headers properly?


The generated code keeps headers that aren't part of your project as 
include statements so your compiler / cross-compiler will expand these 
headers normally.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Thiago Macieira]

On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:
> >> - QML is an interpreted language thus it can be reverse engineered and
> >> plagiarized quite easily.
> > 
> > There's a QML compiler.
> 
> Which is great but does it compile the Javascript code as well?

Yes, to an extent.

> Remember when Wordperfect kept crashing in Windows 3.1 for some strange
> reason back in the days? People ended up using MS Word. The same with
> Netscape...

There are a lot of reasons why people chose MS Word, not just crashes on 
Wordperfect. Not to mention that Word crashes too.

> 
> >> I have a solution that solves those problems and it's called: "Fornux
> > 
> >> C++ Superset":
> > I doubt it.
> 
> As you know I have tested it with a much more complex software called:
> "libarchive" and it works flawlessly:
> https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7
> d191829d5a9b

My point is: I doubt that you have solved all crashes. You have not. Your 
framework may be a huge improvement over a lot of techniques people use today, 
but your claims are not believable. You should be more precise in your 
wording.

> >> - Fornux C++ Superset harnesses the power of Clang.
> > 
> > Does it mean other compilers are not supported? That's a showstopper.
> 
> No it's just a Clang-based layer that injects complex C++ code into
> existing C & C++98 projects. You can use any C++11 compiler to compile
> the resulting code.

So I need Clang to parse my code. Will it parse Microsoft headers properly?
-- 
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] Fornux C++ Superset

[Phil Bouchard]

On 04/23/2018 09:46 PM, Phil Bouchard wrote:

- Fornux C++ Superset harnesses the power of Clang.


Does it mean other compilers are not supported? That's a showstopper.


No it's just a Clang-based layer that injects complex C++ code into 
existing C & C++98 projects. You can use any C++11 compiler to compile 
the resulting code.


It is what we call: "static program analysis", which is the corporations 
works nowadays as you know:

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

Here is why:
https://hackernoon.com/why-you-should-really-care-about-c-c-static-analysis-db13f4463b2d


Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Phil Bouchard]

On 04/23/2018 09:29 PM, Thiago Macieira wrote:

On Monday, 23 April 2018 18:08:19 PDT Phil Bouchard wrote:

Greetings,

Because Qt is very powerful, I would like to clarify the importance of
the following problems despite my previous informal attempts:
- The recent Qt 5.10.1 still randomly crashes for apps written on the
iPhone and for the Android as well.


Do we have bug reports for those? I doubt the crashes are random, they only
appear to be. They are likely very deterministic and most of them are easy to
fix, if the issue is in Qt.


I programmed a Facebook-like interface where I scroll up and down very 
fast and it ends up crashing. I can try to get a backtrace on the iOS 
and file a bug report. But that's a head's up.



- QML is an interpreted language thus it can be reverse engineered and
plagiarized quite easily.


There's a QML compiler.


Which is great but does it compile the Javascript code as well?


As you know 1 crash makes your application worthless. Those are facts,
whether today's mainstream developers like it or not.


Those are not the facts. I've seen Windows, Linux and macOS operating system
crashes. Those are hardly worthless. They're worth billions. My apps on my
phone crash sometimes too, and yet I still use them.


Remember when Wordperfect kept crashing in Windows 3.1 for some strange 
reason back in the days? People ended up using MS Word. The same with 
Netscape...



I have a solution that solves those problems and it's called: "Fornux
C++ Superset":


I doubt it.


As you know I have tested it with a much more complex software called: 
"libarchive" and it works flawlessly:

https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b


- Fornux C++ Superset harnesses the power of Clang.


Does it mean other compilers are not supported? That's a showstopper.


No it's just a Clang-based layer that injects complex C++ code into 
existing C & C++98 projects. You can use any C++11 compiler to compile 
the resulting code.



Regards,
-Phil

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

Re: [Development] Fornux C++ Superset

[Thiago Macieira]

On Monday, 23 April 2018 18:08:19 PDT Phil Bouchard wrote:
> Greetings,
> 
> Because Qt is very powerful, I would like to clarify the importance of
> the following problems despite my previous informal attempts:
> - The recent Qt 5.10.1 still randomly crashes for apps written on the
> iPhone and for the Android as well.

Do we have bug reports for those? I doubt the crashes are random, they only 
appear to be. They are likely very deterministic and most of them are easy to 
fix, if the issue is in Qt.

> - QML is an interpreted language thus it can be reverse engineered and
> plagiarized quite easily.

There's a QML compiler.

> As you know 1 crash makes your application worthless. Those are facts,
> whether today's mainstream developers like it or not.

Those are not the facts. I've seen Windows, Linux and macOS operating system 
crashes. Those are hardly worthless. They're worth billions. My apps on my 
phone crash sometimes too, and yet I still use them.

> I have a solution that solves those problems and it's called: "Fornux
> C++ Superset":

I doubt it.

> - Fornux C++ Superset harnesses the power of Clang.

Does it mean other compilers are not supported? That's a showstopper.

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