[30551] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 1794 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 15 00:09:51 2008

Date: Thu, 14 Aug 2008 21:09:11 -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           Thu, 14 Aug 2008     Volume: 11 Number: 1794

Today's topics:
    Re: Backreferences: alias vs copy <ced@blv-sam-01.ca.boeing.com>
    Re: Backreferences: alias vs copy xhoster@gmail.com
    Re: Backreferences: alias vs copy <ced@blv-sam-01.ca.boeing.com>
    Re: Backreferences: alias vs copy xhoster@gmail.com
    Re: Backreferences: alias vs copy <mjcarman@mchsi.com>
    Re: Backreferences: alias vs copy <mjcarman@mchsi.com>
    Re: Backreferences: alias vs copy <someone@example.com>
    Re: CLPM - a help group? <kkeller-usenet@wombat.san-francisco.ca.us>
    Re: CLPM - a help group? <john@castleamber.com>
    Re: perlish way for ( 0 .. $n) , but downcounting <whynot@pozharski.name>
    Re: perlish way for ( 0 .. $n) , but downcounting <mjcarman@mchsi.com>
    Re: The Importance of Terminology's Quality <jwkenne@attglobal.net>
        This is very OT, and its just a request. It has to do w sln@netherlands.com
    Re: This is very OT, and its just a request. It has to  <mjcarman@mchsi.com>
    Re: Tone generation question plus Windows XP and Vista  <edgrsprj@ix.netcom.com>
    Re: Tone generation question plus Windows XP and Vista  <edgrsprj@ix.netcom.com>
    Re: vec() in lvalue sub <sreservoir@gmail.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Thu, 14 Aug 2008 11:15:02 -0700 (PDT)
From: "comp.lang.c++" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Backreferences: alias vs copy
Message-Id: <316ea053-71a6-4943-8a29-fc0d55a59284@b30g2000prf.googlegroups.com>

On Aug 10, 8:04 am, Michael Carman <mjcar...@mchsi.com> wrote:
> In a separate thread someone recently asked what happens if they modify
> the variable in a 'while ($var =~ /pattern/g)' loop. In crafting a
> sample program I noticed something that surprised me a little:
>
>   my $s = 'abc';
>
>   while ($s =~ /(\w)/g) {
>     print "$1 - ";
>     $s = 'xyz' if $1 eq 'b';
>     print "$1\n";
>   }
>   __END__
>   a - a
>   b - y
>   x - x
>   y - y
>   z - z
>
> In the second result, you can see that the value of $1 changes after
> reassigning $s. Its value becomes the text from the new string at the
> position corresponding to the match against the old one. This makes it
> pretty clear that $1 is actually an alias instead of a copy but I can't
> find this documented anywhere.
>

I can't find anything completely
explicit but the performance penalty would be prohibitive. There'd be
a double whammy if
the backref. was captured but not used afterwards.

> That made me wonder what would happen if the new string was shorter than
> the match position in the old one. Consider
>
>   my $s = 'abc';
>
>   while ($s =~ /(\w)/g) {
>     print "$1 - ";
>     $s = 'x' if $1 eq 'c';
>     print "$1\n";
>   }
>   __END__
>   a - a
>   b - b
>   c - c  # <--
>   x - x
>
> as well as:
>
>   my $s = 'abc';
>
>   while ($s =~ /(\w)/g) {
>     print "$1 - ";
>     $s = 'xy' if $1 eq 'c';
>     print "$1\n";
>   }
>   __END__
>
>   a - a
>   b - b
>   c -    # <--
>   x - x
>   y - y
>
> If that doesn't scream "NUL terminated C string!" I don't know what does.
>
> Is this documented anywhere, preferably with a caveat about using $1 and
> kin after you've changed the match string?
>

