Fri Oct 4 19:20:03 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

HANGOUT

2024-10-04 | 2024-09-04 | 2024-08-04 | 2024-07-04 | 2024-06-04 | 2024-05-04 | 2024-04-04 | 2024-03-04 | 2024-02-04 | 2024-01-04 | 2023-12-04 | 2023-11-04 | 2023-10-04 | 2023-09-04 | 2023-08-04 | 2023-07-04 | 2023-06-04 | 2023-05-04 | 2023-04-04 | 2023-03-04 | 2023-02-04 | 2023-01-04 | 2022-12-04 | 2022-11-04 | 2022-10-04 | 2022-09-04 | 2022-08-04 | 2022-07-04 | 2022-06-04 | 2022-05-04 | 2022-04-04 | 2022-03-04 | 2022-02-04 | 2022-01-04 | 2021-12-04 | 2021-11-04 | 2021-10-04 | 2021-09-04 | 2021-08-04 | 2021-07-04 | 2021-06-04 | 2021-05-04 | 2021-04-04 | 2021-03-04 | 2021-02-04 | 2021-01-04 | 2020-12-04 | 2020-11-04 | 2020-10-04 | 2020-09-04 | 2020-08-04 | 2020-07-04 | 2020-06-04 | 2020-05-04 | 2020-04-04 | 2020-03-04 | 2020-02-04 | 2020-01-04 | 2019-12-04 | 2019-11-04 | 2019-10-04 | 2019-09-04 | 2019-08-04 | 2019-07-04 | 2019-06-04 | 2019-05-04 | 2019-04-04 | 2019-03-04 | 2019-02-04 | 2019-01-04 | 2018-12-04 | 2018-11-04 | 2018-10-04 | 2018-09-04 | 2018-08-04 | 2018-07-04 | 2018-06-04 | 2018-05-04 | 2018-04-04 | 2018-03-04 | 2018-02-04 | 2018-01-04 | 2017-12-04 | 2017-11-04 | 2017-10-04 | 2017-09-04 | 2017-08-04 | 2017-07-04 | 2017-06-04 | 2017-05-04 | 2017-04-04 | 2017-03-04 | 2017-02-04 | 2017-01-04 | 2016-12-04 | 2016-11-04 | 2016-10-04 | 2016-09-04 | 2016-08-04 | 2016-07-04 | 2016-06-04 | 2016-05-04 | 2016-04-04 | 2016-03-04 | 2016-02-04 | 2016-01-04 | 2015-12-04 | 2015-11-04 | 2015-10-04 | 2015-09-04 | 2015-08-04 | 2015-07-04 | 2015-06-04 | 2015-05-04 | 2015-04-04 | 2015-03-04 | 2015-02-04 | 2015-01-04 | 2014-12-04 | 2014-11-04 | 2014-10-04 | 2014-09-04 | 2014-08-04 | 2014-07-04 | 2014-06-04 | 2014-05-04 | 2014-04-04 | 2014-03-04 | 2014-02-04 | 2014-01-04 | 2013-12-04 | 2013-11-04 | 2013-10-04 | 2013-09-04 | 2013-08-04 | 2013-07-04 | 2013-06-04 | 2013-05-04 | 2013-04-04 | 2013-03-04 | 2013-02-04 | 2013-01-04 | 2012-12-04 | 2012-11-04 | 2012-10-04 | 2012-09-04 | 2012-08-04 | 2012-07-04 | 2012-06-04 | 2012-05-04 | 2012-04-04 | 2012-03-04 | 2012-02-04 | 2012-01-04 | 2011-12-04 | 2011-11-04 | 2011-10-04 | 2011-09-04 | 2011-08-04 | 2011-07-04 | 2011-06-04 | 2011-05-04 | 2011-04-04 | 2011-03-04 | 2011-02-04 | 2011-01-04 | 2010-12-04 | 2010-11-04 | 2010-10-04 | 2010-09-04 | 2010-08-04 | 2010-07-04 | 2010-06-04 | 2010-05-04 | 2010-04-04 | 2010-03-04 | 2010-02-04 | 2010-01-04 | 2009-12-04 | 2009-11-04 | 2009-10-04 | 2009-09-04 | 2009-08-04 | 2009-07-04 | 2009-06-04 | 2009-05-04 | 2009-04-04 | 2009-03-04 | 2009-02-04 | 2009-01-04 | 2008-12-04 | 2008-11-04 | 2008-10-04 | 2008-09-04 | 2008-08-04 | 2008-07-04 | 2008-06-04 | 2008-05-04 | 2008-04-04 | 2008-03-04 | 2008-02-04 | 2008-01-04 | 2007-12-04 | 2007-11-04 | 2007-10-04 | 2007-09-04 | 2007-08-04 | 2007-07-04 | 2007-06-04 | 2007-05-04 | 2007-04-04 | 2007-03-04 | 2007-02-04 | 2007-01-04 | 2006-12-04 | 2006-11-04 | 2006-10-04 | 2006-09-04 | 2006-08-04 | 2006-07-04 | 2006-06-04 | 2006-05-04 | 2006-04-04 | 2006-03-04 | 2006-02-04 | 2006-01-04 | 2005-12-04 | 2005-11-04 | 2005-10-04 | 2005-09-04 | 2005-08-04 | 2005-07-04 | 2005-06-04 | 2005-05-04 | 2005-04-04 | 2005-03-04 | 2005-02-04 | 2005-01-04 | 2004-12-04 | 2004-11-04 | 2004-10-04 | 2004-09-04 | 2004-08-04 | 2004-07-04 | 2004-06-04 | 2004-05-04 | 2004-04-04 | 2004-03-04 | 2004-02-04 | 2004-01-04 | 2003-12-04 | 2003-11-04 | 2003-10-04 | 2003-09-04 | 2003-08-04 | 2003-07-04 | 2003-06-04 | 2003-05-04 | 2003-04-04 | 2003-03-04 | 2003-02-04 | 2003-01-04 | 2002-12-04 | 2002-11-04 | 2002-10-04 | 2002-09-04 | 2002-08-04 | 2002-07-04 | 2002-06-04 | 2002-05-04 | 2002-04-04 | 2002-03-04 | 2002-02-04 | 2002-01-04 | 2001-12-04 | 2001-11-04 | 2001-10-04 | 2001-09-04 | 2001-08-04 | 2001-07-04 | 2001-06-04 | 2001-05-04 | 2001-04-04 | 2001-03-04 | 2001-02-04 | 2001-01-04 | 2000-12-04 | 2000-11-04 | 2000-10-04 | 2000-09-04 | 2000-08-04 | 2000-07-04 | 2000-06-04 | 2000-05-04 | 2000-04-04 | 2000-03-04 | 2000-02-04 | 2000-01-04 | 1999-12-04

