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: 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> <87acha5et8.fsf@hydra.bayview.thirdcreek.com> <87wtkd4aq9.fsf@hydra.bayview.thirdcreek.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> <87acha5et8.fsf@hydra.bayview.thirdcreek.com> <87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com> <20051019190008.GA31686@mems-exchange.org> <20051019195232.GA31857@mems-exchange.org> Message-ID: 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 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: References: <87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com> <20051015183855.GA28324@mems-exchange.org> <87acha5et8.fsf@hydra.bayview.thirdcreek.com> <87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com> <20051019190008.GA31686@mems-exchange.org> <20051019195232.GA31857@mems-exchange.org> 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> <87acha5et8.fsf@hydra.bayview.thirdcreek.com> <87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com> <20051019190008.GA31686@mems-exchange.org> <20051019195232.GA31857@mems-exchange.org> <20051019212226.GA32325@mems-exchange.org> Message-ID: On 10/19/05, Neil Schemenauer 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: References: <87ll0u8zx1.fsf@hydra.bayview.thirdcreek.com> <87acha5et8.fsf@hydra.bayview.thirdcreek.com> <87wtkd4aq9.fsf@hydra.bayview.thirdcreek.com> <20051019190008.GA31686@mems-exchange.org> <20051019195232.GA31857@mems-exchange.org> <20051019212226.GA32325@mems-exchange.org> Message-ID: On 10/19/05, Jeremy Hylton 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: On 10/23/05, Neil Schemenauer 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: References: <20051023223542.GB16635@mems-exchange.org> 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> <20051024002429.GA17278@mems-exchange.org> Message-ID: On 10/23/05, Neil Schemenauer 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: References: <20051023223542.GB16635@mems-exchange.org> <20051024002429.GA17278@mems-exchange.org> 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> <20051024002429.GA17278@mems-exchange.org> <20051024004631.GA17535@mems-exchange.org> Message-ID: On 10/23/05, Neil Schemenauer 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: 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: References: 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: <20051025093634.GA25735@mems-exchange.org> Message-ID: On 10/25/05, Neil Schemenauer 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: References: <20051025093634.GA25735@mems-exchange.org> Message-ID: 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 wrote: > On 10/25/05, Neil Schemenauer 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: 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: 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: References: <20051025093634.GA25735@mems-exchange.org> Message-ID: On 10/25/05, Jeremy Hylton 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: 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: 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>
Hola ofdrews, luis te recomienda que visites www.anosjuguosos.com porque lo a
encontrado increible

Firma

luis4677 at yahoo.es
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