[31134] in Perl-Users-Digest
Perl-Users Digest, Issue: 2379 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 30 00:23:11 2009
Date: Wed, 29 Apr 2009 21:14:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 29 Apr 2009 Volume: 11 Number: 2379
Today's topics:
Re: Perl is too slow - A statement <cwilbur@chromatico.net>
Re: Perl is too slow - A statement sln@netherlands.com
Re: Perl is too slow - A statement <1usa@llenroc.ude.invalid>
Re: Perl is too slow - A statement <nat.k@gm.ml>
Re: Perl is too slow - A statement <nat.k@gm.ml>
Re: Perl is too slow - A statement <nat.k@gm.ml>
Re: Perl is too slow - A statement <uri@stemsystems.com>
Re: Possible unintended interpolation of @$ in string <smallpond@juno.com>
Re: Posting to perl.beginners via google groups <nat.k@gm.ml>
Re: Sub indentation trouble <nospam-abuse@ilyaz.org>
Re: Sub indentation trouble <tadmc@seesig.invalid>
tk - optionmenu not updating values <slick.users@gmail.com>
Re: tk - optionmenu not updating values <devnull4711@web.de>
tk Optionmenu - updating options <slick.users@gmail.com>
Re: tk Optionmenu - updating options <ben@morrow.me.uk>
Re: tk Optionmenu - updating options <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 29 Apr 2009 16:16:22 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Perl is too slow - A statement
Message-Id: <86skjrjjvt.fsf@mithril.chromatico.net>
>>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes:
MV> Yes, companies can just "buy bigger computers" but at some
MV> point, that's a waste. Guess you haven't gotten the memo that
MV> companies aren't buying new systems right now. They want to
MV> extend the use of their systems another couple years.
Consider this scenario.
You go to your manager, and say, "We could develop this new project in
C, which will take a team of six programmers six months, and we predict
that it will require one server at a cost of $2000 to run. Or we could
develop it in perl, which will take a team of six programmers five
months, but we predict that one server will not be sufficient at peak
load, so we recommend two servers at $2000 each."
Question 1: How much would the programmers have to be paid per year
before choosing C would make financial sense?
Question 2: Given that your programming team is probably making a lot
more than that, how likely is your boss to go for the C solution?
That's the sort of programmer time versus computer time tradeoff that
Uri is talking about. Computer time is *cheap* compared to programmer
time. This is not an argument in favor of never optimizing, but it's an
argument in favor of using tools that reduce programmer time investment
even if they increase computer time investment.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 29 Apr 2009 13:51:50 -0700
From: sln@netherlands.com
Subject: Re: Perl is too slow - A statement
Message-Id: <m4ehv4hv7nv4f5cvksg0cml8iqjhu7ms76@4ax.com>
On Wed, 29 Apr 2009 16:16:22 -0400, Charlton Wilbur <cwilbur@chromatico.net> wrote:
>>>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes:
>
> MV> Yes, companies can just "buy bigger computers" but at some
> MV> point, that's a waste. Guess you haven't gotten the memo that
> MV> companies aren't buying new systems right now. They want to
> MV> extend the use of their systems another couple years.
>
>Consider this scenario.
>
>You go to your manager, and say, "We could develop this new project in
>C, which will take a team of six programmers six months, and we predict
>that it will require one server at a cost of $2000 to run. Or we could
>develop it in perl, which will take a team of six programmers five
>months, but we predict that one server will not be sufficient at peak
>load, so we recommend two servers at $2000 each."
>
>Question 1: How much would the programmers have to be paid per year
>before choosing C would make financial sense?
>
>Question 2: Given that your programming team is probably making a lot
>more than that, how likely is your boss to go for the C solution?
>
>That's the sort of programmer time versus computer time tradeoff that
>Uri is talking about. Computer time is *cheap* compared to programmer
>time. This is not an argument in favor of never optimizing, but it's an
>argument in favor of using tools that reduce programmer time investment
>even if they increase computer time investment.
>
>Charlton
That is total bullshit. Nobody uses C in large comercial applications.
C alone is not even used for development anymore. Legacy C library's stay intact,
and can be called from C++, but nobody uses C for new development, not even for
embedded/real-time stuff.
Perl is not used in comercial applications. Its uses are in a small niche and are
not sold because of its extreme limitations in speed, functionality and incomprehensible
syntax.
Perl is just a wrapper on the C language itself, or hadn't you noticed?
Even the mighty Expat library, written in C, the fastest flat xml parser in existence,
is 5-10 times slower when called from a Perl wrapper, the Perl interface to it.
You talk about development time and how expensive it is. You talk about buying more
cpu's. Thats absolute insanity. Your actually talking, in a 'macro' sense, what,
'distributed processing'? Sort of like, what, 'pipelining' macro code?
So let me get this straight, Perl is going to take over anything done in hardware,
specialized, like parallel matrix processor's.
Don't make me laff.
-sln
------------------------------
Date: Thu, 30 Apr 2009 00:08:35 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl is too slow - A statement
Message-Id: <Xns9BFCCCE21CA92asu1cornelledu@127.0.0.1>
Uri Guttman <uri@stemsystems.com> wrote in
news:87skjst4bd.fsf@quad.sysarch.com:
>>>>>> "NK" == Nathan Keel <nat.k@gm.ml> writes:
>
> NK> Uri Guttman wrote:
>
> >> it also shows you have no clue about what is important these
> >> days. development time is way more expensive than running time.
> >> you can always get a faster computer but you rarely can speed up a
> >> development schedule.
>
> NK> If you know the language, development time isn't an issue, so
> comparing NK> an experience C programmer (whom will have libraries
> (their own), NK> template scripts, etc. to re-use, unless they are
> an idiot) and compare NK> it to an interpreted language and
> development time, it's likely not NK> going to be a whole lot
> different. And, the compiled code, if it's NK> written well, will
> easily out perform the interpreted code.
>
> study some computer history and come back when you have finished. have
> you ever worked on a computer which actually accounted for your cpu
> time?
For a few years ;-) Haven't looked back ever since I was able to afford
my first PC.
In any case, I think the following article is somewhat related to the
point you are trying to make:
http://prog21.dadgum.com/29.html
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Wed, 29 Apr 2009 13:40:40 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl is too slow - A statement
Message-Id: <RL8Kl.100$ho7.26@newsfe10.iad>
Uri Guttman wrote:
>>>>>> "NK" == Nathan Keel <nat.k@gm.ml> writes:
>
> NK> Uri Guttman wrote:
>
> >> it also shows you have no clue about what is important these
> >> days. development time is way more expensive than running time.
> >> you can always get a faster computer but you rarely can speed up
> >> a development schedule.
>
> NK> If you know the language, development time isn't an issue, so
> comparing NK> an experience C programmer (whom will have libraries
> (their own), NK> template scripts, etc. to re-use, unless they are
> an idiot) and compare NK> it to an interpreted language and
> development time, it's likely not
> NK> going to be a whole lot different. And, the compiled code, if
> it's NK> written well, will easily out perform the interpreted code.
>
> study some computer history and come back when you have finished.
Please don't resort to acting like your view is fact and anyone that
doesn't agree with you is somehow ignorant. I "get" what you've said,
I just don't agree with it.
> have
> you ever worked on a computer which actually accounted for your cpu
> time? you don't understand my point which is well known and
> supported. cpu time used to be the major expense in those days,
> developer time is the major expense now.
That's only true to a point. Many things have changed since the 60s and
70s. Indeed, we have a lot less to worry about as developers, but
that's no excuse to be lazy or stubborn about the topic. Certainly you
must agree that some compiled programs are much better suited for some
situation and applications? If so, you can't really knock C because
Perl is quicker to develop in.
> NK> I quickly turned down the guy's offer, because he said exactly
> what you NK> did above "If people want the program to run faster,
> they can get a
> NK> faster computer". That's an awful and often ignorant attitude.
> Never NK> settle for code that's inefficient for the sake of a quick
> turn around
> NK> time. Perl is my favorite language, but if I care about speed
> (and I
> NK> mean really care), I'll plan to write it in C. If you are
> speaking NK> from experience and how "in the real world", it's
> important to consider NK> that you won't get jobs if you want to
> create the best programs, that's NK> one thing, but hopefully not
> many people have to work for shitty NK> companies that are that
> clueless (or people above them that force them NK> into that
> situation due to lack of planning or understanding the
> NK> project). But, to each their own. I just hope I never end up
> having NK> to work for someone like that, and luckily I've always
> been able to NK> tell them to f--- off.
>
> you don't get it.
I actually do, I just don't agree with your arrogant attitude.
> study some history as i said. computer power is dirt
> cheap today.
Yes, it is, but there are still limitations. If you think that slow
programs are fine, and say people should get faster systems if they
don't like it, then you're not as smart or knowledgeable as you
(clearly) like to think.
> cheaper than you realize.
Apparently you claim to know what I realize about prices on systems and
components, too? Be arrogant if you want, but don't say stupid things.
> developer cost is way more
> expensive.
Probably, yes. However, that doesn't automatically mean it's either A
(hardware) or B (development time). You MUST understand there's a
middle ground, where you want efficient and suitable code, regardless
of the hardware aspects?
> so buying more/faster computers is usually more economical
> than hiring more and better developers.
Or when any idiot can create an inefficient program that uses up all of
the CPU and/or memory and/or system I/O and your theory about faster
systems falls on its face. Plenty of people suck at coding and people
also make mistakes (in code or the design) and these things just mean
that it takes 20 minutes to crash a "faster" system, than the 5 minutes
it takes for it to crash a slower system.
> of course this isn't always
> possible but it is a very strong rule of thumb. and note, i am a speed
> freak coder.
If you say so.
Anyway, you certainly must agree that it's not always the best or viable
solution. I think that's a careless rule of thumb. My code is not
really any longer to develop than other peoples, and my code runs fast
and efficient on any system. I don't agree with the rule of getting a
faster system to account for inefficient or poor coding choices.
> most of my cpan modules (id: uri) are about doing things
> as fast as possible. and they usually succeed. :)
>
> for a starter, read the mythical man month.
>
> uri
I've read it. I've done research. I've been coding for a while (even
if not as long as you might have, I really don't know or care). I
still disagree. I think it's arrogance, ignorance, carelessness and
laziness that accounts for every situation where people's "solution" is
to upgrade a system when it's not otherwise necessary. Sometimes it
is, but if you have to because of a design choice, slow code, or choice
of language, then you should probably find a new line of work if that's
your general, generic "rule of thumb".
------------------------------
Date: Wed, 29 Apr 2009 20:33:23 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl is too slow - A statement
Message-Id: <c_8Kl.974$bi7.532@newsfe07.iad>
Dr.Ruud wrote:
> Uri Guttman wrote:
>
>> you don't get it. study some history as i said. computer power is
>> dirt cheap today. cheaper than you realize. developer cost is way
>> more expensive. so buying more/faster computers is usually more
>> economical than hiring more and better developers. of course this
>> isn't always possible but it is a very strong rule of thumb. and
>> note, i am a speed freak coder. most of my cpan modules (id: uri) are
>> about doing things as fast as possible. and they usually succeed. :)
>>
>> for a starter, read the mythical man month.
>
> Uri, please stop wasting your precious developer's time on these
> types, because they will never get it.
>
> We could also discuss algorithms that run processes in parallel that
> wastefully produce overlapping results which are then merged and
> deduped in order to get the final result much much earlier then when
> we would let a speed addict touch it. But we can't discuss them if we
> are too busy implementing them. :)
>
If you think it's a waste of time to discuss programming in a
programming news group, and think it makes sense to not look for the
best language or best programmers, instead of worrying about comparing
system costs vs. development costs, then no wonder you two are so
confused. There's nothing to "get" here. It's a matter of what's
appropriate and what options you have available. Just dismissing the
fact that some languages are better suited when they are compiled (like
C compared to Perl) is dumb (if you actually think it's going to take
"that much longer" and cost "that much more" just to code in C over
Perl). It doesn't take "that much longer" if you know C well (and that
was just an example). Most of my stuff is coded in Perl and scales
well, but there's a point when buying systems to make up for the
efficiency is going to be futile. If you agree with this, then you
must realize that "these types" DO in fact "get it". There's no hard
and fast rule.
I feel sorry for anyone that thinks buying systems is an appropriate
solution for poor decisions, when the real development time in C over
Perl isn't that much different if you have experience, intelligence and
use existing and well tested modules, libraries, code and function
templates, etc. (just like any developer would do in any language).
Or, you can think like that and jump on the Ruby on Rails bandwagon and
have everything pre-packages for you in simple ways and just call
yourself a programmer when you're only using toys other people made for
you. Then what happens when you don't have a
neat.little.function(available)?
What happens when you find that the language isn't fast enough? You buy
another system because you wanted to avoid a couple more hours of
development costs? Or do you often work with unqualified C programmers
to believe it's going to be that much more expensive and time
consuming? There are variables here that say what's better suited, and
if people don't "get it", then regardless of their arrogance, they are
the unfortunate one's. It think it's pathetic that people have to nit
pick the details of the topic and act like anyone that strives to be
the best coder are just nitpicking trivial speed that you can "buy for
less". This is not a true fact in every situation. I don't see anyone
suggesting people rock the boat with the company they work for or
contract out to, or to drop some language that works efficiently enough
as is (such as Perl) and refuse to code in anything other than C or
something, but logic is logic and it's silly to say people "don't get
it" because they disagree with you with the "default" outlook about
development costs vs. hardware. No real programmer would think this
way, but maybe you guys are just old and jaded and think whatever you
think about any topic brought up here, that you know best and your
ideals are always best, too. You, too, can be wrong (and you are about
this).
------------------------------
Date: Wed, 29 Apr 2009 20:53:42 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl is too slow - A statement
Message-Id: <ah9Kl.85$LO7.3@newsfe23.iad>
sln@netherlands.com wrote:
> On Wed, 29 Apr 2009 16:16:22 -0400, Charlton Wilbur
> <cwilbur@chromatico.net> wrote:
>
>>>>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes:
>>
>> MV> Yes, companies can just "buy bigger computers" but at some
>> MV> point, that's a waste. Guess you haven't gotten the memo that
>> MV> companies aren't buying new systems right now. They want to
>> MV> extend the use of their systems another couple years.
>>
>>Consider this scenario.
>>
>>You go to your manager, and say, "We could develop this new project in
>>C, which will take a team of six programmers six months, and we
>>predict
>>that it will require one server at a cost of $2000 to run. Or we
>>could develop it in perl, which will take a team of six programmers
>>five months, but we predict that one server will not be sufficient at
>>peak load, so we recommend two servers at $2000 each."
>>
>>Question 1: How much would the programmers have to be paid per year
>>before choosing C would make financial sense?
>>
>>Question 2: Given that your programming team is probably making a lot
>>more than that, how likely is your boss to go for the C solution?
>>
>>That's the sort of programmer time versus computer time tradeoff that
>>Uri is talking about. Computer time is *cheap* compared to programmer
>>time. This is not an argument in favor of never optimizing, but it's
>>an argument in favor of using tools that reduce programmer time
>>investment even if they increase computer time investment.
>>
>>Charlton
>
> That is total bullshit. Nobody uses C in large comercial applications.
> C alone is not even used for development anymore. Legacy C library's
> stay intact, and can be called from C++, but nobody uses C for new
> development, not even for embedded/real-time stuff.
I know of plenty of people and programs in C. Your feelings about the
matter aren't fact. I'm pretty sure "somebody" is not "nobody".
> Perl is not used in comercial applications. Its uses are in a small
> niche and are not sold because of its extreme limitations in speed,
> functionality and incomprehensible syntax.
There are commercial applications in Perl, actually (but you're right,
probably not used in "comercial" applications).
> Perl is just a wrapper on the C language itself, or hadn't you
> noticed?
A "wrapper"? Seriously?
> Even the mighty Expat library, written in C, the fastest flat
> xml parser in existence, is 5-10 times slower when called from a Perl
> wrapper, the Perl interface to it.
That's an awful comparison.
> You talk about development time and how expensive it is. You talk
> about buying more cpu's. Thats absolute insanity.
I agree with you here. Maybe I should get my head checked or reconsider
my position? *fear*
> So let me get this straight, Perl is going to take over anything done
> in hardware, specialized, like parallel matrix processor's.
I get what they are saying and why, but they have also made a poor
argument for a "standard" reaction to a problem better solved on
another level (usually anyway). Though I can't argue if the person's
boss or contracted company has unreasonable demands or limited time
frames.
> Don't make me laff.
Don't make me get a DICtiontary.
------------------------------
Date: Thu, 30 Apr 2009 00:02:43 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl is too slow - A statement
Message-Id: <878wliokkc.fsf@quad.sysarch.com>
>>>>> "NK" == Nathan Keel <nat.k@gm.ml> writes:
NK> Uri Guttman wrote:
>> study some computer history and come back when you have finished.
NK> Please don't resort to acting like your view is fact and anyone that
NK> doesn't agree with you is somehow ignorant. I "get" what you've said,
NK> I just don't agree with it.
then you don't get it. cwilbur also covered this. sorry but no more
lessons for you.
>> have you ever worked on a computer which actually accounted for
>> your cpu time? you don't understand my point which is well known
>> and supported. cpu time used to be the major expense in those days,
>> developer time is the major expense now.
NK> That's only true to a point. Many things have changed since the
NK> 60s and 70s. Indeed, we have a lot less to worry about as
NK> developers, but that's no excuse to be lazy or stubborn about the
NK> topic. Certainly you must agree that some compiled programs are
NK> much better suited for some situation and applications? If so,
NK> you can't really knock C because Perl is quicker to develop in.
you still don't get it. sorry. it is not about any particular
application. i wouldn't write an embedded rtos in 64k of ram with
perl. i would do it in assembler like i did on an lsi-11 back in
1980. hell, perl wasn't even invented back then. but given what i was
doing then on modern cpus, i would probably do it in perl as the cpu
speed is enough and the development time would be massively shorter. and
yes, i have also done those types of programs in c including a major web
crawler for northern light. so i know of something about development
time vs cpu power. can you make the same claim? me thinks not.
NK> I actually do, I just don't agree with your arrogant attitude.
no you are ignorant, vs my experience. NYAH NYAH NYAH!
now i will predict you will call me some more names. please do as it
will validate my ESP powers.
>> study some history as i said. computer power is dirt
>> cheap today.
NK> Yes, it is, but there are still limitations. If you think that
NK> slow programs are fine, and say people should get faster systems
NK> if they don't like it, then you're not as smart or knowledgeable
NK> as you (clearly) like to think.
check out my cpan modules. try to make them faster. please do and send
me patches. i will use them (if you can but you can't) and even give you
all the credit.
>> developer cost is way more
>> expensive.
NK> Probably, yes. However, that doesn't automatically mean it's either A
NK> (hardware) or B (development time). You MUST understand there's a
NK> middle ground, where you want efficient and suitable code, regardless
NK> of the hardware aspects?
boo hoo. you seem to be fighting for no reason. i never said any of
that. you don't get it again. it is the bigger picture.
>> so buying more/faster computers is usually more economical
>> than hiring more and better developers.
NK> Or when any idiot can create an inefficient program that uses up
NK> all of the CPU and/or memory and/or system I/O and your theory
NK> about faster systems falls on its face. Plenty of people suck at
NK> coding and people also make mistakes (in code or the design) and
NK> these things just mean that it takes 20 minutes to crash a
NK> "faster" system, than the 5 minutes it takes for it to crash a
NK> slower system.
MMM to the rescue. please read it. i think they have a version written
in 4th grade level english for you.
NK> Anyway, you certainly must agree that it's not always the best or
NK> viable solution. I think that's a careless rule of thumb. My
NK> code is not really any longer to develop than other peoples, and
NK> my code runs fast and efficient on any system. I don't agree with
NK> the rule of getting a faster system to account for inefficient or
NK> poor coding choices.
all rules of thumb are careless. that's why they are CALLED that. duh!!
>> for a starter, read the mythical man month.
NK> I've read it. I've done research. I've been coding for a while
NK> (even if not as long as you might have, I really don't know or
NK> care). I still disagree. I think it's arrogance, ignorance,
NK> carelessness and laziness that accounts for every situation where
NK> people's "solution" is to upgrade a system when it's not otherwise
NK> necessary. Sometimes it is, but if you have to because of a
NK> design choice, slow code, or choice of language, then you should
NK> probably find a new line of work if that's your general, generic
NK> "rule of thumb".
well, then you get to manage a group of perfect coders who all do what
you want to do in zero time (just like Quantum::Superpostions! :). and
you will make tons of money. otherwise you are stuck in the same
boat. you haven't experienced the real world yet it seems. good luck in
your fantasy.
as for my business it is recruiting and placing perl developers. i don't
think i will ask you for your resume in the near (or far)
future. claiming you know all this but not understanding it is not a
skill i would promote to my clients.
have the appropriate amount of fun!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 29 Apr 2009 10:32:29 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Possible unintended interpolation of @$ in string
Message-Id: <dec84301-e5e3-46a6-b24d-6407ec84eb6e@w31g2000prd.googlegroups.com>
On Apr 28, 10:38 pm, jida...@jidanni.org wrote:
> Perl warns here,
> $ echo o|perl -plwe 's/./@@@@$&/'
> Possible unintended interpolation of @$ in string at -e line 1.
> @@@&
> Perhaps it should also warn here:
> $ echo o|perl -plwe 's/(.)/@@@@$1/'
> @@@
>
> If so please submit a bug for me, because my address is blocked from
> perl.org.
I don't know how perl could be expected to know what was intended.
@$ seems to be cromulent.
perl -we '$$[0]="That is"; $$[1]="messed up"; print join " ",@$'
That is messed up
------------------------------
Date: Wed, 29 Apr 2009 20:36:00 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Posting to perl.beginners via google groups
Message-Id: <A09Kl.1009$bi7.562@newsfe07.iad>
Sherm Pendley wrote:
> Nathan Keel <nat.k@gm.ml> writes:
>
>> Good grief, you people will argue about anything
>
> You must be new here! Welcome to usenet. :-)
>
> sherm--
>
Not new at all. While I took a break away from usenet for a while, I
recall the names of people that are involved in this as professional
Perl coders and it's still a little disappointing to see wasteful
contributions. I think people build a name and some respect here and
then they start getting too confortable and feel it's acceptable for
them to bitch and whine and moan and argue and debate about pointless,
off topic things. Not that I'm helping to contribute anything more
useful by replying, but it really gets old. I'm starting to remember
why usenet is dying and why I stopped bothering.
------------------------------
Date: Wed, 29 Apr 2009 21:19:58 GMT
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Sub indentation trouble
Message-Id: <slrngvhhgn.pek.nospam-abuse@chorin.math.berkeley.edu>
On 2009-04-29, Julien K. <bozo_le_clown@wherever.you.want.com> wrote:
>> As you see, there is some code to detect that `{' follows `if', and
>> indent accordingly. Apparently, there is no such code to recognize
>> that `{' follows `sub'.
>
> Like Uri said in another part of the thread, this is not observable when
> one writes:
><<<<<
> sub test {
> # stuff
> }
>>>>>>
Very observable. Just have `{' at start of line. ;-)
>> This should be considered a bug (all indentation of continuation lines
>> which CPerl is putting itself should be "undoable" when it tries to indent
>> following lines).
> Correct me if I'm wrong, but a prototyped 'sub' should behave like a if
> block alone:
><<<<<
> sub test ($$)
> { my ($a,$b) = @_ ;
> #...
> }
I have no idea what your "should" means here...
> "easy-to-visualize matching of paired delimiters" is exactly why I like
> this style, the corresponding braces are vertically aligned, as nothing
> crosses their column. Well, having matching delimiters colored helps too...
This is not easier to visualize than when `}' matches `sub', but
breaks other requirements... Hmm, on the other hand, since you cuddle
the code after `{', it takes the same amount of lines as when `{' us
cuddled after `sub'... So, when following my requirements, the only
problem with your style is that the minimal indent is 4, which is not
in any way critical.
Yours,
Ilya
------------------------------
Date: Wed, 29 Apr 2009 16:44:05 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Sub indentation trouble
Message-Id: <slrngvhih5.n4n.tadmc@tadmc30.sbcglobal.net>
Julien K. <bozo_le_clown@wherever.you.want.com> wrote:
^^^^^^^^
^^^^^^^^
It is bad form to masquerade as a domain that you do not have
permission to use...
> BTW what's wrong with this in your opinion:
><<<<<
> sub test
> { my ($self) = @_ ;
> # stuff
> return ($var) ;
> }
That appears to be a (poor) modification to the Whitesmiths style.
http://en.wikipedia.org/wiki/Indent_style
> I find this indent scheme very easy to read.
<religion>
If it ain't 1TBS, it ain't shit.
</religion>
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 29 Apr 2009 09:40:56 -0700 (PDT)
From: Slickuser <slick.users@gmail.com>
Subject: tk - optionmenu not updating values
Message-Id: <3744d844-0f5f-4d10-b0b8-2631f59a3f71@v1g2000prd.googlegroups.com>
I can get A & B show fine.
But once I update the @list, it doesn't show the current value from
the array. Any help?
Thanks.
@list = ("A","B");
$mw->Optionmenu
(
-variable => \$var,
-options => [@list]
)->grid
(
-row => 1,
-column => 1,
);
@list = ("C","D");
$mw->update;
------------------------------
Date: Thu, 30 Apr 2009 00:53:21 +0200
From: Frank Seitz <devnull4711@web.de>
Subject: Re: tk - optionmenu not updating values
Message-Id: <75s42tF196c2lU1@mid.individual.net>
Slickuser wrote:
> I can get A & B show fine.
> But once I update the @list, it doesn't show the current value from
> the array. Any help?
>
> Thanks.
>
> @list = ("A","B");
>
> $mw->Optionmenu
> (
> -variable => \$var,
> -options => [@list]
> )->grid
> (
> -row => 1,
> -column => 1,
> );
> @list = ("C","D");
>
> $mw->update;
Try: -options => \@list
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
------------------------------
Date: Tue, 28 Apr 2009 23:48:55 -0700 (PDT)
From: Slickuser <slick.users@gmail.com>
Subject: tk Optionmenu - updating options
Message-Id: <b04b4b1a-a0da-4641-a3f4-b39abfc2aff6@y33g2000prg.googlegroups.com>
my @options2 = ("A","B");
$mw->Optionmenu
(
-variable => \my $var,
-options => [@options2],
-justify => 'left'
)->grid
(
-row => 1,
-column => 1,
-sticky => 'nw'
);
Initial, I can see "A" & "B" from the drop down list.
Later in the coe, I modify the options2 array.
@options2 = ("C","D");
The gui is not update with the new value. How can I update this?
I tried $mw->update; doesn't work either.
------------------------------
Date: Thu, 30 Apr 2009 02:22:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: tk Optionmenu - updating options
Message-Id: <44bnc6-lp9.ln1@osiris.mauzo.dyndns.org>
Quoth Slickuser <slick.users@gmail.com>:
> my @options2 = ("A","B");
> $mw->Optionmenu
> (
> -variable => \my $var,
> -options => [@options2],
> -justify => 'left'
> )->grid
> (
> -row => 1,
> -column => 1,
> -sticky => 'nw'
> );
>
> Initial, I can see "A" & "B" from the drop down list.
> Later in the coe, I modify the options2 array.
> @options2 = ("C","D");
>
> The gui is not update with the new value. How can I update this?
I think you need to read perlreftut until you understand it. Your
immediate problem here is that [@options2] makes a copy of @options2, so
updating @options2 won't change the copy. You want \@options2, which
just takes a ref.
Ben
------------------------------
Date: Wed, 29 Apr 2009 19:22:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: tk Optionmenu - updating options
Message-Id: <1d2iv4lq45rnhvfi900n6psievt0dnu075@4ax.com>
Slickuser <slick.users@gmail.com> wrote:
Without ever having used Perl TK...
>my @options2 = ("A","B");
>$mw->Optionmenu
> (
> -variable => \my $var,
> -options => [@options2],
... here you are assigning a copy(!) of the values(!) of @options2 ...
> -justify => 'left'
> )->grid
> (
> -row => 1,
> -column => 1,
> -sticky => 'nw'
> );
>
>Initial, I can see "A" & "B" from the drop down list.
>Later in the coe, I modify the options2 array.
>@options2 = ("C","D");
>The gui is not update with the new value.
Of course not. The array @options2 has no relevance to $mw except that
at one point in its past the values at that time of @options were used
to set some options of $mw.
>How can I update this?
>I tried $mw->update; doesn't work either.
I don't know what $mw->update does, but I guess you will have to submit
the new values. How should it know what new values to use without you
telling it which values to use.
Maybe, just maybe, -options accepts a reference. In that case you could
just pass a reference to $options2 when creating the original menu.
jue
------------------------------
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 V11 Issue 2379
***************************************