Key: Value:

Key: Value:

MESSAGE
DATE 2016-12-06
FROM Christopher League
SUBJECT Re: [Hangout-NYLXS] [Learn] png data format
From hangout-bounces-at-nylxs.com Tue Dec 6 10:40:09 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 647C316131C;
Tue, 6 Dec 2016 10:40:08 -0500 (EST)
X-Original-To: hangout-at-nylxs.com
Delivered-To: hangout-at-nylxs.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 46FBB161311; Tue, 6 Dec 2016 10:07:28 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Tue, 6 Dec 2016 10:07:28 -0500
Resent-Message-ID: <20161206150728.GD24997-at-www.mrbrklyn.com>
Resent-To: hangout-at-nylxs.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from liucs.net (contrapunctus.net [174.136.110.10])
by mrbrklyn.com (Postfix) with ESMTP id 5FE68161311
for ; 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
X-UID: 32783
X-Mailman-Approved-At: Tue, 06 Dec 2016 10:39:57 -0500
X-Content-Filtered-By: Mailman/MimeDel 2.1.17
Subject: Re: [Hangout-NYLXS] [Learn] png data format
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: NYLXS Discussions List
List-Id: NYLXS Discussions List
List-Unsubscribe: ,

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

Content-Type: multipart/mixed; boundary="===============0873416613=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "hangout"

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

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