The only hint I saw was perlre's
warning that once $& is seen, the copy price tag extends to $1, $2,
etc as well:


 WARNING: Once Perl sees that you
 need one of $&, $`, or $'
 anywhere in the program, it has
 to provide them for every
 pattern match.  This may
 substantially slow your program.
 Perl uses the same mechanism to
 produce $1, $2, etc, so you
 also pay a price for each pattern
 that contains capturing parens...


That seems like a clear inference could be made that no copy occurs in
the absence of $&.

--
Charles DeRykus



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

Date: 14 Aug 2008 18:42:45 GMT
From: xhoster@gmail.com
Subject: Re: Backreferences: alias vs copy
Message-Id: <20080814144247.027$M7@newsreader.com>

"comp.lang.c++" <ced@blv-sam-01.ca.boeing.com> wrote:
> >
> > Is this documented anywhere, preferably with a caveat about using $1
> > and kin after you've changed the match string?
> >
>
> The only hint I saw was perlre's
> warning that once $& is seen, the copy price tag extends to $1, $2,
> etc as well:
>
>  WARNING: Once Perl sees that you
>  need one of $&, $`, or $'
>  anywhere in the program, it has
>  to provide them for every
>  pattern match.  This may
>  substantially slow your program.
>  Perl uses the same mechanism to
>  produce $1, $2, etc, so you
>  also pay a price for each pattern
>  that contains capturing parens...

I think you are misinterpreting that.  It goes on to say:

> But if you never use $&, $` or $', then patterns without capturing
> parentheses will not be penalized.

This seems to imply that patterns *with* capturing parentheses will be
penalized, even in the absence of $&, $` or $'.


> That seems like a clear inference could be made that no copy occurs in
> the absence of $&.

Maybe that is what is actually happening, but it seems far from clear based
on the documents.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.


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

Date: Thu, 14 Aug 2008 14:24:09 -0700 (PDT)
From: "comp.lang.c++" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Backreferences: alias vs copy
Message-Id: <7e1cf5e3-6b9b-4bdc-9e23-a1590b5a477e@1g2000pre.googlegroups.com>

On Aug 14, 11:42 am, xhos...@gmail.com wrote:
> "comp.lang.c++" <c...@blv-sam-01.ca.boeing.com> wrote:
>
> > > Is this documented anywhere, preferably with a caveat about using $1
> > > and kin after you've changed the match string?
>
> > The only hint I saw was perlre's
> > warning that once $& is seen, the copy price tag extends to $1, $2,
> > etc as well:
>
> >  WARNING: Once Perl sees that you
> >  need one of $&, $`, or $'
> >  anywhere in the program, it has
> >  to provide them for every
> >  pattern match.  This may
> >  substantially slow your program.
> >  Perl uses the same mechanism to
> >  produce $1, $2, etc, so you
> >  also pay a price for each pattern
> >  that contains capturing parens...
>
> I think you are misinterpreting that.  It goes on to say:
>
> > But if you never use $&, $` or $', then patterns without capturing
> > parentheses will not be penalized.
>
> This seems to imply that patterns *with* capturing parentheses will be
> penalized, even in the absence of $&, $` or $'.
>

No, I think capturing parens
actually copy if $& is in the
picture. Compare below with
orig. output:

my $s = 'abc';
 while ($s =~ /(\w)/g) {
   print "$&:  $1 - ";
   print "$1 - ";
   $s = 'xyz' if $1 eq 'b';
   print "$1\n";
 }
__END__
a:  a - a
b:  b - b
x:  x - x
y:  y - y
z:  z - z

--
Charles DeRykus




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

Date: 14 Aug 2008 22:08:19 GMT
From: xhoster@gmail.com
Subject: Re: Backreferences: alias vs copy
Message-Id: <20080814180822.177$N3@newsreader.com>

"comp.lang.c++" <ced@blv-sam-01.ca.boeing.com> wrote:
> On Aug 14, 11:42 am, xhos...@gmail.com wrote:
> > "comp.lang.c++" <c...@blv-sam-01.ca.boeing.com> wrote:
> >
> > > > Is this documented anywhere, preferably with a caveat about using
> > > > $1 and kin after you've changed the match string?
> >
> > > The only hint I saw was perlre's
> > > warning that once $& is seen, the copy price tag extends to $1, $2,
> > > etc as well:
> >
> > >  WARNING: Once Perl sees that you
> > >  need one of $&, $`, or $'
> > >  anywhere in the program, it has
> > >  to provide them for every
> > >  pattern match.  This may
> > >  substantially slow your program.
> > >  Perl uses the same mechanism to
> > >  produce $1, $2, etc, so you
> > >  also pay a price for each pattern
> > >  that contains capturing parens...
> >
> > I think you are misinterpreting that.  It goes on to say:
> >
> > > But if you never use $&, $` or $', then patterns without capturing
> > > parentheses will not be penalized.
> >
> > This seems to imply that patterns *with* capturing parentheses will be
> > penalized, even in the absence of $&, $` or $'.
> >
>
> No, I think capturing parens
> actually copy if $& is in the
> picture. Compare below with
> orig. output:
>
> my $s = 'abc';
>  while ($s =~ /(\w)/g) {
>    print "$&:  $1 - ";
>    print "$1 - ";
>    $s = 'xyz' if $1 eq 'b';
>    print "$1\n";
>  }

