Friday, April 29, 2016

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

red floyd <no.spam.here@its.invalid>: Apr 19 10:38PM -0700

On 4/19/2016 7:09 AM, Scott Lurndal wrote:
> and useful addressing modes.
 
>> they were on the inside. Possibly put off by PIP and STAT commands. :(
 
> Should have used UnixV6 instead of RSX-11M/RSTS-E.
 
The TI 34010 Graphics processor communicated with the host CPU via
memory mapped registers. You'd load the address register with the
address in 34010 memory space, and then write to the data register.
Successive writes would increment the address register, so that you
could load graphics data by successive writes to the data register.
"Chris M. Thomasson" <nospam@nospam.no>: Apr 29 03:45PM -0700

FWIW, some, IMHO, fairly interesting C++ code for Field Based DLA:
 
https://plus.google.com/101799841244447089430/posts/am5EpMHcmig
 
https://github.com/ChrisMThomasson/CT_fieldDLA
 
https://en.wikipedia.org/wiki/Diffusion-limited_aggregation
 
that can be heavily multithreaded!
 
the code as is, creates the following rendering:
 
https://plus.google.com/101799841244447089430/posts/DfjAJbbdLGp
 
Four C++ files, that use the Cairo graphics lib along with the GLM library:
 
http://cairographics.org/
 
http://glm.g-truc.net/0.9.7/index.html
 
No need to follow random walks, follow field lines for DLA?
 
C++ seems like a _very_ nice place to implement this.
 
:^)
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:40AM -0400

On 4/29/2016 1:20 AM, Öö Tiib wrote:
> defines object or library file formats or application binary interfaces
> so they can. You however very verbosely keep failing to give examples of
> users of that freedom in Unix land.
 
And you can keep demanding all you want. One of these days, I might be
talking to one of my past clients and get the details. I don't remember
what every client I ever worked with runs.
 
But it's not important enough to me to bug them with trivial questions.
 
However, everyone else here seems to claim that ar is required to build
.a files, and all .o files are the same format. It shows just how
limited your experience is.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:42AM -0400

On 4/29/2016 4:14 AM, Ian Collins wrote:
>> it wasn't gcc. However, it's not important enough for me to give a damn.
 
> So as usual you can't back up your nonsensical claims. Why do you
> bother posting bollocks? I guess you don't give a damn.
 
Nope, it's just not important enough for me to try to teach a pig to
sing. Your comments prove the extent of your ignorance.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:43AM -0400

On 4/29/2016 8:46 AM, Scott Lurndal wrote:
>> the educational world. Not even AT&T was using it very much for production.
 
> Interesting, indeed, as I was working for a University on
> a PDP-11/34 writing unix drivers for test hardware.
 
Let's see. You were working for a University. I said they were used in
the educational world. I guess to you a University is not part of the
educational world.
 
I guess you never learned comprehension at your "university".
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Öö Tiib" <ootiib@hot.ee>: Apr 29 08:44AM -0700

On Friday, 29 April 2016 17:41:06 UTC+3, Jerry Stuckle wrote:
> talking to one of my past clients and get the details. I don't remember
> what every client I ever worked with runs.
 
> But it's not important enough to me to bug them with trivial questions.
 
I do not demand. I say that it leaves your assertions bald and empty
denial of reality.
 
 
> However, everyone else here seems to claim that ar is required to build
> .a files, and all .o files are the same format. It shows just how
> limited your experience is.
 
You are moving goalposts here. Others claim that with advent of portable
operating systems some object file formats have been defined and used
on different kinds of systems. The formats are not used because someone
requires that. Formats are used because everybody wants to achieve
compatibility with others. Who does not falls out of pack and loses.
 
No one is required to make say .zip files using a PKZIP program and if
they use something else they are still not required to produce ZIP
format specified by ISO/IEC 21320-1:2015. Everybody just wants to.
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 12:23PM -0400

On 4/29/2016 11:44 AM, Öö Tiib wrote:
 
>> But it's not important enough to me to bug them with trivial questions.
 
> I do not demand. I say that it leaves your assertions bald and empty
> denial of reality.
 
And what you think is of absolutely no importance to me.
 
> on different kinds of systems. The formats are not used because someone
> requires that. Formats are used because everybody wants to achieve
> compatibility with others. Who does not falls out of pack and loses.
 
No, I have moved no goalposts. My statements have been consistent since
the start. Just because your limited experience hasn't exposed you to
other options does not mean they don't exist.
 
> No one is required to make say .zip files using a PKZIP program and if
> they use something else they are still not required to produce ZIP
> format specified by ISO/IEC 21320-1:2015. Everybody just wants to.
 
Now who's moving the goalposts - or at least bringing up another red
herring?
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 02:28PM -0400

On 4/28/2016 5:01 PM, David Brown wrote:
> made it perfectly clear that I don't believe it can be done, and
> certainly don't know of any method. I have also made it clear that I
> will be happy to be proven wrong here.
 
Since you're completely incapable of a small challenge, here's how you
can do it:
 
file: endian.c:
===
#include <stdio.h>
 
union endian {
short s;
char c[sizeof(short)];
};
 
int main(void) {
union endian endian;
 
endian.s = 1;
if (endian.c[0])
printf("LITTLEENDIAN");
else
printf("BIGENDIAN");
return 0;
}
===
 
gcc endian.c -o endian
 
file: endiantest.c:
===
#include <stdio.h>
 
int main(void) {
 
#ifdef BIGENDIAN
printf("Big Endian defined\n");
#elif defined LITTLEENDIAN
printf("Little Endian defined\n");
#else
printf("No endian defined\n");

No comments: