Thu Nov 21 23:15:23 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-12-01

LEARN

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

Key: Value:

Key: Value:

MESSAGE
DATE 2016-12-06
FROM Christopher League
SUBJECT Re: [Learn] png data format
From learn-bounces-at-nylxs.com Tue Dec 6 09:32:48 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 337BD161313;
Tue, 6 Dec 2016 09:32:48 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from liucs.net (contrapunctus.net [174.136.110.10])
by mrbrklyn.com (Postfix) with ESMTP id 66C0B161312;
Tue, 6 Dec 2016 09:32:45 -0500 (EST)
Received: from localhost (pool-98-113-34-169.nycmny.fios.verizon.net
[98.113.34.169]) by liucs.net (Postfix) with ESMTPSA id 7AB03E096;
Tue, 6 Dec 2016 09:32:43 -0500 (EST)
From: Christopher League
To: ruben safir , Hangout ,
learn-at-nylxs.com
In-Reply-To: <87bmwpf857.fsf-at-contrapunctus.net>
References: <66105244-4afa-4330-b0c2-0661bde965fd-at-mrbrklyn.com>
<87bmwpf857.fsf-at-contrapunctus.net>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1
(x86_64-unknown-linux-gnu)
Date: Tue, 06 Dec 2016 09:32:39 -0500
Message-ID: <878trtf7qw.fsf-at-contrapunctus.net>
MIME-Version: 1.0
Subject: Re: [Learn] png data format
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: ,

Content-Type: multipart/mixed; boundary="===============0576477335=="
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"

--===============0576477335==
Content-Type: multipart/signed; boundary="===-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"

--===-=-=
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-=
Content-Type: multipart/alternative; boundary="==-=-="

--==-=-=
Content-Type: text/plain


Ah... I *can* confirm the 218103808 number now. The number you're seeing
in the dump *is* in octal: the three highest-order bytes are 000(oct)
and the low order byte is 015(oct) == 8+5 == 13(dec) == D(hex).

So the full 32-bit number in hexadecimal is 0x0000000D.

Intel architecture stores those bytes in the order 0x0D, 0x00, 0x00,
0x00.

This number, 0x0D000000 == 218103808.

The D is in column 6 (counting from zero at the right), whose
place-value is 16^6 == 16777216, and 13*16777216 == 218103808.

CL

Christopher League writes:

