Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 44121 invoked from network); 18 Sep 2007 15:35:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Sep 2007 15:35:58 -0000 Received: (qmail 37638 invoked by uid 500); 18 Sep 2007 15:35:49 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 37554 invoked by uid 500); 18 Sep 2007 15:35:49 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 37543 invoked by uid 99); 18 Sep 2007 15:35:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Sep 2007 08:35:49 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [130.237.222.182] (HELO smtp.nada.kth.se) (130.237.222.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Sep 2007 15:35:47 +0000 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from [192.168.105.137] ([62.84.203.102]) (authenticated bits=0) by smtp.nada.kth.se (8.12.11.20060308/8.12.11) with ESMTP id l8IFZOt9020269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Sep 2007 17:35:25 +0200 (MEST) Message-ID: <46EFF037.3070409@nada.kth.se> Date: Tue, 18 Sep 2007 17:35:19 +0200 From: Daniel Fagerstrom User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: pipelineComponent scope troubles References: <46C95ED4.7000602@apache.org> <46E4E2CC.1090906@apache.org> <46E4FEC3.4020703@apache.org> <46E52608.7050705@apache.org> <46E5429A.1000808@apache.org> <46E67DA5.9000807@apache.org> <46E6EA9F.5000205@apache.org> <46E7F40D.1030500@apache.org> <46E80467.8090609@apache.org> <46E80EEA.2010803@apache.org> <46E9AED4.5030005@apache.org> <46EA2DEA.8020804@apache.org> <46EA5DF1.6030208@apache.org> <46EA9C9E.5010409@apache.org> <46EAA2F8.1080302@apache.org> <46EAFCCA.8000105@apache.org> <46EFC985.4080401@apache.org> <46EFCFC3.5030407@apache.org> In-Reply-To: <46EFCFC3.5030407@apache.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Grzegorz Kossakowski skrev: > Giacomo Pati pisze: > >> Yes, clean my M2 repo. >> >> >>> of problematic behaviour in order to help anyhow. >>> >> Still have the problems. With scpre="request" I got the stack trace after the first request found >> at http://people.apache.org/~giacomo/request-log4j-2.log >> > > I fear that we got stuck. Without working code exhibiting your problem I cannot help any further. > Don't know if you are going to like it ;) Have you studied how you prove algorithm correctness yet? If not, the idea is that you give a formal definition of the precondition of the algorithm, what is true about input data before you run the algorithm. You also describe the post condition, what is supposed to be true about the output of the algorithm. The you use your creativity and state an invariant, something that will be true about the state variables of the algorthm at all time through the execution. Then the remaining and rather mechanical step is to show that the precondition and the operations leads to the invariant, that loops or recursions preserve the invariant and that the invariant together with the stop condition leads to the postcondition. OK, doing the above in a formal way, would require an completely unrealistic amount of work for the object model and the pipeline scope. But following the general scheme in an unformal way is often quite helpful for understanding and describing complex algorthms. So, getting to the point, what I propose is that you describe in a semiformal way what is supposed to be true about stack and other state before enetering the scope, during the scope and when leaving it. This will be helpful both for you and for the rest of us for being able to see if your approach and code is correct. Now, the above can seem like a rather indirect and inneficient way to find the problem behind the bug that Giacomo found. For code in general it isn't the way to go. But for things like building execution machines for languages (as in the current case) my experience strongly suggest that what I propose is the most efficient way to go. /Daniel