Fri Apr 19 22:45:08 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-04-19 | 2024-03-19 | 2024-02-19 | 2024-01-19 | 2023-12-19 | 2023-11-19 | 2023-10-19 | 2023-09-19 | 2023-08-19 | 2023-07-19 | 2023-06-19 | 2023-05-19 | 2023-04-19 | 2023-03-19 | 2023-02-19 | 2023-01-19 | 2022-12-19 | 2022-11-19 | 2022-10-19 | 2022-09-19 | 2022-08-19 | 2022-07-19 | 2022-06-19 | 2022-05-19 | 2022-04-19 | 2022-03-19 | 2022-02-19 | 2022-01-19 | 2021-12-19 | 2021-11-19 | 2021-10-19 | 2021-09-19 | 2021-08-19 | 2021-07-19 | 2021-06-19 | 2021-05-19 | 2021-04-19 | 2021-03-19 | 2021-02-19 | 2021-01-19 | 2020-12-19 | 2020-11-19 | 2020-10-19 | 2020-09-19 | 2020-08-19 | 2020-07-19 | 2020-06-19 | 2020-05-19 | 2020-04-19 | 2020-03-19 | 2020-02-19 | 2020-01-19 | 2019-12-19 | 2019-11-19 | 2019-10-19 | 2019-09-19 | 2019-08-19 | 2019-07-19 | 2019-06-19 | 2019-05-19 | 2019-04-19 | 2019-03-19 | 2019-02-19 | 2019-01-19 | 2018-12-19 | 2018-11-19 | 2018-10-19 | 2018-09-19 | 2018-08-19 | 2018-07-19 | 2018-06-19 | 2018-05-19 | 2018-04-19 | 2018-03-19 | 2018-02-19 | 2018-01-19 | 2017-12-19 | 2017-11-19 | 2017-10-19 | 2017-09-19 | 2017-08-19 | 2017-07-19 | 2017-06-19 | 2017-05-19 | 2017-04-19 | 2017-03-19 | 2017-02-19 | 2017-01-19 | 2016-12-19 | 2016-11-19 | 2016-10-19 | 2016-09-19 | 2016-08-19 | 2016-07-19 | 2016-06-19 | 2016-05-19 | 2016-04-19 | 2016-03-19 | 2016-02-19 | 2016-01-19 | 2015-12-19 | 2015-11-19 | 2015-10-19 | 2015-09-19 | 2015-08-19 | 2015-07-19 | 2015-06-19 | 2015-05-19 | 2015-04-19 | 2015-03-19 | 2015-02-19 | 2015-01-19 | 2014-12-19 | 2014-11-19 | 2014-10-19

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:24: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 3A610161313;
Tue, 6 Dec 2016 09:24:11 -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 5B89C161311;
Tue, 6 Dec 2016 09:24:07 -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 DE791E096;
Tue, 6 Dec 2016 09:24:05 -0500 (EST)
From: Christopher League
To: ruben safir , Hangout ,
learn-at-nylxs.com
In-Reply-To: <66105244-4afa-4330-b0c2-0661bde965fd-at-mrbrklyn.com>
References: <66105244-4afa-4330-b0c2-0661bde965fd-at-mrbrklyn.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1
(x86_64-unknown-linux-gnu)
Date: Tue, 06 Dec 2016 09:24:04 -0500
Message-ID: <87bmwpf857.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="===============2048593676=="
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"

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

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


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




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::en=
dl;
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>(=
get_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 " <&l=
t; *buffer << std::endl;
std::cout << "buffer size is " << l &l=
t;< 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 &l=
t;< 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****" << st=
d::endl;
break;
} /* ----- end switch ----- */

char * tmp2 =3D reinterpret_cast<char *>(tmp); //reading each b=
yte
std::cout << "Sizeof Byte " << sizeof(*tmp2) &=
lt;< std::endl;
//std::cout << "Mark =3D=3D>>" << __LINE_=
_ << std::endl;
for(int i=3D0; i<4; i++){
std::cout << "Character " << i << &qu=
ot;::" << 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






--=-=-=--

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

--===============2048593676==--

  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!