Thu Dec 12 11:38:16 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2016-11-01

LEARN

2024-12-12 | 2024-11-12 | 2024-10-12 | 2024-09-12 | 2024-08-12 | 2024-07-12 | 2024-06-12 | 2024-05-12 | 2024-04-12 | 2024-03-12 | 2024-02-12 | 2024-01-12 | 2023-12-12 | 2023-11-12 | 2023-10-12 | 2023-09-12 | 2023-08-12 | 2023-07-12 | 2023-06-12 | 2023-05-12 | 2023-04-12 | 2023-03-12 | 2023-02-12 | 2023-01-12 | 2022-12-12 | 2022-11-12 | 2022-10-12 | 2022-09-12 | 2022-08-12 | 2022-07-12 | 2022-06-12 | 2022-05-12 | 2022-04-12 | 2022-03-12 | 2022-02-12 | 2022-01-12 | 2021-12-12 | 2021-11-12 | 2021-10-12 | 2021-09-12 | 2021-08-12 | 2021-07-12 | 2021-06-12 | 2021-05-12 | 2021-04-12 | 2021-03-12 | 2021-02-12 | 2021-01-12 | 2020-12-12 | 2020-11-12 | 2020-10-12 | 2020-09-12 | 2020-08-12 | 2020-07-12 | 2020-06-12 | 2020-05-12 | 2020-04-12 | 2020-03-12 | 2020-02-12 | 2020-01-12 | 2019-12-12 | 2019-11-12 | 2019-10-12 | 2019-09-12 | 2019-08-12 | 2019-07-12 | 2019-06-12 | 2019-05-12 | 2019-04-12 | 2019-03-12 | 2019-02-12 | 2019-01-12 | 2018-12-12 | 2018-11-12 | 2018-10-12 | 2018-09-12 | 2018-08-12 | 2018-07-12 | 2018-06-12 | 2018-05-12 | 2018-04-12 | 2018-03-12 | 2018-02-12 | 2018-01-12 | 2017-12-12 | 2017-11-12 | 2017-10-12 | 2017-09-12 | 2017-08-12 | 2017-07-12 | 2017-06-12 | 2017-05-12 | 2017-04-12 | 2017-03-12 | 2017-02-12 | 2017-01-12 | 2016-12-12 | 2016-11-12 | 2016-10-12 | 2016-09-12 | 2016-08-12 | 2016-07-12 | 2016-06-12 | 2016-05-12 | 2016-04-12 | 2016-03-12 | 2016-02-12 | 2016-01-12 | 2015-12-12 | 2015-11-12 | 2015-10-12 | 2015-09-12 | 2015-08-12 | 2015-07-12 | 2015-06-12 | 2015-05-12 | 2015-04-12 | 2015-03-12 | 2015-02-12 | 2015-01-12 | 2014-12-12 | 2014-11-12 | 2014-10-12

Key: Value:

Key: Value:

MESSAGE
DATE 2016-11-15
FROM ruben safir
SUBJECT Subject: [Learn] Fwd: PNG coding
From learn-bounces-at-nylxs.com Tue Nov 15 18:12:11 2016
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www.mrbrklyn.com (www.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id BAF2B161312;
Tue, 15 Nov 2016 18:12:10 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from [10.0.0.62] (flatbush.mrbrklyn.com [10.0.0.62])
by mrbrklyn.com (Postfix) with ESMTP id 6AFB7160E77
for ; Tue, 15 Nov 2016 18:12:07 -0500 (EST)
References:
<0926c75e-8ccf-4e74-9887-82396932235d-at-googlegroups.com>


<31145d76-97ae-0d80-363f-b0b2ebbaffc5-at-verizon.net>
<529b73c9-0c8c-4f30-8291-56e4d31f61e4-at-googlegroups.com>

<58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>
<20161115234903.5851f221-at-maxa-pc>
<20161115234214.3c2bf7e4-at-maxa-pc>
To: learn-at-nylxs.com
From: ruben safir
X-Forwarded-Message-Id:

<0926c75e-8ccf-4e74-9887-82396932235d-at-googlegroups.com>


<31145d76-97ae-0d80-363f-b0b2ebbaffc5-at-verizon.net>
<529b73c9-0c8c-4f30-8291-56e4d31f61e4-at-googlegroups.com>

<58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>
<20161115234903.5851f221-at-maxa-pc>
<20161115234214.3c2bf7e4-at-maxa-pc>
Message-ID: <1fb754c9-b9e6-9815-5193-6e6aeb270dcb-at-mrbrklyn.com>
Date: Tue, 15 Nov 2016 18:12:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161115234214.3c2bf7e4-at-maxa-pc>
Content-Type: multipart/mixed; boundary="------------F971B676B6E5933019CD67B7"
Subject: [Learn] Fwd: PNG coding
X-BeenThere: learn-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id:
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"

This is a multi-part message in MIME format.
--------------F971B676B6E5933019CD67B7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

hmmm

I simple struct would be a good starting point :(

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="PNG coding.eml"

Path: reader2.panix.com!panix!not-for-mail
From: ruben safir
Newsgroups: comp.lang.c
Subject: PNG coding
Date: Tue, 15 Nov 2016 14:40:04 -0500
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID:
NNTP-Posting-Host: www.mrbrklyn.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: reader2.panix.com 1479238806 4510 96.57.23.82 (15 Nov 2016 19:40:06 GMT)
X-Complaints-To: abuse-at-panix.com
NNTP-Posting-Date: Tue, 15 Nov 2016 19:40:06 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
Xref: panix comp.lang.c:1094867

Does anyone know of any sample code for reading PNG files that doesn't
include using libpng.... just straight direct access.



--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!not-for-mail
From: ruben safir
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 15:20:21 -0500
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID:
References:

NNTP-Posting-Host: www.mrbrklyn.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: reader2.panix.com 1479241221 8935 96.57.23.82 (15 Nov 2016 20:20:21 GMT)
X-Complaints-To: abuse-at-panix.com
NNTP-Posting-Date: Tue, 15 Nov 2016 20:20:21 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
In-Reply-To:
Xref: panix comp.lang.c:1094871

On 11/15/2016 03:02 PM, Rick C. Hodgin wrote:
> On Windows and with a C++ compiler, you can use the built-in
> Gdiplus::Bitmap object and load the png and then write it out
> as a standard .bmp format, which is much easier to access
> line-by-line

I can't use MS, and I'm not looking for a solution, just source code to
learn by, read and adapt.

FWIW, Rick, I wouldn't touch a slaveware MS OS if it was the last
platform on earth. I suggest strongly for you to try something else.


--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

X-Received: by 10.157.46.106 with SMTP id c39mr8674695otd.106.1479241558217;
Tue, 15 Nov 2016 12:25:58 -0800 (PST)
X-Received: by 10.157.4.119 with SMTP id 110mr1831563otc.11.1479241558180;
Tue, 15 Nov 2016 12:25:58 -0800 (PST)
Path: reader2.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!168.235.88.217.MISMATCH!feeder.erje.net!2.us.feeder.erje.net!news.ripco.com!news.glorb.com!w132no121263ita.0!news-out.google.com!c26ni415itd.0!nntp.google.com!w132no121260ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c
Date: Tue, 15 Nov 2016 12:25:57 -0800 (PST)
In-Reply-To:
Complaints-To: groups-abuse-at-google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.44.229.196;
posting-account=BcpLkAoAAACbVwkzAAKP0XXOd-MDREpp
NNTP-Posting-Host: 68.44.229.196
References:

User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0926c75e-8ccf-4e74-9887-82396932235d-at-googlegroups.com>
Subject: Re: PNG coding
From: "Rick C. Hodgin"
Injection-Date: Tue, 15 Nov 2016 20:25:58 +0000
Content-Type: text/plain; charset=UTF-8
Xref: panix comp.lang.c:1094873

On Tuesday, November 15, 2016 at 3:20:29 PM UTC-5, ruben safir wrote:
> On 11/15/2016 03:02 PM, Rick C. Hodgin wrote:
> > On Windows and with a C++ compiler, you can use the built-in
> > Gdiplus::Bitmap object and load the png and then write it out
> > as a standard .bmp format, which is much easier to access
> > line-by-line
>
> I can't use MS, and I'm not looking for a solution, just source code to
> learn by, read and adapt.
>
> FWIW, Rick, I wouldn't touch a slaveware MS OS if it was the last
> platform on earth. I suggest strongly for you to try something else.

Couldn't agree more, though I also extend the definition to include
Mac OS and Linux among others:

http://www.libsf.org/wiki/index.php/Main_Page
https://github.com/RickCHodgin/libsf/tree/master/exodus

I named it Exodus in the 1990s, about six years before I became a
Christian. It was given that name because I wanted it to be "a mass
departure from evil" which was Microsoft.

Today I am pursuing Exodus an OS/2 compatible kernel with some more
modern extensions, called ES/2.

Best regards,
Rick C. Hodgin

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "James R. Kuyper"
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 15:34:19 -0500
Organization: A noiseless patient Spider
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx02.eternal-september.org; posting-host="de2b9cf661b11c67a4716a5ec8a7fe30";
logging-data="27585"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1+CQfV3knADvJVrZrYeGLRbBWC7K/HJyWk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
In-Reply-To:
Cancel-Lock: sha1:N/Th+6PQMye+kEl8N1DlwBAnDlg=
Xref: panix comp.lang.c:1094875

On 11/15/2016 02:40 PM, ruben safir wrote:
> Does anyone know of any sample code for reading PNG files that doesn't
> include using libpng.... just straight direct access.

How about looking at libpng itself? It is the official reference
implementation for PNG, and the source code is available under a
permissive free software license. I'd think you'd learn at least as much
by looking at the code for the official reference implementation as
you'd learn by looking at any other code.


--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!not-for-mail
From: Popping mad
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 20:57:07 +0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID:
References:

NNTP-Posting-Host: www.mrbrklyn.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: reader2.panix.com 1479243427 20608 96.57.23.82 (15 Nov 2016 20:57:07 GMT)
X-Complaints-To: abuse-at-panix.com
NNTP-Posting-Date: Tue, 15 Nov 2016 20:57:07 +0000 (UTC)
User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT b8fc14e
git.gnome.org/git/pan2)
Xref: panix comp.lang.c:1094877

On Tue, 15 Nov 2016 15:34:19 -0500, James R. Kuyper wrote:

> How about looking at libpng itself?

because after 15 years they suddenly broke half my images with their bug
update and I specifically need to work around it to fix my images, not
through it.

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!168.235.88.217.MISMATCH!2.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!news.unit0.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "James R. Kuyper"
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 16:12:15 -0500
Organization: A noiseless patient Spider
Message-ID: <31145d76-97ae-0d80-363f-b0b2ebbaffc5-at-verizon.net>
References:


Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx02.eternal-september.org; posting-host="de2b9cf661b11c67a4716a5ec8a7fe30";
logging-data="3992"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX181gQkjqI79eHiifEUqaoTDh8WDbXHWv04="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
In-Reply-To:
Cancel-Lock: sha1:6+wMfsNtwUOd7wG43Eb9qdtdtxs=
Xref: panix comp.lang.c:1094879

On 11/15/2016 03:57 PM, Popping mad wrote:
> On Tue, 15 Nov 2016 15:34:19 -0500, James R. Kuyper wrote:
>
>> How about looking at libpng itself?
>
> because after 15 years they suddenly broke half my images with their bug
> update and I specifically need to work around it to fix my images, not
> through it.

Reading the source code might be the easiest way to figure out how to
work around it.

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

X-Received: by 10.99.155.9 with SMTP id r9mr1239677pgd.127.1479247255664;
Tue, 15 Nov 2016 14:00:55 -0800 (PST)
X-Received: by 10.157.56.132 with SMTP id p4mr1893848otc.20.1479247255593;
Tue, 15 Nov 2016 14:00:55 -0800 (PST)
Path: reader2.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!168.235.88.217.MISMATCH!feeder.erje.net!2.us.feeder.erje.net!news.ripco.com!news.glorb.com!o1no3018ito.0!news-out.google.com!c26ni20itd.0!nntp.google.com!o1no3009ito.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c
Date: Tue, 15 Nov 2016 14:00:55 -0800 (PST)
In-Reply-To:
Complaints-To: groups-abuse-at-google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2001:480:240:0:0:0:0:2;
posting-account=rH_E3woAAADR_9M5Q9bWAyDPjAMcf7LJ
NNTP-Posting-Host: 2001:480:240:0:0:0:0:2
References:

User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <529b73c9-0c8c-4f30-8291-56e4d31f61e4-at-googlegroups.com>
Subject: Re: PNG coding
From: jadill33-at-gmail.com
Injection-Date: Tue, 15 Nov 2016 22:00:55 +0000
Content-Type: text/plain; charset=UTF-8
Xref: panix comp.lang.c:1094892

On Tuesday, November 15, 2016 at 3:57:17 PM UTC-5, Popping mad wrote:
> On Tue, 15 Nov 2016 15:34:19 -0500, James R. Kuyper wrote:
>
> > How about looking at libpng itself?
>
> because after 15 years they suddenly broke half my images with their bug
> update and I specifically need to work around it to fix my images, not
> through it.

One option is to use a tool like Beyond Compare to compare the source trees
of the two versions of libpng to try to isolate the file change(s) that
caused your problem. If the versions are not too far apart (so that there
are not many large file differences), you may be able to merge the new file
versions from the new libpng into the old libpng and try to rebuild
incrementally to eliminate file changes that do not affect your images.

An alternative is that you can do the same in Subversion/git or other source
control program to visualize the differences. Commit the newest version of
libpng that works with your images to a repo, then copy over files from the
new version of libpng one at a time until you hack a version that works for
you.

You can also try contacting a libpng developer and if you have a couple
sample images that demonstrate the problem that you're able to share, they
may be considerate enough to do this analysis for you.

I've experienced something similar myself when I need to migrate Wireshark
plugin code to new major versions (e.g. 1.10->1.12->2.0->2.2) as the API
changes can be somewhat significant.

Best regards,
John D.

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!goblin2!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Heathfield
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 21:45:21 +0000
Organization: Fix this later
Message-ID:
References:

Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 15 Nov 2016 21:44:50 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="5aa817f98dde6e19527f193bb7e85bbb";
logging-data="12567"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX186CDciL9uz0wnxOnOK6AASd9y2b8PdEzlpiH/aHBotuw=="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
In-Reply-To:
Cancel-Lock: sha1:vCTFmHElt84jkAbxuGg3K+ApIXc=
Xref: panix comp.lang.c:1094886

On 15/11/16 20:34, James R. Kuyper wrote:
> On 11/15/2016 02:40 PM, ruben safir wrote:
>> Does anyone know of any sample code for reading PNG files that doesn't
>> include using libpng.... just straight direct access.
>
> How about looking at libpng itself? It is the official reference
> implementation for PNG, and the source code is available under a
> permissive free software license. I'd think you'd learn at least as much
> by looking at the code for the official reference implementation as
> you'd learn by looking at any other code.

Just to encourage people to take James up on his suggestion, here are
some statistics from the libpng code.

Firstly, there'd better be LOTS of it. We want to learn a lot, don't we?

C files: 17
H files: 6

That looks promising, but not too impressive. Maybe we'd better count
lines instead:

Lines of C: 33593
Lines of H: 6791

Ah, that's better! But how much does it all *weigh*?

Kilobytes of C: 1116
Kilobytes of H: 304

Ah, that's very reassuring. Over a megabyte of C code. Let's remind
ourselves what we're doing: reading a PNG into memory, or writing it
out. Okay, a megabyte (of *source*) seems perfectly reasonable for that.

Now, we all know that there's nothing like the pre-processor for making
code readable, so let's hope they use the pre-processor a *lot*:

Number of lines of H starting #: 1667
Number of lines of C starting #: 2223

Yep, excellent.

Disappointingly, they supply a file, example.c, that shows you how to
use the library. You'd have thought you'd learn more from reading the
whole of the library code line by line in order to understand how to
call it.

But they redeem themselves in a most unexpected manner --- example.c
/does not compile/! And it's not supposed to. There's a comment to that
effect:

"This file does not currently compile, because it is missing certain
parts, like allocating memory to hold an image. You will have to supply
these parts to get it to compile."

They refer the interested reader, instead, to a 2000+ line test program,
which I presume was originally developed as an IOCCC entry. The main()
function calls a function named test_one_file(), which sounds quite a
promising place to start. Let's take a look at it:

/* Test one file */
static int
test_one_file(PNG_CONST char *inname, PNG_CONST char *outname)
{
static png_FILE_p fpin;
static png_FILE_p fpout; /* "static" prevents setjmp corruption */
pngtest_error_parameters error_parameters;
png_structp read_ptr;
png_infop read_info_ptr, end_info_ptr;
#ifdef PNG_WRITE_SUPPORTED
png_structp write_ptr;
png_infop write_info_ptr;
png_infop write_end_info_ptr;
#ifdef PNG_WRITE_FILTER_SUPPORTED
int interlace_preserved = 1;
#endif /* WRITE_FILTER */
#else /* !WRITE */
png_structp write_ptr = NULL;


Actually, since it's about 900 lines long, I don't think I'll show any
more of it. It's obviously all quite self-explanatory, and you won't
need any help at all in understanding it completely. Five minutes should
do it. Maybe ten if you're having a bad day. For the whole library?
Perhaps an hour. After all, it's only 40,000 lines.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "James R. Kuyper"
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 17:15:55 -0500
Organization: A noiseless patient Spider
Message-ID: <58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>
References:


Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx02.eternal-september.org; posting-host="de2b9cf661b11c67a4716a5ec8a7fe30";
logging-data="19856"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX19Tv2XiPMojeSBLI0WT9SAIq3NRihtZk7Y="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
In-Reply-To:
Cancel-Lock: sha1:2o959Bce0c+ZbPzLIaNC1idXxQ4=
Xref: panix comp.lang.c:1094895

On 11/15/2016 04:45 PM, Richard Heathfield wrote:
> On 15/11/16 20:34, James R. Kuyper wrote:
>> On 11/15/2016 02:40 PM, ruben safir wrote:
>>> Does anyone know of any sample code for reading PNG files that doesn't
>>> include using libpng.... just straight direct access.
>>
>> How about looking at libpng itself? It is the official reference
>> implementation for PNG, and the source code is available under a
>> permissive free software license. I'd think you'd learn at least as much
>> by looking at the code for the official reference implementation as
>> you'd learn by looking at any other code.
>
> Just to encourage people to take James up on his suggestion, here are
> some statistics from the libpng code.
...
> Ah, that's very reassuring. Over a megabyte of C code. Let's remind
> ourselves what we're doing: reading a PNG into memory, or writing it
> out. Okay, a megabyte (of *source*) seems perfectly reasonable for that.

With you, it's sometimes hard to tell, but I'm going to assume you're
being sarcastic.

Keep in mind that this is the official reference implementation of PNG.
Any fully functional alternative to libpng is likely to be comparably
complicated - unless the implementors of libpng are exceptionally
incompetent. I know nothing about that personally, but it seems unlikely
that PNG would be as popular as it is if that were the case.

Would a less-than-fully-functional alternative be acceptable? In that
case, such an alternative could be a lot simpler - but that depends upon
which features of PNG ruben needs to handle correctly.


--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Heathfield
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 22:41:23 +0000
Organization: Fix this later
Message-ID:
References:


<58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 15 Nov 2016 22:40:52 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="5aa817f98dde6e19527f193bb7e85bbb";
logging-data="25540"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1+VWrJmpLJljsPfPUBHYgaTcdnU2x/8SGF083E5NSNotw=="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
In-Reply-To: <58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>
Cancel-Lock: sha1:uBx7ipwAF2ofWMjcMOqtuJveb+A=
Xref: panix comp.lang.c:1094896

On 15/11/16 22:15, James R. Kuyper wrote:
> On 11/15/2016 04:45 PM, Richard Heathfield wrote:
>> On 15/11/16 20:34, James R. Kuyper wrote:
>>> On 11/15/2016 02:40 PM, ruben safir wrote:
>>>> Does anyone know of any sample code for reading PNG files that doesn't
>>>> include using libpng.... just straight direct access.
>>>
>>> How about looking at libpng itself? It is the official reference
>>> implementation for PNG, and the source code is available under a
>>> permissive free software license. I'd think you'd learn at least as much
>>> by looking at the code for the official reference implementation as
>>> you'd learn by looking at any other code.
>>
>> Just to encourage people to take James up on his suggestion, here are
>> some statistics from the libpng code.
> ...
>> Ah, that's very reassuring. Over a megabyte of C code. Let's remind
>> ourselves what we're doing: reading a PNG into memory, or writing it
>> out. Okay, a megabyte (of *source*) seems perfectly reasonable for that.
>
> With you, it's sometimes hard to tell,

Good. :-)

> but I'm going to assume you're being sarcastic.

On this occasion, you have correctly divined my intent.

> Keep in mind that this is the official reference implementation of PNG.
> Any fully functional alternative to libpng is likely to be comparably
> complicated - unless the implementors of libpng are exceptionally
> incompetent. I know nothing about that personally, but it seems unlikely
> that PNG would be as popular as it is if that were the case.

I don't think for a moment that they're incompetent. But readable code
clearly is not their priority.

>
> Would a less-than-fully-functional alternative be acceptable?

Hell yes!

> In that
> case, such an alternative could be a lot simpler - but that depends upon
> which features of PNG ruben needs to handle correctly.

I can't speak for Ruben's needs. But if anyone is planning to write a
simple PNG library, I would recommend the following interface:

/* returns width*height unsigned longs, encoding RGBA 00-FF */
unsigned long *png_load(const char *filename,
size_t *width,
size_t *height);

int png_save(const char filename,
unsigned long *frame,
size_t width,
size_t height);

And *nothing else*!

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!168.235.88.217.MISMATCH!2.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail
From: Melzzzzz
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 23:49:03 +0100
Organization: albasani.net
Message-ID: <20161115234903.5851f221-at-maxa-pc>
References:


<58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>

Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net A5EQeyuQ/4lyLSflSXcR/Vo8RvndWcKLGv2xy0FDVgm7DAeK75CGqLcSw397tCOP4lP75/bJE34O6TSkhFGToQ==
NNTP-Posting-Date: Tue, 15 Nov 2016 22:49:03 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="KnZMwYx+R2Js3XWERbh+PuAdxZUPOLwxKL+oWH//r98XEJ9HwMIzlWGWsRWhpbErjGxLnlDQzrCuulQEnGOlWguGLBidoJEUjIpbM0sfpkYhk+rNgeF7fr12GSxSplNb"; mail-complaints-to="abuse-at-albasani.net"
X-Newsreader: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu)
Cancel-Lock: sha1:SfoWz+6H8L84tX5CWtzLA1qzjJI=
Xref: panix comp.lang.c:1094898

