From verify at eBay.com Wed Oct 5 02:22:37 2005
From: verify at eBay.com (verify@eBay.com)
Date: Wed, 5 Oct 2005 07:22:37 +0700
Subject: [Compiler-sig] Verification
Message-ID: <200510050022.j950MbLo017985@localhost.localdomain>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051005/266d9518/attachment.htm
From verify at eBay.com Wed Oct 5 12:26:32 2005
From: verify at eBay.com (verify@eBay.com)
Date: Wed, 5 Oct 2005 17:26:32 +0700
Subject: [Compiler-sig] Verification
Message-ID: <200510051026.j95AQWs5005272@localhost.localdomain>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051005/1eab170e/attachment.htm
From verify at eBay.com Wed Oct 5 12:26:36 2005
From: verify at eBay.com (verify@eBay.com)
Date: Wed, 5 Oct 2005 17:26:36 +0700
Subject: [Compiler-sig] Verification
Message-ID: <200510051026.j95AQaNp005306@localhost.localdomain>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051005/05ef5908/attachment.html
From verify at eBay.com Wed Oct 5 12:26:43 2005
From: verify at eBay.com (verify@eBay.com)
Date: Wed, 5 Oct 2005 17:26:43 +0700
Subject: [Compiler-sig] Verification
Message-ID: <200510051026.j95AQhha005391@localhost.localdomain>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051005/40a65e9c/attachment.htm
From administrator at e-gold.com Thu Oct 6 17:47:30 2005
From: administrator at e-gold.com (E-gold)
Date: Thu, 06 Oct 2005 11:47:30 -0400
Subject: [Compiler-sig] Problems reguarding your account
Message-ID: <E1ENXxy-0002fx-KU@web1.hrhost.net>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051006/406b61af/attachment.html
From VpZ2304 at yahoo.com Sat Oct 8 02:09:49 2005
From: VpZ2304 at yahoo.com (VpZ2304@yahoo.com)
Date: Sat, 08 Oct 2005 02:09:49
Subject: [Compiler-sig] compiler-sig
Message-ID: <20051007181249.ABAE21157C@barracuda-FIGHT-SPAM.dimage.com>
A non-text attachment was scrubbed...
Name: not available
Type: multipart/related
Size: 2216 bytes
Desc: not available
Url : http://mail.python.org/pipermail/compiler-sig/attachments/20051008/6e5b0d36/attachment.bin
From porno at PornoStar.com Sat Oct 8 13:38:47 2005
From: porno at PornoStar.com (Porno Admin)
Date: Sat, 8 Oct 2005 13:38:47 +0200 (CEST)
Subject: [Compiler-sig] You've received a photo with Top 10 sexy women in
the world
Message-ID: <20051008113847.112BA763B30@inkognito.de>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051008/0587201d/attachment.html
From zhu_dave at yahoo.com Sat Oct 8 23:57:43 2005
From: zhu_dave at yahoo.com (Dave)
Date: Sat, 8 Oct 2005 14:57:43 -0700 (PDT)
Subject: [Compiler-sig] Bytecode
Message-ID: <20051008215743.80812.qmail@web30610.mail.mud.yahoo.com>
Hello All,
I would like to gather some information on Python's runtime performance. As far as I understand, it deals with a lot of string objects. Perhaps, it requires a lot of string processing during program execution. So, I wrote a simple program which does simple operations on a class object. Then, I disassembled the code and looked at the bytecode. Here is what I couldn't understand:
For example, myClass.variable1 is disassembled as follows:
LOAD_FAST 1 (myClass)
LOAD_ATTR 4 (variable1)
What I found out is that LOAD_ATTR namei replaces the top of the stack (TOS) with getattr(TOS, co_names[namei]). My question is:
In this example, does it need any string processing to access co_names[variable1]? Or does getattr function need any string processing?
Thanks a lot for your help!
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051008/ae28bb7d/attachment.html
From porno at PornoStar.com Sun Oct 9 14:38:47 2005
From: porno at PornoStar.com (Porno Admin)
Date: Sun, 9 Oct 2005 14:38:47 +0200 (CEST)
Subject: [Compiler-sig] You've received a photo with Top 10 sexy women in
the world
Message-ID: <20051009123847.B5A437A1260@inkognito.de>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051009/3e55b364/attachment.html
From security at eBay.com Tue Oct 11 18:51:19 2005
From: security at eBay.com (eBay request)
Date: Tue, 11 Oct 2005 12:51:19 -0400
Subject: [Compiler-sig] Please follow the Member Verification Procedure
(Second Notice)
Message-ID: <1129049479.17398.qmail@eBay.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051011/70828cf9/attachment.html
From service at paypal.com Fri Oct 14 19:42:01 2005
From: service at paypal.com (service@paypal.com)
Date: Sat, 15 Oct 2005 02:42:01 +0900
Subject: [Compiler-sig] Paypal Update Account
Message-ID: <200510141742.j9EHg1bk025255@tbontb.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051015/2511e946/attachment.htm
From nas at arctrix.com Wed Oct 19 21:52:32 2005
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 19 Oct 2005 13:52:32 -0600
Subject: [Compiler-sig] merging branches
In-Reply-To: <20051019190008.GA31686@mems-exchange.org>
References: <87d5m7bog7.fsf@hydra.bayview.thirdcreek.com>
<20051015005533.GA17774@mems-exchange.org>
<87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com>
<20051015183855.GA28324@mems-exchange.org>
<e8bf7a530510151710y4436e514ta53adae5247251f9@mail.gmail.com>
<87acha5et8.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510152226x66ddf9e0n979ee6b5410b3af0@mail.gmail.com>
<87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510190828u28fafbf9g148d0c0b8dc8515a@mail.gmail.com>
<20051019190008.GA31686@mems-exchange.org>
Message-ID: <20051019195232.GA31857@mems-exchange.org>
[Note: compiler-sig added to Cc list]
On Wed, Oct 19, 2005 at 01:00:08PM -0600, Neil Schemenauer wrote:
> On Wed, Oct 19, 2005 at 11:28:06AM -0400, Jeremy Hylton wrote:
> > test_02_arigo (__main__.TraceTestCase) ... FAIL
>
> This one fails because the new compiler does dead code elimination
> for "while 0" but not for "if 0". I've added optimization for "if
> 0" and disabled the "while 0" optimization for now.
Oops, the "if 0" optimization is tricker than I thought. The new
compiler needs something like look_for_offending_return() to detect
illegal "return" statements inside generator functions. It's harder
to do in the new compiler because nodes cannot be treated
generically (the look_for_offending_return() is pretty simple and
just self recurses).
This check needs to be done after the symtable does its pass
(symtable_visit_expr and friends). I wonder if it would be a good
idea to add another general pass that runs between the symtable
building and the code generation. Initially it would only check for
illegal return statements but if we wanted to add pychecker type
stuff in the future then that would seem to be the place to do it.
Am I making this more complicated then it needs to be? Maybe I'm
missing some easy way to write a look_for_offending_return()
equivalent.
Neil
From jeremy at alum.mit.edu Wed Oct 19 23:08:11 2005
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 19 Oct 2005 17:08:11 -0400
Subject: [Compiler-sig] merging branches
In-Reply-To: <20051019195232.GA31857@mems-exchange.org>
References: <87d5m7bog7.fsf@hydra.bayview.thirdcreek.com>
<87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com>
<20051015183855.GA28324@mems-exchange.org>
<e8bf7a530510151710y4436e514ta53adae5247251f9@mail.gmail.com>
<87acha5et8.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510152226x66ddf9e0n979ee6b5410b3af0@mail.gmail.com>
<87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510190828u28fafbf9g148d0c0b8dc8515a@mail.gmail.com>
<20051019190008.GA31686@mems-exchange.org>
<20051019195232.GA31857@mems-exchange.org>
Message-ID: <e8bf7a530510191408h251bb6fcldab21ec250dd84d4@mail.gmail.com>
I think you're right that there is no way to treat nodes generically.
Perhaps we should generate some generic traversal code-- something
that takes an AST node and a function pointer of visitor functions.
It walks the AST and calls each visitor function as the node is
encountered (the function could be NULL in which case nothing is
done). Then it would be easy to write little analyses like the one
for if 0:.
Jeremy
On 10/19/05, Neil Schemenauer <nas at arctrix.com> wrote:
> [Note: compiler-sig added to Cc list]
>
> On Wed, Oct 19, 2005 at 01:00:08PM -0600, Neil Schemenauer wrote:
> > On Wed, Oct 19, 2005 at 11:28:06AM -0400, Jeremy Hylton wrote:
> > > test_02_arigo (__main__.TraceTestCase) ... FAIL
> >
> > This one fails because the new compiler does dead code elimination
> > for "while 0" but not for "if 0". I've added optimization for "if
> > 0" and disabled the "while 0" optimization for now.
>
> Oops, the "if 0" optimization is tricker than I thought. The new
> compiler needs something like look_for_offending_return() to detect
> illegal "return" statements inside generator functions. It's harder
> to do in the new compiler because nodes cannot be treated
> generically (the look_for_offending_return() is pretty simple and
> just self recurses).
>
> This check needs to be done after the symtable does its pass
> (symtable_visit_expr and friends). I wonder if it would be a good
> idea to add another general pass that runs between the symtable
> building and the code generation. Initially it would only check for
> illegal return statements but if we wanted to add pychecker type
> stuff in the future then that would seem to be the place to do it.
>
> Am I making this more complicated then it needs to be? Maybe I'm
> missing some easy way to write a look_for_offending_return()
> equivalent.
>
> Neil
>
From nas at arctrix.com Wed Oct 19 23:22:26 2005
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 19 Oct 2005 15:22:26 -0600
Subject: [Compiler-sig] merging branches
In-Reply-To: <e8bf7a530510191408h251bb6fcldab21ec250dd84d4@mail.gmail.com>
References: <87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com>
<20051015183855.GA28324@mems-exchange.org>
<e8bf7a530510151710y4436e514ta53adae5247251f9@mail.gmail.com>
<87acha5et8.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510152226x66ddf9e0n979ee6b5410b3af0@mail.gmail.com>
<87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510190828u28fafbf9g148d0c0b8dc8515a@mail.gmail.com>
<20051019190008.GA31686@mems-exchange.org>
<20051019195232.GA31857@mems-exchange.org>
<e8bf7a530510191408h251bb6fcldab21ec250dd84d4@mail.gmail.com>
Message-ID: <20051019212226.GA32325@mems-exchange.org>
On Wed, Oct 19, 2005 at 05:08:11PM -0400, Jeremy Hylton wrote:
> I think you're right that there is no way to treat nodes generically.
> Perhaps we should generate some generic traversal code-- something
> that takes an AST node and a function pointer of visitor functions.
> It walks the AST and calls each visitor function as the node is
> encountered (the function could be NULL in which case nothing is
> done). Then it would be easy to write little analyses like the one
> for if 0:.
Yes, I was thinking of doing that but worried that I might be
overdesigning things. Do you think that it's okay to have each
little analysis do its own traversal or should we try to group them?
Maybe that's premature optimization. However, I wonder how much
slower the new compiler is vs the old.
Neil
From service at paypal.com Wed Oct 19 21:36:04 2005
From: service at paypal.com (accounting@paypal.com)
Date: Wed, 19 Oct 2005 14:36:04 -0500
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <200510191936.j9JJa4o2007634@rackserver6.xurpas.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051019/6312888b/attachment.html
From jeremy at alum.mit.edu Thu Oct 20 00:00:22 2005
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 19 Oct 2005 18:00:22 -0400
Subject: [Compiler-sig] merging branches
In-Reply-To: <20051019212226.GA32325@mems-exchange.org>
References: <87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510151710y4436e514ta53adae5247251f9@mail.gmail.com>
<87acha5et8.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510152226x66ddf9e0n979ee6b5410b3af0@mail.gmail.com>
<87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510190828u28fafbf9g148d0c0b8dc8515a@mail.gmail.com>
<20051019190008.GA31686@mems-exchange.org>
<20051019195232.GA31857@mems-exchange.org>
<e8bf7a530510191408h251bb6fcldab21ec250dd84d4@mail.gmail.com>
<20051019212226.GA32325@mems-exchange.org>
Message-ID: <e8bf7a530510191500t4b287e27g8b63c348c367e86b@mail.gmail.com>
On 10/19/05, Neil Schemenauer <nas at arctrix.com> wrote:
> On Wed, Oct 19, 2005 at 05:08:11PM -0400, Jeremy Hylton wrote:
> > I think you're right that there is no way to treat nodes generically.
> > Perhaps we should generate some generic traversal code-- something
> > that takes an AST node and a function pointer of visitor functions.
> > It walks the AST and calls each visitor function as the node is
> > encountered (the function could be NULL in which case nothing is
> > done). Then it would be easy to write little analyses like the one
> > for if 0:.
>
> Yes, I was thinking of doing that but worried that I might be
> overdesigning things. Do you think that it's okay to have each
> little analysis do its own traversal or should we try to group them?
> Maybe that's premature optimization. However, I wonder how much
> slower the new compiler is vs the old.
We're thinking the same way :-). I share all your concerns. Let's
try to have each do its own analysis for now, since that requires us
to write less code. If we need to combine passes later, we can figure
it out then.
We will need to be some benchmarking at some point. I think it's okay
if the compiler is a little slower (it's got to be just with the ast.c
pass), but I don't want it to be ridiculously slow :-).
Jeremy
From nnorwitz at gmail.com Thu Oct 20 04:28:22 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Wed, 19 Oct 2005 19:28:22 -0700
Subject: [Compiler-sig] merging branches
In-Reply-To: <e8bf7a530510191500t4b287e27g8b63c348c367e86b@mail.gmail.com>
References: <87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com>
<87acha5et8.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510152226x66ddf9e0n979ee6b5410b3af0@mail.gmail.com>
<87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com>
<e8bf7a530510190828u28fafbf9g148d0c0b8dc8515a@mail.gmail.com>
<20051019190008.GA31686@mems-exchange.org>
<20051019195232.GA31857@mems-exchange.org>
<e8bf7a530510191408h251bb6fcldab21ec250dd84d4@mail.gmail.com>
<20051019212226.GA32325@mems-exchange.org>
<e8bf7a530510191500t4b287e27g8b63c348c367e86b@mail.gmail.com>
Message-ID: <ee2a432c0510191928kccbe964va07d2596042f499e@mail.gmail.com>
On 10/19/05, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
>
> We will need to be some benchmarking at some point. I think it's okay
> if the compiler is a little slower (it's got to be just with the ast.c
> pass), but I don't want it to be ridiculously slow :-).
I think it's quite a bit slower (from my experience a long time ago),
but it doesn't really matter much at this point. Imports which
require compilation aren't *that* common. The real problem will be
with compiling dynamic code often. I'm sure once we bullet proof the
code we can look into improving the perf. It should be good enough
for now (famous last words :-).
n
From account at paypal.com Fri Oct 21 17:07:29 2005
From: account at paypal.com (account@paypal.com)
Date: Fri, 21 Oct 2005 10:07:29 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051021150729.EA6F421A7C47@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051021/05fc0583/attachment.htm
From account at paypal.com Fri Oct 21 17:54:59 2005
From: account at paypal.com (account@paypal.com)
Date: Fri, 21 Oct 2005 10:54:59 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051021155459.07DE021ACDCD@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051021/8cd605ba/attachment.html
From account at paypal.com Fri Oct 21 18:57:06 2005
From: account at paypal.com (account@paypal.com)
Date: Fri, 21 Oct 2005 11:57:06 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051021165706.4BD2421B7D83@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051021/fb2f809f/attachment.html
From account at paypal.com Fri Oct 21 21:23:01 2005
From: account at paypal.com (account@paypal.com)
Date: Fri, 21 Oct 2005 14:23:01 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051021192301.4125921D21E7@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051021/9a7a43aa/attachment.htm
From account at paypal.com Sat Oct 22 13:13:37 2005
From: account at paypal.com (account@paypal.com)
Date: Sat, 22 Oct 2005 06:13:37 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051022111337.3B139225609F@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051022/7b883290/attachment.html
From account at paypal.com Sun Oct 23 04:00:39 2005
From: account at paypal.com (account@paypal.com)
Date: Sat, 22 Oct 2005 21:00:39 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051023020039.4CE16231B108@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051022/33b7bf19/attachment.html
From account at paypal.com Sun Oct 23 22:22:59 2005
From: account at paypal.com (account@paypal.com)
Date: Sun, 23 Oct 2005 15:22:59 -0500 (CDT)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051023202259.864C623E331E@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051023/f27c4df5/attachment.html
From nas at arctrix.com Mon Oct 24 00:35:42 2005
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun, 23 Oct 2005 16:35:42 -0600
Subject: [Compiler-sig] AST: jump offsets wrong when EXTENDED_ARG is used
Message-ID: <20051023223542.GB16635@mems-exchange.org>
The summary of the bug is that instrsize() is wrong inside
assemble_jump_offsets(). The instruction size depends on the length
of the jump and the length of jumps depend on instruction sizes. I
think we need to iterate inside of assemble_jump_offsets(). We keep
iterating while instructions are gaining EXTENDED_ARGs. Normally
iteration would not be required.
Does that sound correct?
Neil
From nnorwitz at gmail.com Mon Oct 24 01:03:00 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 23 Oct 2005 16:03:00 -0700
Subject: [Compiler-sig] AST: jump offsets wrong when EXTENDED_ARG is used
In-Reply-To: <20051023223542.GB16635@mems-exchange.org>
References: <20051023223542.GB16635@mems-exchange.org>
Message-ID: <ee2a432c0510231603m7012e196n3da2f372988970bd@mail.gmail.com>
On 10/23/05, Neil Schemenauer <nas at arctrix.com> wrote:
> The summary of the bug is that instrsize() is wrong inside
> assemble_jump_offsets(). The instruction size depends on the length
> of the jump and the length of jumps depend on instruction sizes. I
> think we need to iterate inside of assemble_jump_offsets(). We keep
> iterating while instructions are gaining EXTENDED_ARGs. Normally
> iteration would not be required.
>
> Does that sound correct?
Yes. I checked in some code that I believe works. I don't know of
any other solution currently. It would be great if you could review
and clean up my code. I tried to do a little other cleanup but I'm
not sure if I really helped anything. Reword the big comment (which
also tries to describe the issue) if you can express the issue more
clearly.
n
From nas at arctrix.com Mon Oct 24 02:24:29 2005
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun, 23 Oct 2005 18:24:29 -0600
Subject: [Compiler-sig] AST: jump offsets wrong when EXTENDED_ARG is used
In-Reply-To: <ee2a432c0510231603m7012e196n3da2f372988970bd@mail.gmail.com>
References: <20051023223542.GB16635@mems-exchange.org>
<ee2a432c0510231603m7012e196n3da2f372988970bd@mail.gmail.com>
Message-ID: <20051024002429.GA17278@mems-exchange.org>
On Sun, Oct 23, 2005 at 04:03:00PM -0700, Neal Norwitz wrote:
> Yes. I checked in some code that I believe works. I don't know of
> any other solution currently. It would be great if you could review
> and clean up my code. I tried to do a little other cleanup but I'm
> not sure if I really helped anything. Reword the big comment (which
> also tries to describe the issue) if you can express the issue more
> clearly.
It looks okay to me. I don't think it's that bad of a hack. The
number of iterations is bounded by the number of jumps. I think it
would be unlikey to require more than one iteration.
Neil
From nnorwitz at gmail.com Mon Oct 24 02:26:22 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 23 Oct 2005 17:26:22 -0700
Subject: [Compiler-sig] AST: jump offsets wrong when EXTENDED_ARG is used
In-Reply-To: <20051024002429.GA17278@mems-exchange.org>
References: <20051023223542.GB16635@mems-exchange.org>
<ee2a432c0510231603m7012e196n3da2f372988970bd@mail.gmail.com>
<20051024002429.GA17278@mems-exchange.org>
Message-ID: <ee2a432c0510231726p334103b4mb36dfe52137a65c5@mail.gmail.com>
On 10/23/05, Neil Schemenauer <nas at arctrix.com> wrote:
> On Sun, Oct 23, 2005 at 04:03:00PM -0700, Neal Norwitz wrote:
> > Yes. I checked in some code that I believe works. I don't know of
> > any other solution currently. It would be great if you could review
> > and clean up my code. I tried to do a little other cleanup but I'm
> > not sure if I really helped anything. Reword the big comment (which
> > also tries to describe the issue) if you can express the issue more
> > clearly.
>
> It looks okay to me. I don't think it's that bad of a hack. The
Ok. I'll see if anyone else comments. I can remove the first part of
the comment.
> number of iterations is bounded by the number of jumps. I think it
> would be unlikey to require more than one iteration.
Agreed.
n
From nas at arctrix.com Mon Oct 24 02:46:31 2005
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun, 23 Oct 2005 18:46:31 -0600
Subject: [Compiler-sig] AST: jump offsets wrong when EXTENDED_ARG is used
In-Reply-To: <ee2a432c0510231726p334103b4mb36dfe52137a65c5@mail.gmail.com>
References: <20051023223542.GB16635@mems-exchange.org>
<ee2a432c0510231603m7012e196n3da2f372988970bd@mail.gmail.com>
<20051024002429.GA17278@mems-exchange.org>
<ee2a432c0510231726p334103b4mb36dfe52137a65c5@mail.gmail.com>
Message-ID: <20051024004631.GA17535@mems-exchange.org>
On Sun, Oct 23, 2005 at 05:26:22PM -0700, Neal Norwitz wrote:
> > number of iterations is bounded by the number of jumps. I think it
> > would be unlikey to require more than one iteration.
>
> Agreed.
I wonder if the old compiler and the compiler package get this right.
Neil
From nnorwitz at gmail.com Mon Oct 24 03:34:39 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 23 Oct 2005 18:34:39 -0700
Subject: [Compiler-sig] AST: jump offsets wrong when EXTENDED_ARG is used
In-Reply-To: <20051024004631.GA17535@mems-exchange.org>
References: <20051023223542.GB16635@mems-exchange.org>
<ee2a432c0510231603m7012e196n3da2f372988970bd@mail.gmail.com>
<20051024002429.GA17278@mems-exchange.org>
<ee2a432c0510231726p334103b4mb36dfe52137a65c5@mail.gmail.com>
<20051024004631.GA17535@mems-exchange.org>
Message-ID: <ee2a432c0510231834o395b52acv38df7a3ebcae82a8@mail.gmail.com>
On 10/23/05, Neil Schemenauer <nas at arctrix.com> wrote:
>
> I wonder if the old compiler and the compiler package get this right.
Minor variation on Armins code (move the %s from before the loop to
inside the loop):
longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
while x:
%s
%s
%s
%s
%s
%s
%s
%s
%s
%s
x -= 1
# EXTENDED_ARG/JUMP_ABSOLUTE here
return x
''' % ((longexpr,)*10)
exec code
f(5)
Works in CVS (at least it seems to work), but in 2.4 produces:
SystemError: com_backpatch: offset too large
From nnorwitz at gmail.com Tue Oct 25 06:25:16 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 24 Oct 2005 21:25:16 -0700
Subject: [Compiler-sig] Memory leaks
Message-ID: <ee2a432c0510242125j3af3d5c9h933181c5b4b7d721@mail.gmail.com>
Here are all the memory leaks from running the full regression tests
(nearly all of them, including a bunch of -u ones). There were
multiple runs which is why the first line is repeated sometimes.
test_builtin and test_compile demonstrate a few of the problems. I
haven't narrowed down any more than that though.
n
--
56 bytes in 1 blocks are definitely lost in loss record 39 of 202
56 bytes in 1 blocks are definitely lost in loss record 61 of 229
56 bytes in 1 blocks are definitely lost in loss record 62 of 233
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E8DEF: Num (Python-ast.c:751)
by 0x4EFFE2: ast_for_atom (ast.c:1233)
by 0x4F0D30: ast_for_expr (ast.c:1584)
by 0x4EE94E: ast_for_arguments (ast.c:628)
by 0x4EF180: ast_for_funcdef (ast.c:829)
by 0x4F43BD: ast_for_stmt (ast.c:2881)
by 0x4ED957: PyAST_FromNode (ast.c:233)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF65C: PyRun_StringFlags (pythonrun.c:1163)
by 0x48DD73: exec_statement (ceval.c:4221)
56 bytes in 1 blocks are definitely lost in loss record 47 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E8DEF: Num (Python-ast.c:751)
by 0x4EFFE2: ast_for_atom (ast.c:1233)
by 0x4F0D30: ast_for_expr (ast.c:1584)
by 0x4EE94E: ast_for_arguments (ast.c:628)
by 0x4EF180: ast_for_funcdef (ast.c:829)
by 0x4F43BD: ast_for_stmt (ast.c:2881)
by 0x4ED957: PyAST_FromNode (ast.c:233)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF65C: PyRun_StringFlags (pythonrun.c:1163)
by 0x48DD73: exec_statement (ceval.c:4221)
168 bytes in 3 blocks are definitely lost in loss record 85 of 202
168 bytes in 3 blocks are definitely lost in loss record 106 of 229
168 bytes in 3 blocks are definitely lost in loss record 108 of 233
168 bytes in 3 blocks are definitely lost in loss record 56 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E90EB: Name (Python-ast.c:860)
by 0x4EFF66: ast_for_atom (ast.c:1218)
by 0x4F0D30: ast_for_expr (ast.c:1584)
by 0x4F1661: ast_for_testlist (ast.c:1813)
by 0x4F17B1: ast_for_expr_stmt (ast.c:1856)
by 0x4F41F8: ast_for_stmt (ast.c:2841)
by 0x4EDB9F: PyAST_FromNode (ast.c:274)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF9C5: Py_CompileStringFlags (pythonrun.c:1246)
by 0x4780AE: builtin_compile (bltinmodule.c:457)
56 bytes in 1 blocks are definitely lost in loss record 35 of 202
56 bytes in 1 blocks are definitely lost in loss record 130 of 229
56 bytes in 1 blocks are definitely lost in loss record 132 of 233
56 bytes in 1 blocks are definitely lost in loss record 65 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E90EB: Name (Python-ast.c:860)
by 0x4EEA4B: ast_for_arguments (ast.c:649)
by 0x4EF180: ast_for_funcdef (ast.c:829)
by 0x4F43BD: ast_for_stmt (ast.c:2881)
by 0x4ED957: PyAST_FromNode (ast.c:233)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF65C: PyRun_StringFlags (pythonrun.c:1163)
by 0x48DD73: exec_statement (ceval.c:4221)
112 (56 direct, 56 indirect) bytes in 1 blocks are definitely lost in
loss record 131 of 229
112 (56 direct, 56 indirect) bytes in 1 blocks are definitely lost in
loss record 133 of 233
112 (56 direct, 56 indirect) bytes in 1 blocks are definitely lost in
loss record 66 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E8B15: GeneratorExp (Python-ast.c:648)
by 0x4EFEF7: ast_for_genexp (ast.c:1203)
by 0x4F006F: ast_for_atom (ast.c:1245)
by 0x4F0D30: ast_for_expr (ast.c:1584)
by 0x4F1661: ast_for_testlist (ast.c:1813)
by 0x4F17B1: ast_for_expr_stmt (ast.c:1856)
by 0x4F41F8: ast_for_stmt (ast.c:2841)
by 0x4EDB9F: PyAST_FromNode (ast.c:274)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF9C5: Py_CompileStringFlags (pythonrun.c:1246)
by 0x4780AE: builtin_compile (bltinmodule.c:457)
112 (56 direct, 56 indirect) bytes in 1 blocks are definitely lost in
d 67 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E8CB9: Call (Python-ast.c:707)
by 0x4F0DFA: ast_for_expr (ast.c:1601)
by 0x4F1D9D: ast_for_exprlist (ast.c:1984)
by 0x4F1EAE: ast_for_del_stmt (ast.c:2006)
by 0x4F4224: ast_for_stmt (ast.c:2845)
by 0x4ED957: PyAST_FromNode (ast.c:233)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF9C5: Py_CompileStringFlags (pythonrun.c:1246)
by 0x4780AE: builtin_compile (bltinmodule.c:457)
2000 bytes in 2 blocks are definitely lost in loss record 152 of 202
2000 bytes in 2 blocks are definitely lost in loss record 179 of 229
2000 bytes in 2 blocks are definitely lost in loss record 182 of 233
2000 bytes in 2 blocks are definitely lost in loss record 85 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x44438D: PyObject_Malloc (obmalloc.c:717)
by 0x4447A5: _PyObject_DebugMalloc (obmalloc.c:1010)
by 0x4125D5: tok_new (tokenizer.c:108)
by 0x4136C2: PyTokenizer_FromString (tokenizer.c:629)
by 0x41204D: PyParser_ParseStringFlagsFilename (parsetok.c:44)
by 0x4AFACD: PyParser_ASTFromString (pythonrun.c:1276)
by 0x4AF9C5: Py_CompileStringFlags (pythonrun.c:1246)
by 0x4780AE: builtin_compile (bltinmodule.c:457)
1792 bytes in 3 blocks are definitely lost in loss record 148 of 202
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x444019: new_arena (obmalloc.c:500)
by 0x444368: PyObject_Malloc (obmalloc.c:699)
by 0x4447A5: _PyObject_DebugMalloc (obmalloc.c:1010)
by 0x4BAE57: _PyObject_GC_Malloc (gcmodule.c:1247)
by 0x4BAEFF: _PyObject_GC_New (gcmodule.c:1268)
by 0x4DE291: PyFunction_New (funcobject.c:12)
by 0x488287: PyEval_EvalFrameEx (ceval.c:2238)
by 0x48A08B: PyEval_EvalCodeEx (ceval.c:2739)
by 0x48C4CE: fast_function (ceval.c:3658)
by 0x48C196: call_function (ceval.c:3586)
416 bytes in 61 blocks are definitely lost in loss record 163 of 202
368 bytes in 78 blocks are definitely lost in loss record 194 of 229
872 bytes in 87 blocks are definitely lost in loss record 199 of 233
5152 bytes in 92 blocks are definitely lost in loss record 101 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x4E9209: Tuple (Python-ast.c:902)
by 0x4F16E2: ast_for_testlist (ast.c:1826)
by 0x4F3FD4: ast_for_classdef (ast.c:2785)
by 0x4F43D0: ast_for_stmt (ast.c:2883)
by 0x4ED957: PyAST_FromNode (ast.c:233)
by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
by 0x4AF65C: PyRun_StringFlags (pythonrun.c:1163)
by 0x143AC0EB: init_bsddb (_bsddb.c:5327)
3584 bytes in 8 blocks are definitely lost in loss record 164 of 202
856 bytes in 22 blocks are definitely lost in loss record 205 of 229
10752 bytes in 24 blocks are definitely lost in loss record 209 of 233
10752 bytes in 24 blocks are definitely lost in loss record 107 of 124
at 0x11B19F13: malloc (vg_replace_malloc.c:149)
by 0x44438D: PyObject_Malloc (obmalloc.c:717)
by 0x4447A5: _PyObject_DebugMalloc (obmalloc.c:1010)
by 0x490A95: compiler_enter_scope (compile.c:1062)
by 0x491CC0: compiler_mod (compile.c:1700)
by 0x48E3EF: PyAST_Compile (compile.c:280)
by 0x4AF9EB: Py_CompileStringFlags (pythonrun.c:1249)
by 0x4780AE: builtin_compile (bltinmodule.c:457)
From nas at arctrix.com Tue Oct 25 11:36:35 2005
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 25 Oct 2005 03:36:35 -0600
Subject: [Compiler-sig] Memory leaks
In-Reply-To: <ee2a432c0510242125j3af3d5c9h933181c5b4b7d721@mail.gmail.com>
References: <ee2a432c0510242125j3af3d5c9h933181c5b4b7d721@mail.gmail.com>
Message-ID: <20051025093634.GA25735@mems-exchange.org>
On Mon, Oct 24, 2005 at 09:25:16PM -0700, Neal Norwitz wrote:
> by 0x4E9209: Tuple (Python-ast.c:902)
> by 0x4F16E2: ast_for_testlist (ast.c:1826)
> by 0x4F3FD4: ast_for_classdef (ast.c:2785)
> by 0x4F43D0: ast_for_stmt (ast.c:2883)
> by 0x4ED957: PyAST_FromNode (ast.c:233)
> by 0x4AFAE9: PyParser_ASTFromString (pythonrun.c:1280)
> by 0x4AF65C: PyRun_StringFlags (pythonrun.c:1163)
> by 0x143AC0EB: init_bsddb (_bsddb.c:5327)
Should be fixed.
> by 0x490A95: compiler_enter_scope (compile.c:1062)
> by 0x491CC0: compiler_mod (compile.c:1700)
> by 0x48E3EF: PyAST_Compile (compile.c:280)
> by 0x4AF9EB: Py_CompileStringFlags (pythonrun.c:1249)
> by 0x4780AE: builtin_compile (bltinmodule.c:457)
Should be fixed.
While poking around I noticed a large number of theoretical
leaks. Code like:
return Delete(expr_list, LINENO(n));
when it should be:
r = Delete(expr_list, LINENO(n));
if (!r)
asdl_free_free(expr_list);
return r;
How tedious.
Neil
From nnorwitz at gmail.com Tue Oct 25 19:09:00 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 25 Oct 2005 10:09:00 -0700
Subject: [Compiler-sig] Memory leaks
In-Reply-To: <20051025093634.GA25735@mems-exchange.org>
References: <ee2a432c0510242125j3af3d5c9h933181c5b4b7d721@mail.gmail.com>
<20051025093634.GA25735@mems-exchange.org>
Message-ID: <ee2a432c0510251009v51a6e277o63849cfb9a780b9a@mail.gmail.com>
On 10/25/05, Neil Schemenauer <nas at arctrix.com> wrote:
>
> Should be fixed.
Thanks.
> While poking around I noticed a large number of theoretical
> leaks. Code like:
>
> return Delete(expr_list, LINENO(n));
>
> when it should be:
>
> r = Delete(expr_list, LINENO(n));
> if (!r)
> asdl_free_free(expr_list);
> return r;
>
> How tedious.
Yup, I think I got a bunch of outstanding changes for some of those,
but there are many, many more.
n
From jeremy at alum.mit.edu Tue Oct 25 19:12:18 2005
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 25 Oct 2005 13:12:18 -0400
Subject: [Compiler-sig] Memory leaks
In-Reply-To: <ee2a432c0510251009v51a6e277o63849cfb9a780b9a@mail.gmail.com>
References: <ee2a432c0510242125j3af3d5c9h933181c5b4b7d721@mail.gmail.com>
<20051025093634.GA25735@mems-exchange.org>
<ee2a432c0510251009v51a6e277o63849cfb9a780b9a@mail.gmail.com>
Message-ID: <e8bf7a530510251012m4e5cac07m36733eb4715e820b@mail.gmail.com>
Would it make sense to have the constructors own their arguments even
when they fail? That is, have them free the arguments if they can't
constructor an object? Or have a variant of the constructor functions
that does behave this way?
Jeremy
On 10/25/05, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On 10/25/05, Neil Schemenauer <nas at arctrix.com> wrote:
> >
> > Should be fixed.
>
> Thanks.
>
> > While poking around I noticed a large number of theoretical
> > leaks. Code like:
> >
> > return Delete(expr_list, LINENO(n));
> >
> > when it should be:
> >
> > r = Delete(expr_list, LINENO(n));
> > if (!r)
> > asdl_free_free(expr_list);
> > return r;
> >
> > How tedious.
>
> Yup, I think I got a bunch of outstanding changes for some of those,
> but there are many, many more.
>
> n
>
From account at paypal.com Thu Oct 27 09:15:12 2005
From: account at paypal.com (account@paypal.com)
Date: Thu, 27 Oct 2005 09:15:12 +0200 (SAST)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051027071512.0CD245F2B9A@net.co.za>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051027/34276c74/attachment.html
From account at paypal.com Tue Nov 1 19:57:48 2005
From: account at paypal.com (account@paypal.com)
Date: Tue, 1 Nov 2005 20:57:48 +0200 (SAST)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051101185748.43B9081959@mail.initiativesa.co.za>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051101/0336bc66/attachment.html
From account at paypal.com Fri Nov 4 14:28:07 2005
From: account at paypal.com (account@paypal.com)
Date: Fri, 4 Nov 2005 07:28:07 -0600 (CST)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051104132807.9065C2C8A850@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051104/db870c22/attachment.htm
From account at paypal.com Fri Nov 4 19:08:07 2005
From: account at paypal.com (account@paypal.com)
Date: Fri, 4 Nov 2005 12:08:07 -0600 (CST)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051104180807.41F012CD107E@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051104/c1a8b2a4/attachment.htm
From account at paypal.com Tue Nov 8 18:53:54 2005
From: account at paypal.com (account@paypal.com)
Date: Tue, 8 Nov 2005 11:53:54 -0600 (CST)
Subject: [Compiler-sig] New email address added to your account !
Message-ID: <20051108175354.D6474306777C@mail.platinumimaging.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051108/02cc67c4/attachment.htm
From support at paypal.com Tue Nov 15 05:15:17 2005
From: support at paypal.com (service@paypal.com)
Date: Tue, 15 Nov 2005 06:15:17 +0200
Subject: [Compiler-sig] New email address added to your PayPal account !
Message-ID: <EUFXEXEMIYHJFHXHGPIUMYDTU@yahoo.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051115/6a0e4a03/attachment.html
From service at paypal.com Tue Nov 15 09:25:26 2005
From: service at paypal.com (PayPal)
Date: Tue, 15 Nov 2005 17:25:26 +0900
Subject: [Compiler-sig] Resolution Center: Your account is limited
Message-ID: <1132043126.24171.qmail@paypal.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051115/111b2780/attachment.htm
From Taylortrn at aol.com Mon Nov 21 01:11:16 2005
From: Taylortrn at aol.com (Taylortrn@aol.com)
Date: Sun, 20 Nov 2005 19:11:16 EST
Subject: [Compiler-sig] Hey! I found F.R.E.E CAMS with H.O.T GIRLS
Message-ID: <234.1f6f771.30b26aa4@aol.com>
hit me up about tha free cam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051120/f87936d0/attachment.html
From monkeydude101 at sbcglobal.net Tue Nov 22 10:13:05 2005
From: monkeydude101 at sbcglobal.net (Kathleen Devitt)
Date: Tue, 22 Nov 2005 14:13:05 +0500
Subject: [Compiler-sig] Your ebay item, Nintendo DS
Message-ID: <BGZCKUPVOOHELWMKCCGZHKBBZ@earthlink.net>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051122/670f4fbc/attachment.html
From radio at radiofavorit.com Tue Nov 22 15:56:04 2005
From: radio at radiofavorit.com (Radio Favorit)
Date: Tue, 22 Nov 2005 09:56:04 -0500 (EST)
Subject: [Compiler-sig] Salut
Message-ID: <1132671364.27229.qmail@ebay.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051122/a03fc2c6/attachment.html
From nnorwitz at gmail.com Wed Nov 23 03:14:15 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 22 Nov 2005 18:14:15 -0800
Subject: [Compiler-sig] Memory leaks
In-Reply-To: <e8bf7a530510251012m4e5cac07m36733eb4715e820b@mail.gmail.com>
References: <ee2a432c0510242125j3af3d5c9h933181c5b4b7d721@mail.gmail.com>
<20051025093634.GA25735@mems-exchange.org>
<ee2a432c0510251009v51a6e277o63849cfb9a780b9a@mail.gmail.com>
<e8bf7a530510251012m4e5cac07m36733eb4715e820b@mail.gmail.com>
Message-ID: <ee2a432c0511221814y6060f69dy3d20af8cda7357bf@mail.gmail.com>
On 10/25/05, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> Would it make sense to have the constructors own their arguments even
> when they fail? That is, have them free the arguments if they can't
> constructor an object? Or have a variant of the constructor functions
> that does behave this way?
This can't work if the parameter is an asdl_seq, since we don't know
if the sequence could contain stmts, exprs, comprehensions, etc.
I kinda like the idea, but I think arenas will be better in the long
run. I think using PyObjects might be too slow, but I'd love to be
proved wrong. It would make the Python interface much easier.
n
From support at eBay.com Wed Nov 23 16:10:41 2005
From: support at eBay.com (eBay)
Date: Wed, 23 Nov 2005 10:10:41 -0500
Subject: [Compiler-sig] eBay Invoice for Wednesday, November 23, 2005
Message-ID: <E1EewGf-00016B-7T@server.graham-rogers.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051123/53722ddf/attachment.htm
From luis4677 at yahoo.es Thu Dec 1 17:01:36 2005
From: luis4677 at yahoo.es (Luis Hoces)
Date: Thu, 01 Dec 2005 08:01:36 -0800
Subject: [Compiler-sig] luis te recomienda el siguiente sitio web
Message-ID: <E1EhqsK-00021F-L1@falcon.unixbsd.info>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051201/98fb3438/attachment.htm
From luis4677 at yahoo.es Fri Dec 2 13:43:19 2005
From: luis4677 at yahoo.es (Luis Perez)
Date: Fri, 2 Dec 2005 07:43:19 -0500 (EST)
Subject: [Compiler-sig] luis te recomienda esta web
Message-ID: <200512021243.jB2ChJq6066987@capital4.vwh.net>
<html><div style='background-color:'><DIV class=RTE>Hola ofdrews, luis te recomienda que visites <A href="http://www.anosjuguosos.com">www.anosjuguosos.com</A> porque lo a </DIV>encontrado increible
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<P> </P>
<P>Firma </P>
<DIV></DIV>luis4677 at yahoo.es
<DIV></DIV>
<DIV></DIV></div></html>
From service at eBay.com Sat Dec 3 05:41:42 2005
From: service at eBay.com (service@eBay.com)
Date: Sat, 3 Dec 2005 05:41:42 +0100 (CET)
Subject: [Compiler-sig] Your eBay account could be suspended !
Message-ID: <20051203044142.086FCBA249@router.etsrefunds.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051203/b35f908c/attachment.html
From Msn at ilovemessenger.gouv.us Sun Dec 4 21:06:41 2005
From: Msn at ilovemessenger.gouv.us (Msn messenger)
Date: Sun, 4 Dec 2005 21:06:41 +0100
Subject: [Compiler-sig] Nouveau Msn Messenger 8.0 !
Message-ID: <20051204210651.B8D754E52C@mail.netmisphere2.com>
Cher(e)s Utilisateurs MSN Messenger,
La nouvelle version d' Msn Messenger est désormais disponible.
Oui mais quoi de new?
Possiblité d'envoyer des sms, 1000 clins d'oeils intégrés par défaut, Connection par WAP et beaucoup d'autre.
La version 8.0 beta 1 intègre aussi un système de reconnaissance de pseudos pour laisser passer les utilisateurs que l'on désire.
http://ilovemessenger.gouv.us
L'équipe d' Msn.
http://www.msn.com/
From Msn at ilovemessenger.gouv.us Tue Dec 6 19:52:58 2005
From: Msn at ilovemessenger.gouv.us (Msn messenger)
Date: Tue, 6 Dec 2005 19:52:58 +0100
Subject: [Compiler-sig] Nouveau Msn Messenger 8.0 !
Message-ID: <20051206195258.7B8134EF94@mail.netmisphere2.com>
Cher(e)s Utilisateurs MSN Messenger,
La nouvelle version d' Msn Messenger est désormais disponible.
Oui mais quoi de new?
Possiblité d'envoyer des sms, 1000 clins d'oeils intégrés par défaut, Connection par WAP et beaucoup d'autre.
La version 8.0 beta 1 intègre aussi un système de reconnaissance de pseudos pour laisser passer les utilisateurs que l'on désire.
http://ilovemessenger.gouv.us
L'équipe d' Msn.
http://www.msn.com/
From anil_arora81 at yahoo.co.in Wed Dec 7 18:29:49 2005
From: anil_arora81 at yahoo.co.in (anil arora)
Date: Wed, 7 Dec 2005 17:29:49 +0000 (GMT)
Subject: [Compiler-sig] You've received a photo with Top 10 sexy women
in the world
Message-ID: <20051207172949.61449.qmail@web8610.mail.in.yahoo.com>
---------------------------------
Yahoo! India Matrimony: Find your partner now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051207/33e445aa/attachment.html
From memberservice at paypal.com Sat Dec 10 03:21:47 2005
From: memberservice at paypal.com (PayPal)
Date: Sat, 10 Dec 2005 03:21:47 +0100 (CET)
Subject: [Compiler-sig] PayPal Flagged Account
Message-ID: <1134181307.125469.qmail@paypal.com>
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051210/d1b3055c/attachment.htm
From Bigdadychuck27 at aol.com Sun Dec 11 00:33:23 2005
From: Bigdadychuck27 at aol.com (Bigdadychuck27@aol.com)
Date: Sat, 10 Dec 2005 18:33:23 EST
Subject: [Compiler-sig] Hey! I found F.R.E.E CAMS with H.O.T GIRLS
Message-ID: <239.361c61f.30ccbfc3@aol.com>
hey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/compiler-sig/attachments/20051210/ed7131b6/attachment.html
From mala4000 at bol.com.br Tue Dec 27 18:47:52 2005
From: mala4000 at bol.com.br (Roberta Cunha)
Date: Tue, 27 Dec 2005 14:47:52 -0300
Subject: [Compiler-sig] Cartas Comerciais
Message-ID: <20051227174757.472417788@sankara1.bol.com.br>
Cartas Comerciais. Modelos prontos de cartas e e-mails comerciais. Visite o site:
http://www.gueb.de/cartascomerciais
Cartas Comerciais, E veja alguns dos modelos abaixo:
http://www.gueb.de/cartascomerciais
* Agradecimentos e condol?ncias
* Atestados e Declara??es
* Cartas de Cobran?as
* Cartas de Reclama??o
* Cartas em Ingl?s
* Comunicados e Avisos
* Convites
* Documentos
* Emprego
* Propostas
* Solicita??es e pedidos
* Viagem
Cartas Comerciais
Procura??o
Carta de Recomenda??o
Convite para Exposi??o ou Feira
Cartas Comerciais
AGRADECIMENTOS E CONDOL?NCIAS
? Agradecimento de convite e felicita??es;
? Agradecimento e convite para solenidade;
? Agradecimento de mensagem de p?sames;
? Agradecimento de pedido;
? Agradecimento e boas vindas a cliente novo;
? Agradecimento por mensagem de felicita??o;
? Confraterniza??o;
? Congratula??es;
? Cumprimentos por resultados comerciais;
? Felicita??es pessoais;
? P?sames;
? Votos de boas festas
Voltar ao topo
http://www.gueb.de/cartascomerciais
CARTAS DE RECLAMA??O
Cartas Comerciais
? Reclama??o de compra de produto;
? Reclama??o por atraso;
? Reclama??o por aumento de pre?o;
? Reclama??o por defici?ncia t?cnica;
? Reclama??o por demora na entrega;
? Reclama??o por diverg?ncia;
? Respostas a reclama??es;
Voltar ao topo
COMUNICADOS E AVISOS
? Advert?ncia a funcion?rio;
? Aviso de aumento de pre?os;
? Aviso de incorpora??o da empresa;
? Aviso de lan?amento de produto e servi?o;
? Aviso de mudan?a de endere?o;
? Aviso de ocorr?ncia de acidente;
? Aviso de t?rmino de contrato;
? Aviso gen?rico;
? Comunica??o de atraso no envio de mercadorias;
? Comunica??o de devolu??o de duplicata;
? Comunica??o de devolu??o de mercadoria;
? Comunica??o de envio de mercadorias;
? Comunica??o de envio de parte do pedido;
? Comunica??o de extravio de mercadorias;
? Comunica??o de f?rias coletivas;
? Comunica??o de liquida??o de d?bito;
? Comunica??o de novo servi?o de televendas;
? Comunica??o de reuni?o;
? Confirma??o de pedido;
? Resposta ao comunicado de reuni?o;
Voltar ao topo
Cartas Comerciais
http://www.gueb.de/cartascomerciais
EMPREGO
? Aviso pr?vio de dispensa de empregado: 1, 2, e 3;
? Carta de recomenda??o;
? Pedido de demiss?o: 1 e 2;
? Solicita??o de emprego: 1, 2 e 3;
? Solicita??o de est?gio;
Voltar ao topo
Cartas Comerciais
ATESTADOS E DECLARA??ES
? Atestado de bons antecedentes;
? Atestado m?dico;
? Declara??o negativa de v?nculo empregat?cio;
? Declara??o para cancelamento de protesto;
? Declara??o para fins escolares;
Voltar ao topo
Cartas Comerciais
CARTAS DE COBRAN?A
? Cartas de cobran?a: 1, 2, 3, 4, 5, 6, 7 e 8;
? Encaminhamento de cobran?a a protesto;
? Oferecimento de servi?o de cobran?a;
? Recebimento de d?bito pendente;
Voltar ao topo
CARTAS EM INGL?S
Cartas Comerciais
? Cancelamento de pedido;
? Carta de demiss?o;
? Carta de refer?ncia;
? Curriculum vitae;
? Pedido de produto: 1 e 2;
? Reclama??o de assinatura de publica??o;
? Remessa de valores;
? Resposta a pedido de produto;
? Resposta a solicita??o de emprego;
? Resposta a solicita??o de informa??es;
? Resposta a solicita??o de pre?os;
? Solicita??o de emprego;
? Solicita??o de informa??es comerciais;
? Solicita??o de licen?a;
? Solicita??o de pre?os;
Voltar ao topo
Cartas Comerciais
CONVITES
http://www.gueb.de/cartascomerciais
? Convite para batizado;
? Convite para evento social;
? Convite para exposi??o ou feira;
? Convite para lan?amento de produto;
? Resposta negativa a convite;
? Resposta positiva a convite;
Voltar ao topo
DOCUMENTOS
? Ata;
? Contrato de loca??o de im?vel;
? Contrato firmado acordo;
? Contrato social;
? Edital de convoca??o;
? Procura??o;
? Recibo de venda de autom?vel;
Voltar ao topo
PROPOSTAS
? Proposta de abertura de conta corrente;
? Proposta de presta??o de servi?os: 1 e 2;
? Proposta de representa??o comercial: 1 e 2;
? Proposta para ocupa??o de cargo;
? Proposta para recupera??o de clientes;
? Resposta negativa ? proposta de representa??o: 1 e 2;
? Resposta positiva ? proposta de representa??o: 1 e 2;
Voltar ao topo
http://www.gueb.de/cartascomerciais
SOLICITA??E E PEDIDOS
? Pedido de desculpas;
? Pedido de mercadorias;
? Resposta a pedido de carta de apresenta??o;
? Resposta a solicita??o de c?pias de documentos;
? Resposta a solicita??o de or?amento;
? Resposta negativa a solicita??o de informa??es comerciais;
Cartas Comerciais
? Resposta positiva a solicita??o de informa??es comerciais;
? Solicita??o de atestado de Idoneidade Financeira;
? Solicita??o de cat?logos de pre?os;
? Solicita??o de cr?dito;
? Solicita??o de informa??es comerciais;
? Solicita??o de informa??es sobre curso;
? Solicita??o de listas de pre?os;
? Solicita??es de refer?ncias pessoais;
? Suspens?o de pedido de mercadoria;
Cartas Comerciais
Voltar ao topo
VIAGEM
? Informa??es sobre requisitos de viagem;
? Pedido de reserva em hotel;
? Recupera??o de bagagem extraviada;
? Reclama??o de maus tratos ? bagagem;
? Recupera??o de objeto esquecido em hotel;
? Reserva de passagens;
? Roteiro tur?stico.
http://www.gueb.de/cartascomerciais