[31140] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 2385 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 1 18:09:42 2009

Date: Fri, 1 May 2009 15:09:09 -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           Fri, 1 May 2009     Volume: 11 Number: 2385

Today's topics:
    Re: "Perl has been pretty much forgotten" says Spolsky <nat.k@gm.ml>
    Re: Dumping all Variables <rvtol+usenet@xs4all.nl>
    Re: Dumping all Variables <a_person@anyolddomain.fake>
    Re: Dumping all Variables <uri@stemsystems.com>
    Re: Dumping all Variables <cartercc@gmail.com>
    Re: Dumping all Variables <darkon.tdo@gmail.com>
    Re: I think I found a real regex bug <liarafan@xs4all.nl>
    Re: I think I found a real regex bug <uri@stemsystems.com>
    Re: I think I found a real regex bug <liarafan@xs4all.nl>
    Re: I think I found a real regex bug <uri@stemsystems.com>
    Re: I think I found a real regex bug <darkon.tdo@gmail.com>
    Re: Perl command call check <skye.shaw@gmail.com>
    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 <nat.k@gm.ml>
        simple visual c++  examples <hawash2@hotmail.com>
    Re: simple visual c++  examples <uri@stemsystems.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 01 May 2009 13:51:19 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: "Perl has been pretty much forgotten" says Spolsky
Message-Id: <chJKl.8655$WT7.7657@newsfe11.iad>

Ben Bullock wrote:

> In case anyone's interested, this is Joel Spolsky of stackoverflow.com
> on Perl:
> 
> http://www.youtube.com/watch?v=NWHfY_lvKIQ
> 
> (fast forward to segment from 39:10 to 39:25)
> 
> [This statement is not too surprising considering the general level of
> stackoverflow.com.]

Didn't visit the link/video, and who cares what some random person says? 
So what is Perl isn't the most hyped or most discussed language by a
lot of people in certain groups?  One could use Rails and Ruby on Rails
as an example to say that Perl, Python, C, C++, Java/JSP, and a bunch
of other languages have been forgotten.  Not that this link you've
provided says that, but I am betting that's in essence what it says.  I
don't even know who Joel Spolensky is, nor do I care, and I don't
believe this person (never hearing of them) is any authority on the
subject.  The fact remains, Perl is widely used by hundreds of
thousands or even millions of people every day, either as an end user
or a developer or systems administrator.  This type of article is about
on the same level as the media's desire to hype the Swine Flu panic to
get more money for commercials.


------------------------------

Date: Fri, 01 May 2009 20:13:54 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Dumping all Variables
Message-Id: <49fb3be2$0$186$e4fe514c@news.xs4all.nl>

Bigus wrote:

> Is there a way to print out all variables (scalars, hashes & arrays) 
> currently defined at any point in the execution of a script?

Why?

-- 
Ruud


------------------------------

Date: Fri, 1 May 2009 19:25:53 +0100
From: "Bigus" <a_person@anyolddomain.fake>
Subject: Re: Dumping all Variables
Message-Id: <09HKl.4143$3k7.2690@newsfe17.iad>

"Dr.Ruud" <rvtol+usenet@xs4all.nl> wrote in message 
news:49fb3be2$0$186$e4fe514c@news.xs4all.nl...
> Bigus wrote:
>
>> Is there a way to print out all variables (scalars, hashes & arrays) 
>> currently defined at any point in the execution of a script?
>
> Why?

Because I'm working on a set of badly coded scripts where loads of global 
variables exist (ie: no 'use strict' in effect) that may be modified in any 
one of numerous subroutines over three different and fairly large modules. 
I'm using Data::Dumper for specific hashes/arrays but it woul dbe nice to 
see all the variables and their values at any given point in the script (it 
might also help when we eventually get time to sort the scripts out and get 
everything scoped properly).

Bigus 




------------------------------

Date: Fri, 01 May 2009 14:46:17 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Dumping all Variables
Message-Id: <874ow4acg6.fsf@quad.sysarch.com>