> I can't really confirm this based on the numbers you've given (218103808
> isn't how I think it would come out) but it sounds A LOT like an
> endianness issue. That is, the 4 bytes are stored big-endian in the
> file, but you're operating on a system (Intel) that is little-endian. So
> if you read an entire uint32 at once, it doesn't come out correctly.
> Reading one byte at a time, you can then swap the bytes into the right
> order.
>
> Also, that's not a hex dump, right...? is it octal? decimal?
>
> CL
>
> ruben safir writes:
>
>> Hello
>>
>> I'm having trouble with this imput of data from a PNG image. The
>> specification says that "chunks" have a 4 byte field that is the length
>> of the attached data segment. I tried to read the length in for a chunk
>> that has a length of 13, which was confirmed in a hexdump
>>
>> 0000000 211 120 116 107 015 012 032 012 -->>000 000 000 015<<-- 111 110
>> 104 122
>> 0000010 000 000 041 215 000 000 007 165 010 006 000 000 001 206 055 074
>> 0000020 336 000 000 000 004 147 101 115 101 000 000 261 217 013 374 141
>>
>> I am storing the data in a uint32_t variable using the following code,
>> but the value keeps showing up with a huge number 218103808 which
>> happens to be the number that is evaluated by iostream for the value of
>> the whole chunk
>>
>>
>> done reading header
>>
>>
>>
>> Sizeof Chunk 4
>> Raw Chunk Number 0: 218103808
>> ***LENGTH****
>> Length value => 218103808
>> Sizeof Byte 1
>> Character 0::
>> ^-at-
>> Byte 0::
>> 0
>> Character 1::
>> ^-at-
>> Byte 1::
>> 0
>> Character 2::
>> ^-at-
>> Byte 2::
>> 0
>> Character 3::
>> Byte 3::
>> 13
>>
>>
>> As yet, when I break it down by single bytes, it returns 0 0 0 13, which
>> is correct. ddd seems to say the same thing, and I don't know why.
>> When evaluated as 4 bytes, you get this large number, but when you
>> evaluate them seperately, each byte, it comes out right.
>>
>> The code snippet I'm using looks like this
>>
>> in the .h file #ifndef PNGPRJ
>> #define PNGPRJ
>> #include
>> namespace png_proj{
>> typedef uint32_t CHUNK;
>>
>>
>>
>> In the .cpp file
>> void Image::read_chunk()
>> {
>> char * cur = get_index();
>> CHUNK * tmp = reinterpret_cast(cur);
>> std::cout << std::endl << "Sizeof Chunk " << sizeof(*tmp) << std::endl;
>> for(int j = 0; j<4; j++){
>> std::cout << "Raw Chunk Number " << j << ": " << *tmp << std::endl;
>>
>>
>> switch ( j ) {
>> case 0:
>> std::cout << "***LENGTH****" << std::endl;
>> set_length(static_cast(*tmp));
>> std::cout << "Length value => " << static_cast(*tmp) << std::endl;
>> break;
>>
>> case 1:
>> std::cout << "***TYPE****" << std::endl;
>> set_type(static_cast(*tmp));
>> break;
>>
>> case 2:
>> {
>> std::cout << "***DATA****" << std::endl;
>> unsigned long int l = static_cast(get_length());
>> std::cout << "buffer size should be " << get_length() << std::endl;
>> int8_t * buffer = new int8_t[l];
>> std::cout << "buffer element size is " << *buffer << std::endl;
>> std::cout << "buffer size is " << l << std::endl;
>> for(unsigned int k = 0; k < get_length(); k++){
>> buffer[k] = static_cast(tmp[k]);
>> std::cout << "data " << *buffer << std::endl;
>> }
>> set_data(buffer);
>> }
>> break;
>>
>> case 3:
>> std::cout << "***CRC****" << std::endl;
>> set_crc(static_cast(*tmp));
>> break;
>>
>> default:
>> std::cout << "***NOMANDSLAND****" << std::endl;
>> break;
>> } /* ----- end switch ----- */
>>
>> char * tmp2 = reinterpret_cast(tmp); //reading each byte
>> std::cout << "Sizeof Byte " << sizeof(*tmp2) << std::endl;
>> //std::cout << "Mark ==>>" << __LINE__ << std::endl;
>> for(int i=0; i<4; i++){
>> std::cout << "Character " << i << "::" << std::endl << "\t" << *tmp2
>> << std::endl;
>> std::cout << "Byte " << i << "::" << std::endl << "\t" <<
>> static_cast(*tmp2) << std::endl;
>> tmp2++;
>> }
>> std::cout<>> std::cout<>> tmp++;
>> cur = ( reinterpret_cast(tmp) );
>> }
>> set_index(cur);
>> }
>>
>>
>>
>> I dug through libpng since this seems to not being doing what I
>> expected. They seem to set it up as 4 byte array
>>
>> void /* PRIVATE */
>> png_push_read_chunk(png_structrp png_ptr, png_inforp info_ptr)
>> {
>> png_uint_32 chunk_name;
>> #ifdef PNG_HANDLE_AS_UNKNOWN_SUPPORTED
>> int keep; /* unknown handling method */
>> #endif
>>
>> /* First we make sure we have enough data for the 4-byte chunk name
>> * and the 4-byte chunk length before proceeding with decoding the
>> * chunk data. To fully decode each of these chunks, we also make
>> * sure we have enough data in the buffer for the 4-byte CRC at the
>> * end of every chunk (except IDAT, which is handled separately).
>> */
>> if ((png_ptr->mode & PNG_HAVE_CHUNK_HEADER) == 0)
>> {
>> png_byte chunk_length[4];
>> png_byte chunk_tag[4];
>>
>> PNG_PUSH_SAVE_BUFFER_IF_LT(8)
>> png_push_fill_buffer(png_ptr, chunk_length, 4);
>> png_ptr->push_length = png_get_uint_31(png_ptr, chunk_length);
>> png_reset_crc(png_ptr);
>> png_crc_read(png_ptr, chunk_tag, 4);
>> png_ptr->chunk_name = PNG_CHUNK_FROM_STRING(chunk_tag);
>> png_check_chunk_name(png_ptr, png_ptr->chunk_name);
>> png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
>> }
>>
>>
>> I'm obviously not understanding something I'm evaluation here. So I'm
>> wondering if anyone can shed light on this.
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.h
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.cpp
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/main_png.cpp
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/makefile
>>
>> ruben
>>
>> let.me.in
>>
>>
>> Ruben
>> _______________________________________________
>> Learn mailing list
>> Learn-at-nylxs.com
>> http://lists.mrbrklyn.com/mailman/listinfo/learn

--==-=-=
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable






1.0, user-scalable=3Dyes">




Ah=E2=80=A6 I can confirm the 218103808 number now. The number =
you=E2=80=99re seeing in the dump is in octal: the three highest-o=
rder bytes are 000(oct) and the low order byte is 015(oct) =3D=3D 8+5 =3D=
=3D 13(dec) =3D=3D D(hex).


So the full 32-bit number in hexadecimal is 0x0000000D.


Intel architecture stores those bytes in the order 0x0D, 0x00, 0x00, 0x0=
0.


This number, 0x0D000000 =3D=3D 218103808.


The D is in column 6 (counting from zero at the right), whose place-valu=
e is 16^6 =3D=3D 16777216, and 13*16777216 =3D=3D 218103808.


CL


Christopher League league-at-co=
ntrapunctus.net
writes:



I can=E2=80=99t really confirm this based on the numbers you=E2=80=99ve =
given (218103808 isn=E2=80=99t how I think it would come out) but it sounds=
A LOT like an endianness issue. That is, the 4 bytes are stored big-endian=
in the file, but you=E2=80=99re operating on a system (Intel) that is litt=
le-endian. So if you read an entire uint32 at once, it doesn=E2=80=99t come=
out correctly. Reading one byte at a time, you can then swap the bytes int=
o the right order.


Also, that=E2=80=99s not a hex dump, right=E2=80=A6? is it octal? decima=
l?


CL


ruben safir ruben-at-mrbrklyn.com=
writes:



Hello


I=E2=80=99m having trouble with this imput of data from a PNG image. The=
specification says that =E2=80=9Cchunks=E2=80=9D have a 4 byte field that =
is the length of the attached data segment. I tried to read the length in f=
or a chunk that has a length of 13, which was confirmed in a hexdump


0000000 211 120 116 107 015 012 032 012 =E2=80=93>>000 000 000 015=
<<=E2=80=93 111 110 104 122 0000010 000 000 041 215 000 000 007 165 0=
10 006 000 000 001 206 055 074 0000020 336 000 000 000 004 147 101 115 101 =
000 000 261 217 013 374 141


I am storing the data in a uint32_t variable using the following code, b=
ut the value keeps showing up with a huge number 218103808 which happens to=
be the number that is evaluated by iostream for the value of the whole chu=
nk


done reading header


Sizeof Chunk 4 Raw Chunk Number 0: 218103808 LENGTHrong>* Length value =3D> 218103808 Sizeof Byte 1 Character 0:: ^-at- Byte 0=
:: 0 Character 1:: ^-at- Byte 1:: 0 Character 2:: ^-at- Byte 2:: 0 Character 3:: =
Byte 3:: 13


As yet, when I break it down by single bytes, it returns 0 0 0 13, which=
is correct. ddd seems to say the same thing, and I don=E2=80=99t know why.=
When evaluated as 4 bytes, you get this large number, but when you evaluat=
e them seperately, each byte, it comes out right.


The code snippet I=E2=80=99m using looks like this


in the .h file #ifndef PNGPRJ #define PNGPRJ #include names=
pace png_proj{ typedef uint32_t CHUNK;


In the .cpp file void Image::read_chunk() { char * cur =3D get_index(); =
CHUNK * tmp =3D reinterpret_cast(cur); std::cout << std::end=
l << =E2=80=9CSizeof Chunk=E2=80=9D << sizeof(tmp) <<=
std::endl; for(int j =3D 0; j<4; j++){ std::cout << =E2=80=9CRaw =
Chunk Number=E2=80=9D << j << =E2=80=9C:=E2=80=9D << >tmp << std::endl;


     switch ( j ) {
case 0:
std::cout << "***LENGTH****" << std::end=
l;
set_length(static_cast<int32_t>(*tmp));
std::cout << "Length value =3D> " << =
static_cast<int>(*tmp) << std::endl;
break;

case 1:=20
std::cout << "***TYPE****" << std::endl;
set_type(static_cast<int32_t>(*tmp));
break;

case 2:
{
std::cout << "***DATA****" << std::endl;
unsigned long int l =3D static_cast<unsigned long int>(g=
et_length());
std::cout << "buffer size should be " <<=
get_length() << std::endl;
int8_t * buffer =3D new int8_t[l];
std::cout << "buffer element size is " <<=
; *buffer << std::endl;
std::cout << "buffer size is " << l <=
;< std::endl;
for(unsigned int k =3D 0; k < get_length(); k++){
buffer[k] =3D static_cast<int8_t>(tmp[k]);
std::cout << "data " << *buffer <=
;< std::endl;
}
set_data(buffer);
}
break;

case 3:=20
std::cout << "***CRC****" << std::endl;
set_crc(static_cast<int32_t>(*tmp));
break;

default:=20=20=20=20
std::cout << "***NOMANDSLAND****" << std=
::endl;
break;
} /* ----- end switch ----- */

char * tmp2 =3D reinterpret_cast<char *>(tmp); //reading each by=
te
std::cout << "Sizeof Byte " << sizeof(*tmp2) &l=
t;< std::endl;
//std::cout << "Mark =3D=3D>>" << __LINE__=
<< std::endl;
for(int i=3D0; i<4; i++){
std::cout << "Character " << i << &quo=
t;::" << std::endl << "\t" << *tmp2
=

<< std::endl; std::cout << =E2=80=9CByte=E2=80=9D << i=
<< =E2=80=9C::=E2=80=9D << std::endl << =E2=80=9C=E2=80=
=9D << static_cast(*tmp2) << std::endl; tmp2=
++; } std::cout< std::cout< tmp++;
cur =3D ( reinterpret_cast(tmp) ); } set_index(cur); }


I dug through libpng since this seems to not being doing what I expected=
. They seem to set it up as 4 byte array


void /* PRIVATE / png_push_read_chunk(png_structrp png_ptr, png_info=
rp info_ptr) { png_uint_32 chunk_name; #ifdef PNG_HANDLE_AS_UNKNOWN_SUPPORT=
ED int keep; /
unknown handling method */ #endif


/* First we make sure we have enough data for the 4-byte chunk name * an=
d the 4-byte chunk length before proceeding with decoding the * chunk data.=
To fully decode each of these chunks, we also make * sure we have enough d=
ata in the buffer for the 4-byte CRC at the * end of every chunk (except ID=
AT, which is handled separately). */ if ((png_ptr->mode & PNG_HAVE_C=
HUNK_HEADER) =3D=3D 0) { png_byte chunk_length[4]; png_byte chunk_tag[4];p>

  PNG_PUSH_SAVE_BUFFER_IF_LT(8)
png_push_fill_buffer(png_ptr, chunk_length, 4);
png_ptr->push_length =3D png_get_uint_31(png_ptr, chunk_length);
png_reset_crc(png_ptr);
png_crc_read(png_ptr, chunk_tag, 4);
png_ptr->chunk_name =3D PNG_CHUNK_FROM_STRING(chunk_tag);
png_check_chunk_name(png_ptr, png_ptr->chunk_name);
png_ptr->mode |=3D PNG_HAVE_CHUNK_HEADER;

}


I=E2=80=99m obviously not understanding something I=E2=80=99m evaluation=
here. So I=E2=80=99m wondering if anyone can shed light on this. http://ww=
w.nylxs.com/docs/grad_school/parallel/src/png/png_proj.h http://www.nylxs.c=
om/docs/grad_school/parallel/src/png/png_proj.cpp http://www.nylxs.com/docs=
/grad_school/parallel/src/png/main_png.cpp http://www.nylxs.com/docs/grad_s=
chool/parallel/src/png/makefile


ruben


let.me.in


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







--==-=-=--

--=-=-=--

--===-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE3x0LN7z09c1wuX58a4uzPU8xsIsFAlhGzAgACgkQa4uzPU8x
sIumxAgAjJOgm8j+3VdoDoi7Q+KWPaE5CijBrzENzLvdnwhYvLPESotsk/s8o6b6
RKL2TDTDPNtT2ioyEKbtRYseHQYJofXpWYMFCemFfDzNuWawXCalWTTlJ7MvbZ3w
+JuCJP4kSeW6Fz5KONKz26se+taARS5KHWUoLQ5nBLVbC9mq8T2jGgmwVjE85Yo9
0uidmL5KaitsSeQYp1r9uRImr/DPVK/YXOLHWa5bVmjcUDFMvhnFQNZ1aoHE/YG2
rJk+/oFWz1ZFvTJkrtzAW2FtQL+cFG6jCzCXK7Qk8UFx13IZT9+l2/t4K7lc0LcO
joMC0klXtdrC857JNPmsMs7m7N7MtQ==
=QhWr
-----END PGP SIGNATURE-----
--===-=-=--

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

--===============0576477335==--

  1. 2016-12-01 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: Patrolling the Dark Net,
  2. 2016-12-02 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Tutorial on threaded binary tree part 1: simple
  3. 2016-12-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Witner Labs
  4. 2016-12-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Nice lecture on Quantum Mechanics
  5. 2016-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] information access, copyright wars and DRM
  6. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] png data format
  7. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] png data format
  8. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] png data format
  9. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] png data format
  10. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] png data format
  11. 2016-12-06 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] png data format
  12. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] png data format
  13. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] png data format
  14. 2016-12-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] png data format
  15. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] png data format
  16. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] [Hangout-NYLXS] png data format
  17. 2016-12-06 John Bowler <john.cunningham.bowler-at-gmail.com> Re: [Learn] [png-mng-implement] 4 byte length storage
  18. 2016-12-06 John Bowler <john.cunningham.bowler-at-gmail.com> Re: [Learn] [png-mng-implement] 4 byte length storage
  19. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] [png-mng-implement] 4 byte length storage
  20. 2016-12-06 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Ocaml
  21. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: [luny-talk] Humble Bundle O'Reilly UNIX books
  22. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] JT's words
  23. 2016-12-06 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] png data format
  24. 2016-12-07 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: png data format
  25. 2016-12-08 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: png data format
  26. 2016-12-08 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: png data format
  27. 2016-12-08 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: png data format
  28. 2016-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] references to pointers
  29. 2016-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ returning lvalue references and pointers and refs
  30. 2016-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] const puzzle and literal type arguments
  31. 2016-12-11 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: png data format
  32. 2016-12-12 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: Re: png data format
  33. 2016-12-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] gene phylogienics of homonids
  34. 2016-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Bit Depth
  35. 2016-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ Threads Workshop
  36. 2016-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Summer Jobs
  37. 2016-12-14 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Subject: [Learn] For Ruben ( + those in NYC Metro ) : Holiday Social Event
  38. 2016-12-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: [dinosaur] Ceratopsid (Centrosaurinae:
  39. 2016-12-15 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] Happy Holidays
  40. 2016-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] zlib demo with vector::resize
  41. 2016-12-15 John Bowler <john.cunningham.bowler-at-gmail.com> Re: [Learn] [png-mng-implement] 4 byte length storage
  42. 2016-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Elephant bird nuclear genome fragments
  43. 2016-12-15 Christopher League <league-at-contrapunctus.net> Subject: [Learn] zlib demo with vector::resize
  44. 2016-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] zlib demo with vector::resize
  45. 2016-12-16 Christopher League <league-at-contrapunctus.net> Re: [Learn] zlib demo with vector::resize
  46. 2016-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] PNG Parallel Programming problem
  47. 2016-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  48. 2016-12-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] irc thread on the use of object methods in threads
  49. 2016-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] PNG threaded program
  50. 2016-12-18 ruben safir <ruben-at-mrbrklyn.com> Re: [Learn] Threads and Object Methods
  51. 2016-12-18 ruben safir <ruben-at-mrbrklyn.com> Re: [Learn] Threads and Object Methods
  52. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Look C++ is a functional programming language
  53. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] C++ Threading
  54. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ Threading
  55. 2016-12-19 ISOC-NY announcements <announce-at-lists.isoc-ny.org> Subject: [Learn] [isoc-ny] JOB: Telecommunications Policy Specialist -at- NTIA
  56. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] F'ing Mouse Pad
  57. 2016-12-20 mrbrklyn <mrbrklyn-at-panix.com> Subject: [Learn] Phylogenetic study worth noting
  58. 2016-12-21 Samir Iabbassen <Samir.Iabbassen-at-liu.edu> Re: [Learn] Noobdy is home
  59. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Noobdy is home
  60. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Noobdy is home
  61. 2016-12-21 Samir Iabbassen <Samir.Iabbassen-at-liu.edu> Re: [Learn] thread concurancy
  62. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] thread concurancy
  63. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: lamda's in classes
  64. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: lamda's in classes
  65. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: thread concurancy
  66. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  67. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  68. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  69. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  70. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  71. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  72. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  73. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  74. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Re: Threads and Object Methods
  75. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) thread concurancy
  76. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] (fwd) Threads and Object Methods
  77. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] I need help
  78. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Noobdy is home
  79. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] thread concurancy
  80. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] [Hangout-NYLXS] Marnchester by the Sea
  81. 2016-12-22 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] [Hangout-NYLXS] And be aware you were an unexcused
  82. 2016-12-22 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: thread concurancy
  83. 2016-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] HOPL (History of Programming Languages)
  84. 2016-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Noobdy is home
  85. 2016-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Tiny Compiler in many languages at Rosettacode.org
  86. 2016-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Google and C++
  87. 2016-12-25 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] phylogentics
  88. 2016-12-27 Samir Iabbassen <Samir.Iabbassen-at-liu.edu> Re: [Learn] thread concurancy

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