Based on my experimentation:

In the absence of /g, capturing parenthesis always copy.

In the presence of $&, capturing parenthesis always copy.

They alias only if they are used with a /g  and only if $& (etc) has not
been seen.

Odd.

If you use a string eval to inspect $&, $' or $` (so that Perl doesn't
see them coming), then those variables are set by alias vs. copy under the
same conditions the capturing parenthesis are.  And if the regex doesn't
have any capturing parenthesis, then $& etc are set by alias.  That was a
surprise; I figured they wouldn't get set at all when Perl doesn't see them
coming and there were no capturing parentheses.


Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.


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

Date: Fri, 15 Aug 2008 01:42:16 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: Backreferences: alias vs copy
Message-Id: <Y95pk.243572$TT4.111930@attbi_s22>

comp.lang.c++ wrote:
> On Aug 10, 8:04 am, Michael Carman <mjcar...@mchsi.com> wrote:
>> This makes it pretty clear that $1 is actually an alias instead of
>> a copy but I can't find this documented anywhere.
> 
> I can't find anything completely explicit but the performance penalty
> would be prohibitive.

Yes, the behavior isn't surprising at all if you think about the
implementation a little.

> WARNING: Once Perl sees that you need one of $&, $`, or $' anywhere
> in the program, it has to provide them for every pattern match.  This
> may substantially slow your program. Perl uses the same mechanism to 
> produce $1, $2, etc, so you also pay a price for each pattern that
> contains capturing parens...
> 
> That seems like a clear inference could be made that no copy occurs
> in the absence of $&.

All that says is that if you use those variables perl has to track the
prematch, match, and postmatch for every regular expression. This is
because they're set after a successful match, and when you use them perl
has no way of knowing which regex will have be the last successful one.

Capturing parens only introduce the overhead for the regexes in which
they are used because it's clear that they only apply there.

After poking around a bit more, I noticed that perlvar has this to say
in the entry for @- (@LAST_MATCH_START):

    $1 is the same as "substr($var, $-[1], $+[1] - $-[1])"

I had always read that as "is equivalent to" but it would appear that a
literal interpretation is warranted. They really are the exact same.

-mjc


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

Date: Fri, 15 Aug 2008 02:43:37 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: Backreferences: alias vs copy
Message-Id: <t36pk.243636$TT4.162707@attbi_s22>

xhoster@gmail.com wrote:
> In the absence of /g, capturing parenthesis always copy.
> 
> In the presence of $&, capturing parenthesis always copy.
> 
> They alias only if they are used with a /g  and only if $& (etc) has
> not been seen.

I see the same behavior, though I wonder if in the presence of $& it's
actually $& that's the copy and then $1 and friends alias to it instead
of to the original string. There's probably no way of knowing without
mucking through the guts.

> If you use a string eval to inspect $&, $' or $` (so that Perl
> doesn't see them coming), then those variables are set by alias vs.
> copy under the same conditions the capturing parenthesis are.

Actually, it's weirder than that:

perl -e "$_ = 'abc123'; /\d/; $_ = 'xyz789'; print qq{[$&]}"
[1]

perl -e "$_ = 'abc123'; /1/; $_ = 'xyz789'; print qq{[$&]}"
[1]

perl -e "$_ = 'abc123'; /\d/; $_ = 'xyz789'; eval 'print qq{[$&]}'"
[7]

perl -e "$_ = 'abc123'; /1/; $_ = 'xyz789'; eval 'print qq{[$&]}'"
[]

perl -e "$_ = 'abc123'; /[0-9]/; $_ = 'xyz789'; eval 'print qq{[$&]}'"
[7]

perl -e "$_ = 'abc123'; /\w1/; $_ = 'xyz789'; eval 'print qq{[$&]}'"
[z7]

> And if the regex doesn't have any capturing parenthesis, then $& etc
> are set by alias.  That was a surprise; I figured they wouldn't get
> set at all when Perl doesn't see them coming and there were no
> capturing parentheses.

Agreed. I was particularly surprised by that as well, although it
depends on the pattern. If you match literal text $& isn't set; you'll
get an uninitialized value warning if you add -w.

If you match against things like /\d/, /[0-9]/, or /(?:1|2)/ then $&
does get set. Patterns such as /[1]/ and /(?:1)/ don't set it,
presumably because they can be simplified to a literal /1/.

It appears that the aliasing (at least for a stealth $&) is a side
effect of the regex engine potentially needing to backtrack. I suspect
that for the literal matches perl is calling index() to look for a
substring instead of invoking the regex engine.

It's possible that the behavior of $1 is the result of a similar
implementation detail/optimization. I'm hesitant to call it a bug,
though it might be.

-mjc


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

Date: Fri, 15 Aug 2008 03:37:46 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Backreferences: alias vs copy
Message-Id: <eS6pk.184435$gc5.99709@pd7urf2no>

Michael Carman wrote:
> 
> After poking around a bit more, I noticed that perlvar has this to say
> in the entry for @- (@LAST_MATCH_START):
> 
>     $1 is the same as "substr($var, $-[1], $+[1] - $-[1])"
> 
> I had always read that as "is equivalent to" but it would appear that a
> literal interpretation is warranted. They really are the exact same.

They are not *exactly* the same.  You can assign to substr($var, $-[1], 
$+[1] - $-[1]) but you cannot assign to $1.



John
-- 
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order.                            -- Larry Wall


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

Date: Thu, 14 Aug 2008 11:21:54 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: CLPM - a help group?
Message-Id: <3n9en5xg7r.ln2@goaway.wombat.san-francisco.ca.us>

On 2008-08-14, Justin C <justin.0805@purestblue.com> wrote:
>
> Al Qaeda, selling cookies door-to-door, dressed as boy scouts,
> apparently raising money for Georgian orphans doesn't make Al Qaeda a
> charitable organisation either. They're still terrorists. 

Is al-Qaeda the next Nazis?  Because this thread so needs to end.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information



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

Date: 14 Aug 2008 18:44:58 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: CLPM - a help group?
Message-Id: <Xns9AFA8BDE44C0castleamber@130.133.1.4>

Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

> On 2008-08-14, Justin C <justin.0805@purestblue.com> wrote:
>>
>> Al Qaeda, selling cookies door-to-door, dressed as boy scouts,
>> apparently raising money for Georgian orphans doesn't make Al Qaeda a
>> charitable organisation either. They're still terrorists. 
> 
> Is al-Qaeda the next Nazis?  Because this thread so needs to end.

Rest assured, it will end around Wednesday, next week. Ten days later a 
new discussion will start, this time the topic will be: "Why are regular 
expressions unreadable in PERL?"

-- 
John    http://johnbokma.com/ - Hacking & Hiking in Mexico

Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html


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

Date: Thu, 14 Aug 2008 22:20:25 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: perlish way for ( 0 .. $n) , but downcounting
Message-Id: <p4den5xgfa.ln2@carpet.zombinet>

hofer <blabla@dungeon.de> wrote:
*SKIP*
> for the reverse I'd hesitate to use reverse() as it creates probably
> the entire list first

Don't guess, benchmark first!

/proc/[number]/statm                                                       
Provides  information about memory status in pages.  The columns are:
	size	total program size
	resident resident set size
	share	shared pages                                            
	text	text (code)
	lib	library
	data	data/stack
	dt	dirty pages (unused in Linux 2.6)

21:48:38 65 [2:0]$ perl -wle '
@x = (0 .. 10000); open $h, "</proc/$$/statm"; print <$h>'
Name "main::x" used only once: possible typo at -e line 1.
1000 498 275 256 0 307 0

21:49:22 66 [2:0]$ perl -wle '
@x = reverse (0 .. 10000); open $h, "</proc/$$/statm"; print <$h>'
Name "main::x" used only once: possible typo at -e line 1.
1000 500 277 256 0 307 0

21:49:28 67 [2:0]$ perl -wle '
@x = (0 .. 10000); @x = @x; open $h, "</proc/$$/statm"; print <$h>'
1001 497 275 256 0 308 0

21:49:35 68 [2:0]$ perl -wle '
@x = (0 .. 10000); @x = reverse @x; open $h, "</proc/$$/statm"; print <$h>'
1000 498 277 256 0 307 0

21:49:41 69 [2:0]$ perl -wle '
@x = (0 .. 10000); $_++ foreach @x; open $h, "</proc/$$/statm"; print <$h>'
1000 501 279 256 0 307 0

21:50:14 70 [2:0]$ perl -wle '
@x = (0 .. 10000); $_++ foreach reverse @x;
open $h, "</proc/$$/statm"; print <$h>'
1001 503 280 256 0 308 0

21:50:22 71 [2:0]$ perl -wle '
@x = (0 .. 10000); $_++ while $_ = shift @x;
open $h, "</proc/$$/statm"; print <$h>'
1000 501 279 256 0 307 0

If you think that the last does what it's intended to do, then you (me?)
are wrong. No fscking way! It's B<foreach>!

22:06:25 80 [2:0]$ perl -wle '
@x = (0 .. 10000); while(1) { shift @x; @x or last };
open $h, "</proc/$$/statm"; print <$h>'
1001 505 283 256 0 308 0

Though that one does.  As you can see neither memory is released back
(just checked, B<undef> doesn't release too), no any significant
increase.  Just for clarity:

22:08:14 83 [2:0]$ perl -wle '
@x = (0 .. 1); open $h, "</proc/$$/statm"; print <$h>'
Name "main::x" used only once: possible typo at -e line 1.
831 338 274 256 0 138 0

Appending C<print scalar @x> in each case is left as an exercise for
courious reader (BTW, how to say that abreviated?)

*CUT*

-- 
Torvalds' goal for Linux is very simple: World Domination


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

Date: Fri, 15 Aug 2008 02:46:41 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: perlish way for ( 0 .. $n) , but downcounting
Message-Id: <l66pk.243639$TT4.90068@attbi_s22>

Eric Pozharski wrote:
> 
> Appending C<print scalar @x> in each case is left as an exercise for
> courious reader (BTW, how to say that abreviated?)

print 0+@x;

-mjc


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

Date: Thu, 14 Aug 2008 18:33:30 -0400
From: John W Kennedy <jwkenne@attglobal.net>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <48a4b2ba$0$20923$607ed4bc@cv.net>

Robert Maas, http://tinyurl.com/uh3t wrote:
> John W Kennedy <jwke...@attglobal.net> wrote:
> JWK> Into the 60s, indeed, there were still machines being made
> JWK> that had no instruction comparable to the mainframe BASx/BALx
> JWK> family, or to Intel's CALL. You had to do a subprogram call by
> JWK> first overwriting the last instruction of what you were
> JWK> calling with a branch instruction that would return back to
> JWK> you.
> 
> That's not true, that you needed to do that, that there was no
> other way available. The subroutine linkage I invented for S.P.S.
> (Symbolic Programming System, i.e. IBM 1620 assembly language) was
> to reserve a 5-digit space immediately before the subroutine entry
> point for storing the return address. So the caller needed to know
> only one address, the entry point, and do both store-return-address
> and jump relative to that address, rather than needing to know both
> the entry point and the last-instruction-JUMP-needs-patch address
> as independent items of information. So calling a subroutine was
> two instructions (pseudo-code here):
>    literal[nextAdrOfSelf} -> memory[SubrEntryPoint-1]
>    jump to SubrEntryPoint
> and returning from a subroutine was two instructios:
>    copy memory[SubrEntryPoint-1] -> memory[here + 11]
>    jump to 00000 ;These zeroes replaced by return address just above
> Of course if you needed to pass parameters and/or return value,
> that was handled separately, perhaps by reserving additional
> storage just before the return address. Of course this methodology
> didn't support recursion.
> 
> So my method required one extra instruction per return point, but
> allowed multiple return points from a single subroutine, and
> allowed "encapsulation" of the relation between entry point and
> return point.
> 
> Note: On IBM 1620, instructions and forward-sweeping data records
> were addressed by their *first* digit, whereas arithmetic fields
> were addressed by their *last* digit, the low-order position, to
> support natural add-and-carry operations. Storage was decimal
> digits, with two extra bits, flag to indicate negative value (if in
> low-order position) or high-order-end (if in any other position),
> and parity. Values larger than nine were reserved for special
> purposes, such as RECORD MARK used to terminate right-sweep data
> records. Because of that, the low-order position of the return
> address and the first digit of the machine instruction at the
> subroutine entry point differed by only machine address, hence the
> SubrEntryPoint-1 instead of SubrEntryPoint-5 you would otherwise
> expect.
> 
> Hmm, I suppose if I had thought it out more at the time, I might have
> done it slightly differently:
> 
> Entry point like this:
>          jump 00000 ;Patched by caller to contain return address
>   Entry: ...(regular code)...
>           ...
> 
> Each return point like this:
>          jump Entry-12
> 
> 
> I wonder if anybody ever implemented a stack on the IBM 1620?
> Probably not, because it would take a lot more machine instructions
> to push and pop, and if you weren't writing anything recursive then
> extra work for no extra benefit except saving a few digits of
> memory if your maximum stack depth is less than the total number of
> subroutines you have loaded, except the extra instructions more
> than kill off the storage savings.
> 
> Hmm, I suppose you could have a auxilary function that serves as
> trampoline for stack-based call and return. To call, you move your
> own return address and address of subroutine to fixed locations in
> low memory then jump to the call trampoline, which pushes the
> return address onto the stack and jumps at entry address. To
> return, you just jump to the return trampoline, which pops the
> return address off the stack and jumps at it. The trampoline,
> occuping memory only *once*, could afford to have code to safely
> check for stack over/under flow.

Actually, I was thinking of the 1401. But both the 1620 and the 1401 
(without the optional Advanced Programming Feature) share the basic 
omission of any instruction that could do call-and-return without 
hard-coding an adcon with the address of the point to be returned to. 
(The Advanced Programming Feature added a 1401 instruction, Store 
B-address Register, that, executed as the first instruction of a 
subroutine, could store the return-to address.)

The 1620, oddly enough, /did/ have call instructions (Branch and 
Transfer, and Branch and Transfer Immediate) and a return instruction 
(Branch Back), but with a hard-wired stack depth of 1.

-- 
John W. Kennedy
  "When a man contemplates forcing his own convictions down another 
man's throat, he is contemplating both an unchristian act and an act of 
treason to the United States."
   -- Joy Davidman, "Smoke on the Mountain"


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

Date: Fri, 15 Aug 2008 01:23:05 GMT
From: sln@netherlands.com
Subject: This is very OT, and its just a request. It has to do with Ashton Tate Framework 2/PC World contest in the 1980's
Message-Id: <fak9a4ppiv03gkciih0lrarur9cq8n9n3g@4ax.com>

Sorry to post this here, but I only posted this here
so ignore if you don't know. This if very OT for a Perl
group.

I'm one of those people who used to enter contest's
and mail my code in for evaluation. I had different code
programs mailed into different people. Back then I didn't
really know better.

In the mid-80's I had the oppertunity to have exposure
to many different programming envivonments. And I was
paid very nicely.

I programmed a piece called "Action Memo", with things
called "Action Items", for a database.

It was very complex for those days. I have the aged
green/white gigantic printouts of the source at my home
that can be dated.

The program was written in FW II (aka: FrameWork 2 by Ashton Tate)
It was a macro language called "Fred", extremely complex in its
potential (and I used it all).

I created a program called "Action Memo", it was undefined as
to what action memo was back then. I just hoofed it and made it 
into a timed database of full faced records that were directed
to time relavent sources. Each memo was full face sheet editable,
complete with fields and time critical dependancies.

I phrased each item as an "Action Item". The database was of
action items. There was a complete management system for it.

This was in 1984, for the Las Vegas computer convention where
I enterred this for.

This was an extremely complex Framework 2 macro program. It was
all code.

I enterred the contest, Ashton Tate/PC World, mailed in the 
entire source with doc's (as was required).

Lo an behold I won second place amongst 60 contestants worldwide.

No article was written about me, no mention of the program, no
nothing.

However, I won. I got my choice of $600 (back then) software.
I didn't wan't any but I picked the full package of DBase III.
A 1 foot square qube of software and documentation (mostly doces)
that still to this day sits out in my garage unopened.

It was recently brought to my attention, that my phrases,
my software phrase descriptions and in particular "Action Memo",
"Action Item's" are used heavily in contact management software
programs.

If the usage in terms did not happen to coincide with the exact
software functionality, I would have not cared, however it is 
what I invented exactly!

I feel like Nicholas Tesla in that he invented the radio, but
Marconi got credit (patents were reversed for Tesla).

Yeah, I wrote it on a napkin with Framework 2 (Fred) but I wrote
it FIRST and I got proof. The entire construct was stolen from me.


Lotus owes me big time royalties..........

I am the inventor of Action Memo and Action Item construct's !!!!

If you think I am telling the truth, and I am, any lawyers out there
willing to take up my case?

I have not been to a lawyer. I have all the documents from Ashton Tate
for validation, as well as all the source that can be dated.


Thanks,

sln






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

Date: Fri, 15 Aug 2008 02:56:44 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: This is very OT, and its just a request. It has to do with Ashton Tate Framework 2/PC World contest in the 1980's
Message-Id: <Mf6pk.298471$yE1.107075@attbi_s21>

sln@netherlands.com wrote:
> Lotus owes me big time royalties..........
> 
> I am the inventor of Action Memo and Action Item construct's !!!!
> 
> If you think I am telling the truth, and I am, any lawyers out there
> willing to take up my case?

Do you even have a case? Did the contest rules say anything about
copyright? e.g. that you retained it, or that they were free to do
whatever they wanted with entries? It wouldn't surprise me if it had
wording indicating the latter.

-mjc


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

Date: Thu, 14 Aug 2008 20:00:47 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Tone generation question plus Windows XP and Vista information
Message-Id: <PvydnScm2vSmSDnVnZ2dnUVZ_uadnZ2d@earthlink.com>

"Joost Diepenmaat" <joost@zeekat.nl> wrote in message 
news:8763q50xb1.fsf@zeekat.nl...
> It's been part of the Win32::API modules since 2003. Did you try
>
> use Win32::kernel32; # note the module
> Win32::Beep ( $FREQUENCY, $DURATION );

I did check the documentation at the Cpan site etc. before posting that 
second note and could not find those routines in any of the modules in my 
version of Perl.  I also had PPM reload the modules just to make certain.  I 
must have missed something and will check this again.



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

Date: Thu, 14 Aug 2008 20:06:12 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Tone generation question plus Windows XP and Vista information
Message-Id: <eYydnUnmJdzgSznVnZ2dnUVZ_oLinZ2d@earthlink.com>

"John Bokma" <john@castleamber.com> wrote in message 
news:Xns9AF980A8C4B79castleamber@130.133.1.4...
> Assuming you have Active Perl, check out Win32::Sound. I've used it
> successfully in the past to play sounds (wav files).

As I reported in another note I just posted, I did check the documentation 
and went looking for these types of routines in my program.  I also tried to 
run them.  Nothing happened.  So, I will run some additional checks to see 
if I might have missed something.

I wonder if the automatic download and install modules available for the 
ActiveState version of Perl 5.10 might not have those sound generation 
routines.   Ones at the ActiveState site did not have the .exe program 
generation routines in them as far as I could tell.  I had to get them from 
the Bribes.org Web site.



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

Date: Thu, 14 Aug 2008 20:13:44 -0400
From: =?ISO-8859-1?Q?s_=B7_reservoir?= <sreservoir@gmail.com>
Subject: Re: vec() in lvalue sub
Message-Id: <g82hnt$6t3$1@aioe.org>

Big and Blue wrote:
> In 5.8.5 it also reports 1....

As it does under 5.6.3, 5.7.3, 5.8.8, 5.9.4, and 5.10.0...

> FWIW the "if (@_)" setting block never gets called (put a print 
> statement in it - it never happens).  The first call only has 2 
> parameters.  Hence $str is never set, and you are actually trying to 

$str is should set - the ugly do if block assigns to it, not the if (@_).

> access an unset variable, which probably explains the different result 

Access to an unset variable gives a warning under -w, but it didn't.

> in and not-in the debugger.

The if (@_) block is there to let you do this:
   mess_with_bits($str, 1, 1);
and get back 0 while setting the second bit to 1.
I just copied most of it from my editor.

> It is documented that you can't have a return in an lvalue sub (e.g. 
> http://search.cpan.org/dist/perl/pod/perlsub.pod#Lvalue_subroutines__)

Though in reality, you can - you just can't assign to it if it returns 
from a return. I discovered that when I foolishly tried to do so.


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

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 1794
***************************************


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