On Tue, 15 Nov 2016 22:41:23 +0000
Richard Heathfield wrote:


>
> I can't speak for Ruben's needs. But if anyone is planning to write a
> simple PNG library, I would recommend the following interface:
>
> /* returns width*height unsigned longs, encoding RGBA 00-FF */
> unsigned long *png_load(const char *filename,
> size_t *width,
> size_t *height);
>
> int png_save(const char filename,
> unsigned long *frame,
> size_t width,
> size_t height);
>
> And *nothing else*!
>
Well, one can write wrapper around libpng, possibly C++ ;)


--
press any key to continue or any other to quit

--------------F971B676B6E5933019CD67B7
Content-Type: message/rfc822;
name="Re: PNG coding.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: PNG coding.eml"

Path: reader2.panix.com!panix!goblin3!goblin1!goblin.stu.neva.ru!news.albasani.net!.POSTED!not-for-mail
From: Melzzzzz
Newsgroups: comp.lang.c
Subject: Re: PNG coding
Date: Tue, 15 Nov 2016 23:42:14 +0100
Organization: albasani.net
Message-ID: <20161115234214.3c2bf7e4-at-maxa-pc>
References:


<58044c2b-c4d4-cfd7-7142-2b5ca73a6c28-at-verizon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Trace: news.albasani.net VlgqHu+wXj+N/gKf5tsGFbgUWt0o9qUN81wJ+DbUAXvTm0Hij0ROCzQRJCeuVE79/kKvE5a1D84KLnkFzOQu8Q==
NNTP-Posting-Date: Tue, 15 Nov 2016 22:42:14 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="ynNEA4HYPc6CwYPy9aWxkp2kdGQ1w1oGyglOQgaGf8+rLgelOPCpyeq+BWhqjw/E3JYWBeQRordH2ObsnQZ9F7N2kNA5F7zmFboIvVtcTcDgPUUB8/UkdgdXgpU4Y0EO"; mail-complaints-to="abuse-at-albasani.net"
X-Newsreader: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu)
Cancel-Lock: sha1:OBdBTJM32fPZCk+HYJ1u5zQpSCo=
Xref: panix comp.lang.c:1094897

On Tue, 15 Nov 2016 17:15:55 -0500
"James R. Kuyper" wrote:

> On 11/15/2016 04:45 PM, Richard Heathfield wrote:
> > On 15/11/16 20:34, James R. Kuyper wrote: =20
> >> On 11/15/2016 02:40 PM, ruben safir wrote: =20
> >>> Does anyone know of any sample code for reading PNG files that
> >>> doesn't include using libpng.... just straight direct access. =20
> >>
> >> How about looking at libpng itself? It is the official reference
> >> implementation for PNG, and the source code is available under a
> >> permissive free software license. I'd think you'd learn at least
> >> as much by looking at the code for the official reference
> >> implementation as you'd learn by looking at any other code. =20
> >
> > Just to encourage people to take James up on his suggestion, here
> > are some statistics from the libpng code. =20
> ...
> > Ah, that's very reassuring. Over a megabyte of C code. Let's remind
> > ourselves what we're doing: reading a PNG into memory, or writing it
> > out. Okay, a megabyte (of *source*) seems perfectly reasonable for
> > that. =20
>=20
> With you, it's sometimes hard to tell, but I'm going to assume you're=20
> being sarcastic.
>=20
> Keep in mind that this is the official reference implementation of
> PNG. Any fully functional alternative to libpng is likely to be
> comparably complicated - unless the implementors of libpng are
> exceptionally incompetent. I know nothing about that personally, but
> it seems unlikely that PNG would be as popular as it is if that were
> the case.
>=20
> Would a less-than-fully-functional alternative be acceptable? In that=20
> case, such an alternative could be a lot simpler - but that depends
> upon which features of PNG ruben needs to handle correctly.
>=20

Well, how about Golang implementation?
[bmaxa-at-maxa-pc png]$ ls -l
total 28
drwxr-xr-x 3 bmaxa users 15 14.07.2015 20:01 testdata/
-rw-r--r-- 1 bmaxa users 3685 24.09.2016 02:52 example_test.go
-rw-r--r-- 1 bmaxa users 1768 11.12.2014 20:19 paeth.go
-rw-r--r-- 1 bmaxa users 2252 11.12.2014 20:19 paeth_test.go
-rw-r--r-- 1 bmaxa users 25588 28.10.2016 16:47 reader.go
-rw-r--r-- 1 bmaxa users 17597 28.10.2016 16:47 reader_test.go
-rw-r--r-- 1 bmaxa users 12530 01.10.2016 00:01 writer.go
-rw-r--r-- 1 bmaxa users 4670 11.12.2014 20:19 writer_test.go

reader/writer_test are bunch of golang routines to test every aspect of
library.
This is example decode:

func ExampleDecode() {
// This example uses png.Decode which can only decode PNG images.
// Consider using the general image.Decode as it can sniff and deco=
de any registered image format.
img, err :=3D png.Decode(gopherPNG())
if err !=3D nil {
log.Fatal(err)
}

levels :=3D []string{" ", "=E2=96=91", "=E2=96=92", "=E2=96=93", "=
=E2=96=88"}

for y :=3D img.Bounds().Min.Y; y < img.Bounds().Max.Y; y++ {
for x :=3D img.Bounds().Min.X; x < img.Bounds().Max.X; x++ {
c :=3D color.GrayModel.Convert(img.At(x, y)).(color=
.Gray)
level :=3D c.Y / 51 // 51 * 5 =3D 255
if level =3D=3D 5 {
level--
}
fmt.Print(levels[level])
}
fmt.Print("\n")
}
}

--=20
press any key to continue or any other to quit


--------------F971B676B6E5933019CD67B7
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Learn mailing list
Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn

--------------F971B676B6E5933019CD67B7--

  1. 2016-11-01 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] how is it indexing in cuda
  2. 2016-11-01 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] not adequately speced of explained
  3. 2016-11-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] how is it indexing in cuda
  4. 2016-11-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] not adequately speced of explained
  5. 2016-11-02 Christopher League <league-at-contrapunctus.net> Re: [Learn] Fitch Algorithm - C++
  6. 2016-11-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  7. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] how is it indexing in cuda
  8. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fitch Algorithm - C++
  9. 2016-11-02 IEEE Computer Society <csconnection-at-computer.org> Subject: [Learn] Hear Google's John Martinis Take on Quantum Computing at
  10. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] opencl
  11. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] scheduled for tommorw
  12. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] threads tutorial
  13. 2016-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  14. 2016-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  15. 2016-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  16. 2016-11-03 Christopher League <league-at-contrapunctus.net> Re: [Learn] huffman code
  17. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] huffman code
  18. 2016-11-03 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] huffman code
  19. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fitch algorithm from the beginning
  20. 2016-11-03 From: <mrbrklyn-at-panix.com> Subject: [Learn] huffman code
  21. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Phenology meeting
  22. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] relevant hackathon
  23. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] relevant hackathon
  24. 2016-11-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] huffman code
  25. 2016-11-04 Christopher League <league-at-contrapunctus.net> Subject: [Learn] Fitch/Sankoff
  26. 2016-11-05 Christopher League <league-at-contrapunctus.net> Re: [Learn] Fwd: templates within templates
  27. 2016-11-05 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: const T vs T const
  28. 2016-11-05 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Template Library files and Header linking troubles
  29. 2016-11-05 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: templates within templates
  30. 2016-11-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fwd: templates within templates
  31. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: templates within templates
  32. 2016-11-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fwd: templates within templates
  33. 2016-11-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] Fwd: templates within templates
  34. 2016-11-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fwd: templates within templates
  35. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: templates within templates
  36. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: templates within templates
  37. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] GNU Parallel 20161022 ('Matthew') released [stable]
  38. 2016-11-07 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] templates and ostream for future reference
  39. 2016-11-08 Christopher League <league-at-contrapunctus.net> Re: [Learn] C++ signature ambiguity
  40. 2016-11-08 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] C++ signature ambiguity
  41. 2016-11-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ signature ambiguity
  42. 2016-11-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Invitation: Phylogeny meeting -at- Weekly from 10:15 to
  43. 2016-11-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] Fwd: [nylug-talk] RSVP open: Wed Nov 16,
  44. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  45. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort parallel hw
  46. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort parallel hw
  47. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  48. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] mergesort tutorial
  49. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] mergesort tutorial
  50. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] namespace and external files confusion
  51. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] namespace and external files confusion
  52. 2016-11-09 From: "Carlos R. Mafra" <crmafra-at-gmail.com> Re: [Learn] Question about a small change
  53. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] =?utf-8?q?C++_call_of_overloaded_=E2=80=98track=28int*=26?=
  54. 2016-11-09 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: lost arguments
  55. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Dating origins of dinosaurs,
  56. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] merge sort parallel hw
  57. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] mergesort tutorial
  58. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] namespace and external files confusion
  59. 2016-11-10 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  60. 2016-11-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] merge sort parallel hw
  61. 2016-11-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] merge sort parallel hw
  62. 2016-11-10 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] merge sort parallel hw
  63. 2016-11-10 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] [Hangout-NYLXS] mergesort tutorial
  64. 2016-11-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] Fwd: [Hangout-NYLXS] ease your mind- everything in the
  65. 2016-11-10 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: [Hangout-NYLXS] R Programming Workshop
  66. 2016-11-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Paleocast phenogenetic tree building
  67. 2016-11-11 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  68. 2016-11-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] HW of mergesort in parallel
  69. 2016-11-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] merge sort in parallel assignment
  70. 2016-11-14 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort in parallel assignment
  71. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort in parallel assignment
  72. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort parallel hw
  73. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] CUDA and video
  74. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] PNG Graphic formats and CRCs
  75. 2016-11-15 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: PNG coding
  76. 2016-11-15 ruben safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: PNG Coding
  77. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: lost arguments
  78. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] relevant hackathon
  79. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ Workshop Announcement
  80. 2016-11-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] Fwd: Re: ref use
  81. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] ref use
  82. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] why use a reference wrapper int his example
  83. 2016-11-17 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] [Hangout-NYLXS] at K&R now
  84. 2016-11-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [Hangout-NYLXS] Fwd: PNG Coding
  85. 2016-11-18 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ workshop and usenet responses
  86. 2016-11-19 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ref use
  87. 2016-11-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] when is the constructor called for an object
  88. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: creating a binary tree
  89. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: hidden static
  90. 2016-11-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ISBI 2017 Call for Abstracts and Non-Author
  91. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: PNG coding
  92. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: the new {} syntax
  93. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: when is the constructor called for an object
  94. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: when is the constructor called for an object
  95. 2016-11-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Eoconfuciusornis feather keratin and
  96. 2016-11-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] look what I found
  97. 2016-11-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Cuccuency book
  98. 2016-11-22 ruben safir <ruben.safir-at-my.liu.edu> Subject: [Learn] declare a func or call an object
  99. 2016-11-22 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: Re: Using CLIPS as a library
  100. 2016-11-23 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: Simple C++11 Wrapper for CLIPS 6.30
  101. 2016-11-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Parrelel Programming HW2 with maxpath
  102. 2016-11-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] great research news for big data
  103. 2016-11-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] mapping algorithms
  104. 2016-11-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Todays meeting
  105. 2016-11-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Flightless theropod phylogenetic variation
  106. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Note to self for Thursday
  107. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fitch etc
  108. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Note to self for Thursday
  109. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] operator<<() overloading details and friend
  110. 2016-11-27 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] 130 year old feathers analysis
  111. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ACM/SPEC ICPE 2017 - Call for Tutorial Proposals
  112. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ACM/SPEC ICPE 2017 - Call for Workshop Proposals
  113. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: CfP 22nd Conf. Reliable Software Technologies,
  114. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Seeking contributors for psyche-c
  115. 2016-11-29 Christopher League <league-at-contrapunctus.net> Re: [Learn] Look at this exciting output by my test program
  116. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Look at this exciting output by my test program
  117. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Look at this exciting output by my test program
  118. 2016-11-29 Christopher League <league-at-contrapunctus.net> Re: [Learn] Quantum Entanglement
  119. 2016-11-29 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Quantum Entanglement
  120. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Here is the paper I was talking out
  121. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Look at this exciting output by my test program
  122. 2016-11-29 nylxs <mrbrklyn-at-optonline.net> Subject: [Learn] Look at this exciting output by my test program
  123. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Quantum Entanglement
  124. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] The Death of PBS
  125. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] witmer lab ohio and 3d imaging
  126. 2016-11-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] phylogenetic crawler

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!