Friday, March 1, 2019

Digest for comp.lang.c++@googlegroups.com - 20 updates in 5 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 03:39PM -0800

On Thursday, February 28, 2019 at 5:31:30 PM UTC-5, Mr Flibble wrote:
> allow individual translation units to be specified within the same source
> file using special directives as you say. This would be a nice feature but
> not essential.
 
CAlive's design allows mixing of CAlive code and VXB++ code (an
XBASE language) natively. The design also allows other blocks to
be compiled using the standard assembly notation, but with the
other language's prefix:
 
_java {
}
 
_c# {
}
 
Et cetera.
 
--
Rick C. Hodgin
Bart <bc@freeuk.com>: Feb 28 06:39PM

On 28/02/2019 15:47, Öö Tiib wrote:
> reuse much of it to produce a C preprocessor somehow faster than
> with 3.5 months? I doubt that since the details are still there and are
> different than those with Ada.
 
As described the project doesn't sound viable, not if the only input for
each new language is a data file.
 
It needs to be code. In other words, you have to write a new compiler
front-end for each language. Perhaps some elements such as lexers can be
reused, or driven from grammar descriptions, but as you say something
like C is going to be different from any other language because of the
peculiar way its preprocessor works. And every language will have its
own quirks.
 
The OP mentioned a semantic module in a way that suggested code plug-ins
for each language. That's another way of saying you need a separate
compiler for each.
 
Maybe all these disparate compilers can be made to fit into a common
framework, but that then doesn't sound much different than using a
make-file to build mixed-language projects.
 
The advantage of a universal compiler, if it tries to do anything
cleverer than just invoking a dedicated compiler for each language, is
then less obvious.
 
But then we get to the fact that all these languages will have the same
target, some VM, but it would need to be a VM that can cope with both
highly dynamic languages and very static ones.
 
Or perhaps (I don't know how it works), it's a more static VM for which
certain dynamic languages will require an extra layer of code, that does
the job of interpreter.
 
So it might be that there will still be a need for compilers and
interpreters, but in some different form.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 01 12:24AM

On 28/02/2019 23:39, Rick C. Hodgin wrote:
 
> _c# {
> }
 
> Et cetera.
 
I will probably use a non-ASCII character to delineate different languages
(source files have to be UTF-8 encoded), perhaps the atheism emoji:
 
⚛⚛c⚛
/* two emoji means make c the default language for this source file */
#include <stdio.h>
⚛c++⚛
#include <iostream>
⚛ada⚛
with Ada.Text_IO;
use Ada.Text_IO;
⚛⚛
 
printf("Hello, world (from C)!\n");
 
⚛c++⚛
std::cout << "Hello, world (from C++)!" << std::endl;
⚛ada⚛
procedure Hello is
begin
Put_Line("Hello, world (from Ada)!");
end Hello;
⚛⚛
 
printf("Hello again from C!\n");
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 04:27PM -0800

On Thursday, February 28, 2019 at 7:24:30 PM UTC-5, Mr Flibble wrote:
> end Hello;
> ⚛⚛
 
> printf("Hello again from C!\n");
 
 
Your way is easier to read, and naturally intuitive.
 
--
Rick C. Hodgin
Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 09:41PM +0200

On 28.02.2019 20:39, Bart wrote:
>> different than those with Ada.
 
> As described the project doesn't sound viable, not if the only input for
> each new language is a data file.
 
I think you all have misinterpreted Mr. Flibble's intent. He said his
universal compiler will support Ada, Python, C, etc. How everybody
interpreted this was that what is supported is the union of all these
languages, so that one would get the hard real-time multithreading from
Ada, all fancy deep learning stuff like NumPy+tensorflow from Python, etc.
 
I guess what he really had in mind was the *intersection* of languages,
so you can write a program for adding 2+2 in Ada, Python, C, etc, and it
would work the same.
Bart <bc@freeuk.com>: Feb 28 09:54PM

On 28/02/2019 19:41, Paavo Helde wrote:
 
> I guess what he really had in mind was the *intersection* of languages,
> so you can write a program for adding 2+2 in Ada, Python, C, etc, and it
> would work the same.
 
No, I assumed that the universal compiler would work with either
language X or Y or Z, always one at a time, with the output always being
the same VM language.
 
I think I did ask about whether mixed source was allowed (one source
file containing a mix of languages, presumably requiring special
directives to tell you what was what), and I also asked about
interfacing between language X and language Y.
 
However, the whole thing is still a bit of a mystery.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 01 04:10AM +0100

On 28.02.2019 23:31, Mr Flibble wrote:
> would allow individual translation units to be specified within the same
> source file using special directives as you say. This would be a nice
> feature but not essential.
 
Donald Knuth would be pleased to hear about this! :)
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Mar 01 10:15AM +0100

On 28/02/2019 23:31, Mr Flibble wrote:
> source file using special directives as you say. This would be a nice
> feature but not essential.
 
> /Flibble
 
Now I /know/ this is all a parody of Rick's ideas.
gazelle@shell.xmission.com (Kenny McCormack): Mar 01 10:43AM

In article <q5at78$71j$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>> feature but not essential.
 
>> /Flibble
 
>Now I /know/ this is all a parody of Rick's ideas.
 
Wonders never cease.
 
Me & DB agreeing on something.
 
--
Christianity is not a religion.
 
- Rick C Hodgin -
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 01 03:09AM -0800

On Friday, March 1, 2019 at 5:43:31 AM UTC-5, Kenny McCormack wrote:
> Christianity is not a religion.
> - Rick C Hodgin -
 
Context:
 
https://groups.google.com/d/msg/comp.lang.c/r8g28GOHslU/QP-vAIHMBQAJ
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 01 03:32AM -0800

On Friday, March 1, 2019 at 6:09:48 AM UTC-5, Rick C. Hodgin wrote:
> > - Rick C Hodgin -
 
> Context:
 
> https://groups.google.com/d/msg/comp.lang.c/r8g28GOHslU/QP-vAIHMBQAJ
 
Additional context:
 
https://groups.google.com/d/msg/comp.lang.c/1F8H2QfQDdM/We0vZ8G6BwAJ
 
--
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 01 01:14PM +0100

On 01.03.2019 10:15, David Brown wrote:
>> feature but not essential.
 
>> /Flibble
 
> Now I /know/ this is all a parody of Rick's ideas.
 
The kind of .mix files the Mr. Fibble describes may be similar to
something that has been tried For Real™, by Microsoft.
 
Namely, .wsh mixed language script files for Windows Script Host, as
described e.g. at <url:
https://en.wikibooks.org/wiki/Windows_Programming/Windows_Script_Host>.
 
One baffling mix of abstraction levels was that a .wsh file, as I
recall, could define a simple COM component. Implemented with scripting
languages. Oh it was a nice technology, and it's still there, but since
it's not been updated for years it doesn't e.g. support UTF-8.
 
 
Cheers!,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 01 05:13PM

Hi!
 
The neos website is live: https://neos.dev/ \o/
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Mar 01 12:41PM -0800

On 3/1/2019 9:13 AM, Mr Flibble wrote:
> Hi!
 
> The neos website is live: https://neos.dev/ \o/
 
Fwiw, be sure to tell me when you get Python 3 up and running. I will
try it out. Also have some experimental dynamic field based DLA
JavaScript code that would be interesting to test on neos:
 
http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test
 
Let it run for around half-a-minute then click somewhere in the square
to create a new DLA seed. It should create renderings like:
 
https://plus.google.com/101799841244447089430/posts/LjJesbaokGd
 
Here is a C++ version using Cairo for the graphics:
 
https://github.com/ChrisMThomasson/CT_fieldDLA
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 01 05:59AM -0800


> On 1/7/2019 11:44 PM, Jorgen Grahn wrote:
 
>> On Sat, 2019-01-05, Unto Sten wrote:
[...]
 
> feature is inexpensive if you don't want to use it - even if you
> don't use it, you need to know about it, and this is not
> cost-free.
 
Completely agree.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 01 05:57AM -0800

> wrong? As a check, I used the same approach for the standard
> birthday problem, and I do indeed get the textbook answer of 23 for
> that one.
 