>>>>> "B" == Bigus  <a_person@anyolddomain.fake> writes:

  B> "Dr.Ruud" <rvtol+usenet@xs4all.nl> wrote in message 
  B> news:49fb3be2$0$186$e4fe514c@news.xs4all.nl...
  >> Bigus wrote:
  >> 
  >>> Is there a way to print out all variables (scalars, hashes & arrays) 
  >>> currently defined at any point in the execution of a script?
  >> 
  >> Why?

  B> Because I'm working on a set of badly coded scripts where loads of
  B> global variables exist (ie: no 'use strict' in effect) that may be
  B> modified in any one of numerous subroutines over three different
  B> and fairly large modules.  I'm using Data::Dumper for specific
  B> hashes/arrays but it woul dbe nice to see all the variables and
  B> their values at any given point in the script (it might also help
  B> when we eventually get time to sort the scripts out and get
  B> everything scoped properly).

ESP::PSI tells me you have a lot of pain in your future!!

ouch!

best to scan the symbol table. you don't even need a module, just loop
over it like a hash tree (which is what it is from the code's point of
view). check each symbol for the types you want (scalars, arrays, etc)
and then call data::dumper on each one you care about.

and then start to refactor as fast as you can and get it strict
clean. for a good book on this get 'perl medic' by peter scott. it is
out of print but you can find used copies. it specificly covers
refactoring legacy perl systems.

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: Fri, 1 May 2009 11:56:02 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Dumping all Variables
Message-Id: <9cc6585f-fe26-43be-b91c-c91749c89d89@c9g2000yqm.googlegroups.com>

On May 1, 2:25=A0pm, "Bigus" <a_per...@anyolddomain.fake> wrote:
> Because I'm working on a set of badly coded scripts where loads of global
> variables exist (ie: no 'use strict' in effect) that may be modified in a=
ny
> one of numerous subroutines over three different and fairly large modules=
 .

If it were me, I might start by using strict (and warnings.)

This will (obviously) throw compile errors for undeclared variables.
Then you can declare your variables, starting with the top scope and
working your way down to the inner scopes. At least see where they are
scoped.

Another thing I might do is make control flow graphs showing the flow
of control for your program. I have found this to be a very useful
tool.

If you are a bottom up developer, I'd write drivers for your modules,
and test the routines in your modules to see if they do what they are
supposed to do. If you are a top down developer, I'd write stubs for
your called routines to see the absent functionality. I've only been
involved in a project like this a couple of times, but I've had luck
doing both and meeting in the middle.

Another thing that's worked for me is a functional style of
programming where routines only accept arguments and return values --
that is, they avoid side effects unless they specifically produce a
side effect (like 'print_comma_delimited_file(\@data_array_ref)'), and
then they only produce the side effect.

Good luck, CC.


------------------------------

Date: Fri, 1 May 2009 15:34:59 -0400
From: "darkon" <darkon.tdo@gmail.com>
Subject: Re: Dumping all Variables
Message-Id: <zcqdncJ3wZt-02bUnZ2dnUVZ_radnZ2d@supernews.com>


"Bigus" <a_person@anyolddomain.fake> wrote in message 
news:09HKl.4143$3k7.2690@newsfe17.iad...
> "Dr.Ruud" <rvtol+usenet@xs4all.nl> wrote in message 
> news:49fb3be2$0$186$e4fe514c@news.xs4all.nl...
>> Bigus wrote:
>>
>>> Is there a way to print out all variables (scalars, hashes & arrays) 
>>> currently defined at any point in the execution of a script?
>>
>> Why?
>
> Because I'm working on a set of badly coded scripts where loads of global 
> variables exist (ie: no 'use strict' in effect) that may be modified in 
> any one of numerous subroutines over three different and fairly large 
> modules. I'm using Data::Dumper for specific hashes/arrays but it woul dbe 
> nice to see all the variables and their values at any given point in the 
> script (it might also help when we eventually get time to sort the scripts 
> out and get everything scoped properly).

If you're not already using it, you might consider running them through 
perltidy just to get some decent formatting.  I once inherited a bunch of 
poorly-written programs (no strict, no warnings, every variable was global, 
no indentation) and perltidy was the first thing I did with each one.  Then 
I could read it well enough to start fixing things.

But then, you said the former programmer used modules, so that's better than 
what I had.  Maybe the formatting is already OK.



------------------------------

Date: Fri, 1 May 2009 20:19:42 +0200
From: "Mark" <liarafan@xs4all.nl>
Subject: Re: I think I found a real regex bug
Message-Id: <kOidnU-T5YiioGbUnZ2dnUVZ8jSdnZ2d@giganews.com>

"Uri Guttman" <uri@stemsystems.com> wrote in message 
news:87d4asaea7.fsf@quad.sysarch.com...

> you don't understand how /g is working.

Guess I really don't. :) I thought the new 'while' loop would start pos at
0 again. But I take it that, in reality, it only gets reset at the closure
of the outer 'if' statement.

Man, this is a rare occassion where I'm happy to be wrong. :) To think it
was a real bug would be rather unsettling.

Thanks for the clarification, though.

- Mark 



------------------------------

Date: Fri, 01 May 2009 14:52:20 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: I think I found a real regex bug
Message-Id: <87zldw8xln.fsf@quad.sysarch.com>

>>>>> "M" == Mark  <liarafan@xs4all.nl> writes:

  M> "Uri Guttman" <uri@stemsystems.com> wrote in message
  M> news:87d4asaea7.fsf@quad.sysarch.com...

  >> you don't understand how /g is working.

  M> Guess I really don't. :) I thought the new 'while' loop would start pos at
  M> 0 again. But I take it that, in reality, it only gets reset at the closure
  M> of the outer 'if' statement.

how would while know what to reset? while only checks the boolean result
and loops accordingly. it has no knowledge of the expression inside its
boolean conditional other than its final value. whereas the regex pos is
attached to the variable and you did set it with the first test. pos is
reset when the variable is modified (as you did with the .= '') so it
worked as you thought then. pos is stateful when used with /g in scalar
match contexts and you did one first and then looped so the regex
restarted after the initial first match.

the real question is why did you first do one match and then the loop?
you can just immediately loop over the regex and get the results or
nothing will happen and the loop will fail. i see this in kiddie code
all the time. they first see if an m// is good and then do an s/// with
the same regex. wasteful coding.

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: Fri, 1 May 2009 21:09:45 +0200
From: "Mark" <liarafan@xs4all.nl>
Subject: Re: I think I found a real regex bug
Message-Id: <SL-dndukFqlk1WbUnZ2dnUVZ8sydnZ2d@giganews.com>

"Uri Guttman" <uri@stemsystems.com> wrote in message 
news:87zldw8xln.fsf@quad.sysarch.com...

> the real question is why did you first do one match and then the loop?
> you can just immediately loop over the regex and get the results or
> nothing will happen and the loop will fail. i see this in kiddie code
> all the time. they first see if an m// is good and then do an s/// with
> the same regex. wasteful coding.

That was just hastily put out code, on my end, because of the panic. :)
The real idea was as follows:

# Do we have exactly 4 PostgreSQL helper processes running?

} elsif ((($_ = $ps_command) =~ s/^pgsql .+? postgres: .+$/\n/mg) != 4) {

    # If not, kill them off, one by one...

    while ($ps_command =~ /^pgsql (\d+) .+? postgres: /mg) {
        # Kill the pid in $1 here;
    }
} 



------------------------------

Date: Fri, 01 May 2009 15:20:41 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: I think I found a real regex bug
Message-Id: <87pres8wae.fsf@quad.sysarch.com>

>>>>> "M" == Mark  <liarafan@xs4all.nl> writes:

  M> "Uri Guttman" <uri@stemsystems.com> wrote in message
  M> news:87zldw8xln.fsf@quad.sysarch.com...

  >> the real question is why did you first do one match and then the loop?
  >> you can just immediately loop over the regex and get the results or
  >> nothing will happen and the loop will fail. i see this in kiddie code
  >> all the time. they first see if an m// is good and then do an s/// with
  >> the same regex. wasteful coding.

  M> That was just hastily put out code, on my end, because of the panic. :)

don't panic!! :)

  M> The real idea was as follows:

  M> # Do we have exactly 4 PostgreSQL helper processes running?

  M> } elsif ((($_ = $ps_command) =~ s/^pgsql .+? postgres: .+$/\n/mg) != 4) {

why the assignment to $_? you can directly match against the var as you
do below.

  M>    # If not, kill them off, one by one...

  M>    while ($ps_command =~ /^pgsql (\d+) .+? postgres: /mg) {
  M>        # Kill the pid in $1 here;
  M>    }
  M> } 

why not just grab the list of pids in an array and kill them from that?
then you only need one regex call and it is much simpler. something like
this (untested):

	my @pids = $ps_command =~ /^pgsql (\d+) .+? postgres: /mg ;
	if ( @pids != 4 ) {

		foreach my $pid ( @pids ) {

			kill ......
		}
	}

having a duplicate complex regex in two places is bug prone. what if the
ps output changes and you fix only one of the regexes? or if you must
have duplicates, save it in a var with a qr// first and use them
later. but my grabbing to an array is even better in this case.

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: Fri, 1 May 2009 15:37:18 -0400
From: "darkon" <darkon.tdo@gmail.com>
Subject: Re: I think I found a real regex bug
Message-Id: <8ZKdnTmOt5zy0mbUnZ2dnUVZ_o2dnZ2d@supernews.com>


"Uri Guttman" <uri@stemsystems.com> wrote in message 
news:87pres8wae.fsf@quad.sysarch.com...
>>>>>> "M" == Mark  <liarafan@xs4all.nl> writes:
>
>  M> "Uri Guttman" <uri@stemsystems.com> wrote in message
>  M> news:87zldw8xln.fsf@quad.sysarch.com...
>
>  >> the real question is why did you first do one match and then the loop?
>  >> you can just immediately loop over the regex and get the results or
>  >> nothing will happen and the loop will fail. i see this in kiddie code
>  >> all the time. they first see if an m// is good and then do an s/// 
> with
>  >> the same regex. wasteful coding.
>
>  M> That was just hastily put out code, on my end, because of the panic. 
> :)
>
> don't panic!! :)

And keep your towel handy...



------------------------------

Date: Fri, 1 May 2009 13:36:40 -0700 (PDT)
From: "Skye Shaw!@#$" <skye.shaw@gmail.com>
Subject: Re: Perl command call check
Message-Id: <248681e6-26e4-455e-8c91-4bad3067d7c5@f1g2000prb.googlegroups.com>

On Apr 30, 1:12=A0am, neilsolent <n...@solenttechnology.co.uk> wrote:
> I will just submit the commands and work out what happened
> after.

Well with system() or backticks, how do know if it's telling you that
the command doesn't exist vs. exit failure?

~ >uname
Linux
~ >perl -e'print(system("bass > /dev/null 2>&1")>>8)'
127
~ >grep '\<127\>' /usr/include/asm-generic/errno.h
#define EKEYEXPIRED     127     /* Key has expired */

Hum, not sure what that means, let=92s try something familiar:

~ >perl -e'print(system("ls nope > /dev/null 2>&1")>>8)'
2
~ >grep '\<2\>' /usr/include/asm-generic/errno-base.h '
#define ENOENT           2      /* No such file or directory */

Ah ok. Let=92s see what the exit value of an inaccessible command is on
Solaris?

~ >uname
SunOS
~ >perl -e'print(system("bass > /dev/null 2>&1")>>8)'
sh: bass: not found
1

I'd stick with the Which module.

-Skye


------------------------------

