[27431] in Perl-Users-Digest
Perl-Users Digest, Issue: 9073 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 21 18:06:00 2006
Date: Tue, 21 Mar 2006 15:05:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 21 Mar 2006 Volume: 10 Number: 9073
Today's topics:
Re: A Problem With GD robic0
Re: A Problem With GD robic0
Re: A Problem With GD robic0
Re: How to release memory ? xhoster@gmail.com
Re: joining a hash of arrays <xx087@freenet.carleton.ca>
OT: Senator Everett Dirksen (was Re: How to release mem <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 21 Mar 2006 14:14:03 -0800
From: robic0
Subject: Re: A Problem With GD
Message-Id: <gkt022p4gss5vm26pivuhtdg0eppbph4e1@4ax.com>
On Mon, 20 Mar 2006 13:33:46 +0100, "Lukas Mai" <rwxr-xr-x@gmx.de> wrote:
>robic0 schrob:
>> On Sun, 19 Mar 2006 13:21:22 +0100, "Lukas Mai" <rwxr-xr-x@gmx.de> wrote:
>>
>>>robic0 schrob:
>>>>
>>>> Really? What does a compiler know? It knows the smallest and the largest.
>>>> The smallest is always a "char", the largest is always an "int".
>>>
>>>Wrong. The smallest addressable unit is always a char, but long int or
>>>long long int are often larger than int.
>>
>> Jesus, what drugs are you on dude? I'm talking about the *MACHINE WORD*.
>> That which is *NATIVE* to the cpu, a *REGISTER*, address or data !!!!
>> These are *INTRINSIC* types to the compiler, there are *NO* others !!!
>
>Wrong again. What makes you think a compiler has to generate machine
>code,
Thats what 'C' compilers do. In 2 passes btw.
> or that int has to be a "native" type? Or that all registers have
>the same size?
>
'int' is another way of saying machine 'word'. Its a notation more for
the user that says the largest bit size of a data register in whatever
mode it is running in (32-64 bit). Its something the compiler knows
that will make the cpu run at its optimum and its set in the last pass
when binary (machine code) is generated. All you have to do is tell the
compiler not to generate debug and trace into any function. You can also
go to the definition of any intrinsic (thats the little color hilighted
code in an ide). That will take you to typedefs and MACRO's.
>> Everything else you can type in a .cpp file is a *MACRO*, a definition
>> that resolves to signed or unsigned of the native "char" or "int". This
>> since the advent of 32-bit compilers.
>
>A macro is something created by "#define" (ok, or one of the built-in
>macros, like __FILE__ or __STDC__). Oh, and shorts are 16 bits wide
>here. That's neither char (8 bits) nor int (32 bits).
>
'short's are whatever the MACRO of the compiler says it is. Check it out
for yourself. 'shorts' aren't used anymore these days.
>> Bit map manipulations are extremely dependent on this and are hardcoded
>> by programmers. Bit masks, bit shifts are usually what needs to be modified
>> when going to a *larger* machine word compiler.
>
>Only if your code sucks. You can write perfectly portable code that uses
>bitwise ops.
Don't understand what you mean here.
>
>> If you see code that has typing other than int, char, signed or unsigned,
>> it is a macro! AND its probably code that is 10 or more years older.
>
>Wrong.
'typedefs' and MACRO's all resolving to 'char' and 'int'.
'short' ends up being a bitmask'ed 'int', signed or unsigned.
>
>> "long" is *NOT* a intrinsic type for many years now. Not "long long",
>> "long short long", "short long char", not any of these things!!!!
>
>You can't use both "short" and "long" in the same type. "long" happens
>to be an intrinsic type here (it's 32 bits wide and fits in a machine
>register).
>
'long' is *NOT* an intrinsic type.. anywhere!!!!!
>> Get off drugs as soon as possible..........
>>
>> <other bullshit snipped>
>
>As announced, your soul is mine now. I advise you to stop posting to
>usenet; no one will pay attention to your articles anyway if you don't
>have a soul. Thanks.
>
>Lukas
Its a good thing that I posted a reply to you, otherwise you would
still think 'short', 'long' and 'byte' are actually something different
that intrinsics int and char.
And I welcome anyone else to comment who believes as this gentleman does
(and a few others).
robic0
------------------------------
Date: Tue, 21 Mar 2006 14:26:55 -0800
From: robic0
Subject: Re: A Problem With GD
Message-Id: <equ022pi7qsfqvnkj8m9u9pte0t04ka24c@4ax.com>
On Tue, 21 Mar 2006 14:14:03 -0800, robic0 wrote:
>On Mon, 20 Mar 2006 13:33:46 +0100, "Lukas Mai" <rwxr-xr-x@gmx.de> wrote:
>
>>robic0 schrob:
>>> On Sun, 19 Mar 2006 13:21:22 +0100, "Lukas Mai" <rwxr-xr-x@gmx.de> wrote:
>>>
>>>>robic0 schrob:
>>>>>
>>>>> Really? What does a compiler know? It knows the smallest and the largest.
>>>>> The smallest is always a "char", the largest is always an "int".
>>>>
>>>>Wrong. The smallest addressable unit is always a char, but long int or
>>>>long long int are often larger than int.
>>>
>>> Jesus, what drugs are you on dude? I'm talking about the *MACHINE WORD*.
>>> That which is *NATIVE* to the cpu, a *REGISTER*, address or data !!!!
>>> These are *INTRINSIC* types to the compiler, there are *NO* others !!!
>>
>>Wrong again. What makes you think a compiler has to generate machine
>>code,
>Thats what 'C' compilers do. In 2 passes btw.
>> or that int has to be a "native" type? Or that all registers have
>>the same size?
>>
>'int' is another way of saying machine 'word'. Its a notation more for
>the user that says the largest bit size of a data register in whatever
>mode it is running in (32-64 bit). Its something the compiler knows
>that will make the cpu run at its optimum and its set in the last pass
>when binary (machine code) is generated. All you have to do is tell the
>compiler not to generate debug and trace into any function. You can also
>go to the definition of any intrinsic (thats the little color hilighted
>code in an ide). That will take you to typedefs and MACRO's.
>
>>> Everything else you can type in a .cpp file is a *MACRO*, a definition
>>> that resolves to signed or unsigned of the native "char" or "int". This
>>> since the advent of 32-bit compilers.
>>
>>A macro is something created by "#define" (ok, or one of the built-in
>>macros, like __FILE__ or __STDC__). Oh, and shorts are 16 bits wide
>>here. That's neither char (8 bits) nor int (32 bits).
>>
>'short's are whatever the MACRO of the compiler says it is. Check it out
>for yourself. 'shorts' aren't used anymore these days.
>
>>> Bit map manipulations are extremely dependent on this and are hardcoded
>>> by programmers. Bit masks, bit shifts are usually what needs to be modified
>>> when going to a *larger* machine word compiler.
>>
>>Only if your code sucks. You can write perfectly portable code that uses
>>bitwise ops.
>Don't understand what you mean here.
>>
>>> If you see code that has typing other than int, char, signed or unsigned,
>>> it is a macro! AND its probably code that is 10 or more years older.
>>
>>Wrong.
>'typedefs' and MACRO's all resolving to 'char' and 'int'.
>'short' ends up being a bitmask'ed 'int', signed or unsigned.
>>
>>> "long" is *NOT* a intrinsic type for many years now. Not "long long",
>>> "long short long", "short long char", not any of these things!!!!
>>
>>You can't use both "short" and "long" in the same type. "long" happens
>>to be an intrinsic type here (it's 32 bits wide and fits in a machine
>>register).
>>
>'long' is *NOT* an intrinsic type.. anywhere!!!!!
>
>>> Get off drugs as soon as possible..........
>>>
>>> <other bullshit snipped>
>>
>>As announced, your soul is mine now. I advise you to stop posting to
>>usenet; no one will pay attention to your articles anyway if you don't
>>have a soul. Thanks.
>>
>>Lukas
>
>Its a good thing that I posted a reply to you, otherwise you would
>still think 'short', 'long' and 'byte' are actually something different
>that intrinsics int and char.
>
>And I welcome anyone else to comment who believes as this gentleman does
>(and a few others).
>
>robic0
Sorry, I just can't resist one more comment.
As far as the cpu goes, it has single instructions for dealing with
'char' and 'int', 'int' being the machine word. For a cpu to have to
implement a 'short' (whatever that is) would require a possible bitmask
and shift.
Doesen't it just seem natural that the compiler wouldn't want to do that
unless it absolutely had to, as in the case of possible I/O.
So, the compiler promotes all wierd pseudo, legacy types to the machine
word (except byte). When and if I/O requires a compiler defined bit
range it is converted, but never before and never at all if no I/O.
So if you have a type 'short' within a structure, its type is really
'int', when you do bit manipulations on it, its really on a 'int'.
*ONLY* if and when you do I/O on it will it ever be masked and joined
on the next (or padded) machine word!!!
Please don't forget that.
If you dispute this, bring it on...
robic0
------------------------------
Date: Tue, 21 Mar 2006 14:29:33 -0800
From: robic0
Subject: Re: A Problem With GD
Message-Id: <1hv022pej262n1e60de0r377m76httrofq@4ax.com>
On Mon, 20 Mar 2006 14:04:54 +0100, "Dr.Ruud" <rvtol+news@isolution.nl> wrote:
>Lukas Mai schreef:
>
>> Wrong again.
>
>Please don't feed the troll.
Get ur peanuts, popcorn for the troll, only 1 dolla...
------------------------------
Date: 21 Mar 2006 20:34:45 GMT
From: xhoster@gmail.com
Subject: Re: How to release memory ?
Message-Id: <20060321154226.601$rQ@newsreader.com>
zdbrg <zdbrg@mail.con> wrote:
> xhoster@gmail.com a dit le 21 Mar 2006 14:50:07 GMT:
>
> >Mostly I just let the VM system do it's job. Are you sure that won't
> >work for you?
> >
> >Xho
>
> Yes it will, at the cost of swapping hundred megs of memory to disk.
A hundred meg here, an hundred meg there, pretty soon you may be talking
about real IO :).
Swapping lots of memory to disk is often a small price to pay for the
benefit of not having to micromanage your program's memory use. And when
that price is too high, then your optimization choices are so intimately
tied in with the nitty-gritty details of your code that it is hard to
discuss them meaningfully in generalities. At various times, I've:
Opened "+<" then used seek, tell, read, etc.
Used Acme::Abuse to isolate certain parts to separate process.
Used various tie modules to tie the data to disk.
Used mmap through XS code (although doing it again I'd probably look into
Sys::Mmap first) Made my code readily restartable, so I could exit after a
particularly memory heavy usage and then pick up where it left off in a
fresh interpreter.
But the vast majority of the time I don't do any of these rather painful
and time consuming (my time, that is) things, I just let the VM system swap
out hundreds of megabytes.
>
> As zentara pointed out, using some kind of persistant database (which was
> not wanted at the first time), will surely drop down memory use, adding a
> bit of complexity, and probably slowlyness.
This is often a good idea, especially if your large data structure is a
hash. But if it is a scalar, like your example seems to suggest, it is less
clear how useful this will be.
> Forking or using a crontab
> (on *nix systems) for that is surely another good solution.
I don't see how crontab would help here, but forking certainly could if you
have a lot of mostly independent tasks where some are very big and some
are not. But if in that situation, I'd tend to use forking anyway, even
if memory was not a concern.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 21 Mar 2006 20:01:07 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: joining a hash of arrays
Message-Id: <slrne20ms3.9ep.xx087@smeagol.ncf.ca>
At 2006-03-21 11:50AM, Marshall Dudley <mdudley@king-cart.com> wrote:
> How do you join an hash of arrays, I can't seem to find, nor figure out
> the syntax.
>
> When I try:
>
> my $color = join ' ',@{ $color{$id}};
>
> and the array for $id contains "white","black" I get:
>
> ARRAY(0x8051878)
>
> instead of "white black".
Looks like you have a hash of arrays of arrays instead:
Try looking at the first element of the array reference:
my %color = (id => [[ qw{white black} ]]);
print join(':', @{$color{'id'}} ); #==> ARRAY(0x235454)
print join(':', @{$color{'id'}->[0]} ); #==> white:black
For debugging, use Data::Dumper to look at your data.
use Data::Dumper
print Dumper \%color
$VAR1 = {
'id' => [ # Note the two layers of
[ # array references here
'white',
'black'
]
]
};
--
Glenn Jackman
Ulterior Designer
------------------------------
Date: Tue, 21 Mar 2006 16:35:43 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: OT: Senator Everett Dirksen (was Re: How to release memory ?)
Message-Id: <slrne20vtv.vpq.tadmc@magna.augustmail.com>
xhoster@gmail.com <xhoster@gmail.com> wrote:
> A hundred meg here, an hundred meg there, pretty soon you may be talking
> about real IO :).
A veiled reference to one of my most favorite quotes:
http://www.quotationspage.com/quote/170.html
But maybe the attribution is not accurate:
http://www.dirksencenter.org/print_emd_billionhere.htm
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9073
***************************************