[code snipped]
 
An interesting problem.
 
Your approach uses a Monte Carlo technique. This isn't
necessary. The problem can be solved nicely using a dynamic
programming approach. To start off:
 
With zero people in the room, the probability of zero
shared birthdays and zero unshared birthdays is 100%.
 
With one person in the room, the probability of zero
shared birthdays and one unshared birthday is 100%
 
With two people in the room, the probabilty of one
shared birthday and no unshared birthdays is 1/365,
and the probability of no shared birthdays and two
unshared birthdays is 364/365.
 
... and so forth ...
 
The idea is to add one more person at each step, calculating the
probabilities of all the possible configurations for that number
of people, having calculated the probabilities for all possible
configurations for smaller numbers of people previously. (The
step for N+1 people needs only the set of probabilities for
configurations involving N people.)
 
There is a separate probability for each pair of numbers (s,u),
where s is the number of shared birthdays, and u is the number
of unshared birthdays. Clearly s+u <= 365 (although coding it
I used an array dimensioned [366][366], not trying to be too
clever about saving space).
 
Give it a try! After you get that working, you might think
about extending the program to account for leap-days, which
yields some (to me) unexpected results.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 28 09:13PM -0800

On 2/27/2019 2:25 AM, Bonita Montero wrote:
> the condvar would be used only in contention cases and when that happens
> there would be kernel-calls which are a lot slower the additional over-
> head over raw semaphores (and eventually events).
 
Agreed.
 
 
> But I think it's more elegant because more minimalistic when you realize
> that with the system facilities and have more than one implementation of
> the rw-mutex.
 
Using system specific primitives is going to, or really should be "more"
efficient than emulating them with mutex/condvar. However, a 100% pure
c++11 implementation would allow the algorihtm to be exposed to
different architectures and operating systems: A fairly decent trade-off?
 
Your algorihtm reminds me of mine, but in a different sort of way. I am
wondering about what would happen to your algorihtm if it were to
alternate reader and writer preference at random in the Unlock function.
It should work and create different interesting testing results wrt
reads and writes performed in a fixed amount of time.
 
Actually, std::shared_mutex should beat our algorithms, but on my end,
ours both beat it out. Oh well... ;^)
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 28 10:15PM -0800

On 2/27/2019 2:25 AM, Bonita Montero wrote:
> But I think it's more elegant because more minimalistic when you realize
> that with the system facilities and have more than one implementation of
> the rw-mutex.
 
Actually, you can remove the loop in Lock and use fetch_add, or
InterlockedExchangeAdd. Recursive locking aside, your Lock function CAS
loop can be reduced down to:
___________________________
void SharedMutex::Lock()
{
if (InterlockedExchangeAdd(&m_lRWCounters, 1) != 0)
{
WaitForSingleObject(m_hEvtReleaseWriter, INFINITE);
}
}
___________________________
 
Now, this really reminds me of my algorihtm. :^)
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 28 10:21PM -0800

On 2/28/2019 10:15 PM, Chris M. Thomasson wrote:
> }
> ___________________________
 
> Now, this really reminds me of my algorihtm. :^)
 
Fwiw, this type of discussion brings me back to the good ol' days in
comp.programming.threads. Before c++ officially recognized these types
of things in the standard...
Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 28 11:55AM -0800

> Under Cygwin, which uses a different library implementation, the
> problem doesn't occur with g++ (though it does occur with clang++).
 
> I'll submit a bug report.
 
I think the problem is not in the library headers but in the
translators themselves. After doing a bit of detective work,
I found that these commands
 
g++ -x c++ -std=c++11 -pedantic -U_GNU_SOURCE m-pi.c -o g++-m-pi
clang-5.0 -x c++ -std=c++11 -pedantic -U_GNU_SOURCE m-pi.c -o clang-m-pi
 
will compile the source without complaint, and produce
executables that behave as expected, but if the -U_GNU_SOURCE
option is left off then there are compilation errors, like what
you reported. (Which version of C++ standard is used seems not
to matter. The environment is a ubuntu 16.04 distribution.)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)