Date: Fri, 01 May 2009 14:17:17 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Perl is too slow - A statement
Message-Id: <86ws90it76.fsf@mithril.chromatico.net>

>>>>> "sln" == sln  <sln@netherlands.com> writes:

      [a great deal of rubbish]

Someone who whines about not being able to find work, alternating it
with really bad advice and really shoddy code, really has no business
lecturing other people about how businesses work or about sane
development practices.

Charlton


-- 
Charlton Wilbur
cwilbur@chromatico.net


------------------------------

Date: Fri, 01 May 2009 11:43:38 -0700
From: sln@netherlands.com
Subject: Re: Perl is too slow - A statement
Message-Id: <54gmv45n0ug86i602epvoplo4v5bst52uc@4ax.com>

On Fri, 01 May 2009 14:17:17 -0400, Charlton Wilbur <cwilbur@chromatico.net> wrote:

>>>>>> "sln" == sln  <sln@netherlands.com> writes:
>>On Fri, 01 May 2009 10:54:16 -0400, Charlton Wilbur <cwilbur@chromatico.net> wrote:
>>
>>>>>>>> "NK" == Nathan Keel <nat.k@gm.ml> writes:
>>>
>>>    NK> In the end, if I ever told someone that I was contracted to
>>>    NK> program for them, or my employer that, "if you want it to run
>>>    NK> better or faster, get faster systems", I'd have been quickly
>>>    NK> ripped a "new one" or fired, and definitely lost the respect of
>>>    NK> the people I was on the same programming team with.  
>>>
>>>Whereas I have said as a consultant, "Look, I can spend a week tuning
>>>this code and get *maybe* a 5% increase in speed overall.  Or you can
>>>spend the same $2K you'd spend paying me for that week and get a new
>>>system to run it on, and get a 50% increase in speed across the board."
>>>Oddly enough, this seemed to win me more respect.
>>
>>Do you assume a one-off simple in-house utility program that one person
>>in a no person staff could tweek? In that case, they wouldn't spend any
>>money at all for speed enhancement, hardware or software.
>>
>>On the other hand, a sophisticated in-house system would have a support
>>staff. And as the requirements are constantly changing, software modifications,
>>be it bug fixes or enhancements are done/being worked on constantly.
>>Why hire a support staff to tell you to update your hardware as a bug fix?
>>
>>As for a hardware update to get that %50 speed increase.
>>I assume you mean adding another cpu core as in 'dual-core cpu', as
>>opposed to adding another parallel machine in a distributed processing.
>>
>>The fact is, unless your adding a Cray, this won't help a bit. The big
>>reason is that until languages can take single code path sourse and
>>convert and compile into threaded code to take advantage of the extra
>>core, the speed will actually decrease from the original.
>>
>>The limiting factor of all hardware speed is the heat of the cpu.
>>When doubling the core of the cpu you double the heat. Reducing the
>>wattage consumption in multiple cores via the wafer process, has resulted
>>in reducing each cores speed (Ghz) compared to a single core. All this to
>>maintain a maximum level of heat dissipation (wattage) when all the
>>cores are firing (stressed) on all cylinders.
>>
>>Each new rev of a cpu has actual pipelining/instruction enhancements,
>>however, some apps may benefit and some won't as app benchmarks tell us.
>>
>>The bottom line is that apps are always evolving to take advantage of new
>>cpu technology, NOT the other way around. Enhancements, re-writes, re-factor,
>>bug fixes, etc.. for all common sense reasons, are the rule, NOT the exception.
>>
>>>
>>>It's not all about hero programming.
>>
>>Ah, the *GLORY*, the hero. Do it for the glory of it. Plunging into one
>>large app enhancement after another. Yeah, if you live through the stress
>>I guess you would be a hero... when you bring home the paycheck to support
>>your wife and kids.
>>
>>>It's about getting the job done
>>>right while using as few resources as possible, and development time and
>>>powerful hardware can sometimes be exchanged for each other.  There
>>>usually comes a point where spending more money on hardware gives you a
>>>better bang for the buck than spending more money on development and
>>>optimization.
>>
>>This is NOT mutually exclusive as you portend, far from it.
>>
>>>I'd be pretty disgusted with a manager who didn't realize
>>>that.
>>>
>>>Charlton
>>
>>I didn't know that supervisors give you a choice to be disgusted.
>>Hardware is a procurement item, budgeted, and out of the control
>>of development teams. In other words, in the corp world, the
>>solution to speed up a one-off utility app by purchacing a new
>>machine would have to be approved by the business department.
>>A complete procuremnt and justification array of paper work and
>>departmental approvals would be needed, taking several weeks or
>>months for the process, costing more than the machine itself.
>>
>>So I see no argument that a simple machine upgrade alone will solve
>>speed problems.
>>
>>-sln
>
>Someone who whines about not being able to find work, alternating it
>with really bad advice and really shoddy code, really has no business
>lecturing other people about how businesses work or about sane
>development practices.
>
>Charlton