--==-=-=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"


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 [1]league-at-contrapunctus.net 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 [2]ruben-at-mrbrklyn.com 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::e
ndl;
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 << "" <<
static_cast(*tmp2) << std::endl; tmp2++; } std::cout<(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

References

1. mailto:league-at-contrapunctus.net
2. mailto:ruben-at-mrbrklyn.com

--==-=-=--

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

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

_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/
--===============0873416613==--

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

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

--==-=-=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"


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 [1]league-at-contrapunctus.net 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 [2]ruben-at-mrbrklyn.com 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::e
ndl;
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 << "" <<
static_cast(*tmp2) << std::endl; tmp2++; } std::cout<(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

References

1. mailto:league-at-contrapunctus.net
2. mailto:ruben-at-mrbrklyn.com

--==-=-=--

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

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

_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/
--===============0873416613==--

  1. 2016-12-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] FYI for Brooklynites and others
  2. 2016-12-01 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Fwd: Patrolling the Dark Net,
  3. 2016-12-03 Asher Elbein <aelbein-at-gmail.com> Subject: [Hangout-NYLXS] [dinosaur] Regarding Art Theft
  4. 2016-12-03 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] [dinosaur] Regarding Art Theft
  5. 2016-12-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Witner Labs
  6. 2016-12-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] the city for the people and by the people
  7. 2016-12-03 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout-NYLXS] HIMSS17 Early Bird Registration Deadline is
  8. 2016-12-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Nice lecture on Quantum Mechanics
  9. 2016-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: Tomorrow's Webinar - No Downtime Data
  10. 2016-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] http://www.lazarus-ide.org/
  11. 2016-12-05 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Fwd: [LIU Comp Sci] Nice possible project for NYLXS
  12. 2016-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Oh Look a real website
  13. 2016-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] information access, copyright wars and DRM
  14. 2016-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] More retarded news from the city that wants to push
  15. 2016-12-06 ruben safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] png data format
  16. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] png data format
  17. 2016-12-05 From: "Rijksmuseum" <rijksstudio-at-news.rijksmuseum.nl> Subject: [Hangout-NYLXS] Glorious food in Rijksstudio
  18. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] [Learn] png data format
  19. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Hangout-NYLXS] [Learn] png data format
  20. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Hangout-NYLXS] [Learn] png data format
  21. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Hangout-NYLXS] [Learn] png data format
  22. 2016-12-06 Christopher League <league-at-contrapunctus.net> Re: [Hangout-NYLXS] [Learn] png data format
  23. 2016-12-06 John Bowler <john.cunningham.bowler-at-gmail.com> Re: [Hangout-NYLXS] [png-mng-implement] 4 byte length storage
  24. 2016-12-06 John Bowler <john.cunningham.bowler-at-gmail.com> Re: [Hangout-NYLXS] [png-mng-implement] 4 byte length storage
  25. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] [png-mng-implement] 4 byte length storage
  26. 2016-12-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] [Learn] png data format
  27. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] [Learn] png data format
  28. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: Re: [luny-talk] Humble Bundle O'Reilly UNIX
  29. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Every face is tracked. Every footfall was
  30. 2016-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] JT's words
  31. 2016-12-06 James E Keenan <jkeen-at-verizon.net> Subject: [Hangout-NYLXS] The ny.pm talks I'd like to hear
  32. 2016-12-07 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Islam s fine
  33. 2016-12-09 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Fwd: Kindly Share the Free Journal
  34. 2016-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] good Shabbos All
  35. 2016-12-10 ruben safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Michael Kingsley and the Fascist in Office
  36. 2016-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] slow Vietnam like creep into Syrian civil war
  37. 2016-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] C++ returning lvalue references and pointers and
  38. 2016-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] a real live dinosaur tail found in the flesh
  39. 2016-12-10 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Movie of the Week
  40. 2016-12-10 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Michael Kingsley and the Fascist in Office
  41. 2016-12-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] I knew as soon as I learned about dark matter that
  42. 2016-12-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] islam is your friend
  43. 2016-12-11 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] islam is your friend
  44. 2016-12-12 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] islam is your friendII
  45. 2016-12-12 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] islam is your friend III
  46. 2016-12-12 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] islam is your friend IV
  47. 2016-12-12 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] islam is your friend V
  48. 2016-12-12 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] islam is your friend VI
  49. 2016-12-12 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] islam is your friend VI
  50. 2016-12-12 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] islam is your friend VII
  51. 2016-12-12 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] islam is your friend VI
  52. 2016-12-11 Rick Tanner <leaf-at-real-time.com> Subject: [Hangout-NYLXS] [crossfire] Crossfire wiki offline for maintenance
  53. 2016-12-12 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #281 - The holidays are upon us!
  54. 2016-12-12 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] islam is your friend VI
  55. 2016-12-12 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] islam is your friend VI
  56. 2016-12-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Minoan history
  57. 2016-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Death of the Sea Saw
  58. 2016-12-12 Nawaz Nazeer Ahamed <nawaz.nazeer.ahamed-at-oracle.com> Subject: [Hangout-NYLXS] MySQL Community Server 5.6.35 has been released
  59. 2016-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] C++ Threads Workshop
  60. 2016-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Summer Jobs
  61. 2016-12-14 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] islam is your friend VI
  62. 2016-12-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: Re: [dinosaur] Ceratopsid (Centrosaurinae:
  63. 2016-12-13 From: "Ruben.Safir" <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] goldfinch
  64. 2016-12-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Apollo Moon Shot Photography
  65. 2016-12-14 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Subject: [Hangout-NYLXS] For Ruben ( + those in NYC Metro ) : Holiday Social
  66. 2016-12-14 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] islam is your friend VI
  67. 2016-12-14 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] islam is your friend VI
  68. 2016-12-14 Elfen Magix <elfen_magix-at-yahoo.com> Re: [Hangout-NYLXS] Apollo Moon Shot Photography
  69. 2016-12-15 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] islam is your friend VI
  70. 2016-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Your Santa Imam is here
  71. 2016-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] islam is your friend VI
  72. 2016-12-15 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] islam is your friend VI
  73. 2016-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Barak and Jerry Show
  74. 2016-12-15 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Michael Kingsley and the Fascist in Office
  75. 2016-12-15 From: "American Museum of Natural History" <mat-at-amnh.org> Subject: [Hangout-NYLXS] Join the MAT Program Class of 2017
  76. 2016-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] this story is 5 years late on drug prices
  77. 2016-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Attacks at Cornel
  78. 2016-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  79. 2016-12-17 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  80. 2016-12-17 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Movie of the Week! Hello BOB!!
  81. 2016-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] anyone want to see Star Wars tonight?
  82. 2016-12-18 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  83. 2016-12-16 From: "APhA's Pharmacy Today" <PTdaily-at-aphanet.org> Subject: [Hangout-NYLXS] December 16,
  84. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  85. 2016-12-18 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  86. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  87. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  88. 2016-12-18 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  89. 2016-12-18 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  90. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Look C++ is a functional programming language
  91. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  92. 2016-12-18 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  93. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  94. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  95. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] New Distros to try
  96. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] New Distros to try
  97. 2016-12-19 mayer ilovitz <pmamayeri-at-gmail.com> Re: [Hangout-NYLXS] New Distros to try
  98. 2016-12-19 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] New Distros to try
  99. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] New Distros to try
  100. 2016-12-19 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] another offbeat distro
  101. 2016-12-19 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] New Distros to try
  102. 2016-12-19 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] systemd critique et al
  103. 2016-12-19 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] New Distros to try
  104. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] New Distros to try
  105. 2016-12-19 From: "Ruben.Safir" <ruben.safir-at-my.liu.edu> Re: [Hangout-NYLXS] New Distros to try
  106. 2016-12-19 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #282 - The White Camels are roaming
  107. 2016-12-19 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] New Distros to try: Please explain what the
  108. 2016-12-19 mayer ilovitz <pmamayeri-at-gmail.com> Re: [Hangout-NYLXS] New Distros to try: Please explain what the
  109. 2016-12-19 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] the issues with SystemD: why are they doing
  110. 2016-12-19 mayer ilovitz <pmamayeri-at-gmail.com> Re: [Hangout-NYLXS] the issues with SystemD: why are they doing
  111. 2016-12-19 ISOC-NY announcements <announce-at-lists.isoc-ny.org> Subject: [Hangout-NYLXS] [isoc-ny] JOB: Telecommunications Policy Specialist
  112. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  113. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  114. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] the issues with SystemD: why are they doing
  115. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] NYLXS Textbook Section
  116. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] NYLXS Textbook Section
  117. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] New Distros to try: Please explain what the
  118. 2016-12-19 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] New Distros to try: Please explain what the
  119. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] NYLXS Textbook Section
  120. 2016-12-19 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Workshops -at- ACM/SPEC ICPE 2017 - Call for
  121. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] wow - just got an email from Ruth
  122. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] This Mayor is an IDIOT
  123. 2016-12-20 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  124. 2016-12-20 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  125. 2016-12-20 mayer ilovitz <pmamayeri-at-gmail.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  126. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  127. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  128. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Ocean Parkway Protest!!
  129. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] The ever growing police state
  130. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Serious danger to state sovereignty and your right
  131. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] F'ing Mouse Pad
  132. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  133. 2016-12-20 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout-NYLXS] BHI'17 Registration Now Open!
  134. 2016-12-20 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Serious danger to state sovereignty and your
  135. 2016-12-20 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  136. 2016-12-20 einker <eminker-at-gmail.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  137. 2016-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  138. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Serious danger to state sovereignty and your
  139. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  140. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] The fascinating case of Bernie Goetz
  141. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  142. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] The fascinating case of Bernie Goetz
  143. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  144. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] The fascinating case of Bernie Goetz
  145. 2016-12-21 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Serious danger to state sovereignty and your
  146. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Thank god he is dead
  147. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Brooklyn Principal Shot to Death While Looking for
  148. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Marla Hanson recalls her nightmare
  149. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Official crime numbers in Kings County
  150. 2016-12-21 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] I'm sure it's a coincidence, part n+1
  151. 2016-12-21 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] LIU Brooklyn Campus Safety
  152. 2016-12-21 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] LIU Brooklyn Campus Safety
  153. 2016-12-21 Rick Moen <rick-at-linuxmafia.com> Subject: [Hangout-NYLXS] What California gets for Christmas
  154. 2016-12-21 From: "Amy at NTEN" <amy-at-nten.org> Subject: [Hangout-NYLXS] NTEN Connect: The Best NPTech Stories of 2016,
  155. 2016-12-21 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout-NYLXS] 2017 ISBI Call for Abstracts- Submission Deadline
  156. 2016-12-21 einker <eminker-at-gmail.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  157. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  158. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Marnchester by the Sea
  159. 2016-12-21 mayer ilovitz <pmamayeri-at-gmail.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  160. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  161. 2016-12-21 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] What California gets for Christmas
  162. 2016-12-21 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  163. 2016-12-21 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT
  164. 2016-12-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] the sorry state of this country and its bizarre
  165. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] What California gets for Christmas: Yeah but
  166. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] sorry state this country,
  167. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] This Mayor is an IDIOT | | Yeah,
  168. 2016-12-22 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] sorry state this country,
  169. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Shelter Cove- which one ? There are two- one in
  170. 2016-12-22 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Shelter Cove- which one ? There are two- one in
  171. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] And be aware you were an unexcused no-show
  172. 2016-12-22 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Hangout-NYLXS] And be aware you were an unexcused no-show
  173. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] And be aware you were an unexcused no-show
  174. 2016-12-22 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] And be aware you were an unexcused no-show
  175. 2016-12-22 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] We were talking about how you could transport
  176. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] And be aware you were an unexcused no-show
  177. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Shelter Cove- which one ? There are two- one in
  178. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] This Mayor is an IDIOT | | Yeah,
  179. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] sorry state this country,
  180. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] What California gets for Christmas: Yeah but
  181. 2016-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Homeless have taken over 34th street
  182. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] the sorry state of this country and its bizarre
  183. 2016-12-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] the sorry state of this country and its bizarre
  184. 2016-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] HOPL (History of Programming Languages)
  185. 2016-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Tiny Compiler in many languages at
  186. 2016-12-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Chag Simaach
  187. 2016-12-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] jobs
  188. 2016-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Sanders and Socialism
  189. 2016-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Free Speach
  190. 2016-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Google and C++
  191. 2016-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Conflicts of Interest
  192. 2016-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Syria wished you a Merry Christmas
  193. 2016-12-25 Rick Moen <rick-at-linuxmafia.com> Subject: [Hangout-NYLXS] Light even in the darkness
  194. 2016-12-25 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Syria wished you a Merry Christmas
  195. 2016-12-26 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #283 - Merry Christmas & Happy Hanukkah
  196. 2016-12-26 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #283 - Merry Christmas & Happy Hanukkah
  197. 2016-12-27 From: "Ruben.Safir" <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Israel band, Iran Good
  198. 2016-12-27 mrbrklyn <mrbrklyn-at-panix.com> Subject: [Hangout-NYLXS] Israel band, Iran Good
  199. 2016-12-27 mrbrklyn <mrbrklyn-at-panix.com> Subject: [Hangout-NYLXS] International criminals, every jew
  200. 2016-12-27 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] she's gone
  201. 2016-12-27 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] International criminals, every jew
  202. 2016-12-28 mrbrklyn <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] International criminals, every jew
  203. 2016-12-28 mrbrklyn <mrbrklyn-at-panix.com> Subject: [Hangout-NYLXS] can't find the damn ball anywhere here
  204. 2016-12-28 From: "Pharmacy Times" <enews-at-pharmacytimes.com> Subject: [Hangout-NYLXS] Xtampza(R) ER (oxycodone) Product Bulletin
  205. 2016-12-29 From: "Ruben.Safir" <ruben.safir-at-my.liu.edu> Subject: [Hangout-NYLXS] Police State gets one step closer

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