Nice defence and comeback. It sounds like the "hero programmer/manager"
made you have another disgusting day. Enjoy your job while you have it.

-sln


------------------------------

Date: Fri, 01 May 2009 13:45:19 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl is too slow - A statement
Message-Id: <EbJKl.8653$WT7.5515@newsfe11.iad>

Charlton Wilbur wrote:

>>>>>> "NK" == Nathan Keel <nat.k@gm.ml> writes:
> 
>     NK> In the end, if I ever told someone that I was contracted to
>     NK> program for them, or my employer that, "if you want it to run
>     NK> better or faster, get faster systems", I'd have been quickly
>     NK> ripped a "new one" or fired, and definitely lost the respect
>     of NK> the people I was on the same programming team with.
> 
> Whereas I have said as a consultant, "Look, I can spend a week tuning
> this code and get *maybe* a 5% increase in speed overall.  Or you can
> spend the same $2K you'd spend paying me for that week and get a new
> system to run it on, and get a 50% increase in speed across the
> board." Oddly enough, this seemed to win me more respect.

It what was the situation, that's different and I'd agree with you.

> It's not all about hero programming.

No, of course not.

> It's about getting the job done 
> right while using as few resources as possible, and development time
> and
> powerful hardware can sometimes be exchanged for each other.

Yes, sometimes.  As I said, just not every time and people that
sometimes opt for a more workable more efficient design and even
language, if it is cheaper, there's no debating.  Sometimes companies
don't want to spend more on hardware and insist it should run better on
what they have, and sometimes they are right.  Sometimes, no matter
what, you simply need to upgrade the hardware because there's going to
be a need for it anyway.

> There 
> usually comes a point where spending more money on hardware gives you
> a better bang for the buck than spending more money on development and
> optimization.  I'd be pretty disgusted with a manager who didn't
> realize that.
> 
> Charlton

I really believe that they go hand in hand anyway, since good
development and the right designs and choices are vital regardless,
else you won't be getting much more bang for your buck anyway, as I'm
sure you agree.  Every situation can be different, and I actually never
disagreed with this, but I do disagree when people say it is always
better.


------------------------------

Date: Fri, 1 May 2009 12:54:59 -0700 (PDT)
From: hoho <hawash2@hotmail.com>
Subject: simple visual c++  examples
Message-Id: <536dd3eb-4f70-440a-9e53-471d28ac5093@3g2000yqk.googlegroups.com>

www.visualcsamples.blogspot.com

contains simple visual c++ example I made them


------------------------------

Date: Fri, 01 May 2009 15:59:55 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: simple visual c++  examples
Message-Id: <87fxfo8uh0.fsf@quad.sysarch.com>

>>>>> "h" == hoho  <hawash2@hotmail.com> writes:

  h> www.visualcsamples.blogspot.com
  h> contains simple visual c++ example I made them

and your perl question is?

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: 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 2385
***************************************


home help back first fref pref prev next nref lref last post