<!-- 
RSS generated by JIRA (8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b) at Sat Feb 10 15:31:47 JST 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>PFS-JIRA</title>
    <link>https://pfspipe.ipmu.jp/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.3.4</version>
        <build-number>803005</build-number>
        <build-date>13-09-2019</build-date>
    </build-info>


<item>
            <title>[REDMINE1D-345] [RM-8441] Refactor warning flag recording when an error occur</title>
                <link>https://pfspipe.ipmu.jp/jira/browse/REDMINE1D-345</link>
                <project id="11002" key="REDMINE1D">1D Redmine </project>
                    <description>&lt;p&gt;&lt;em&gt;&lt;font color=&quot;#505f79&quot;&gt; Created on 2023-10-24 14:32:26 by Didier Vibert. % Done: 0&lt;/font&gt;&lt;/em&gt;&lt;/p&gt;


&lt;p&gt;in develop (and 0.44) when running a QSO linemeas only, with a linemeas catalog without the required columns (eg qso.VelocityAbsorption) the error &quot;Context warning flag already exists&quot; still appears ...&lt;/p&gt;

&lt;p&gt;&amp;lt;pre&amp;gt;&lt;br/&gt;
Info:  processing                        ProcessingID&lt;br/&gt;
0  00005-00000-0,0-000000000000067d&lt;br/&gt;
Info:  Using amazed reader&lt;br/&gt;
Info:  Using amazed external storage&lt;br/&gt;
Info:  Processing 00005-00000-0,0-000000000000067d&lt;br/&gt;
Error:  PYTHON_API_ERROR: &apos;qso.VelocityAbsorption&apos; &lt;span class=&quot;error&quot;&gt;&amp;#91;base.py:3654:get_loc&amp;#93;&lt;/span&gt;&lt;br/&gt;
Error:  Context warning flag already exists&lt;/p&gt;

&lt;p&gt;&amp;lt;/pre&amp;gt;&lt;/p&gt;

&lt;p&gt;The warning flags should not be recorded in the COperatorResultStore from the c++ exception (as it is the case now) but from the python process flow&lt;/p&gt;</description>
                <environment></environment>
        <key id="24087">REDMINE1D-345</key>
            <summary>[RM-8441] Refactor warning flag recording when an error occur</summary>
                <type id="3" iconUrl="https://pfspipe.ipmu.jp/jira/secure/viewavatar?size=xsmall&amp;avatarId=10518&amp;avatarType=issuetype">Task</type>
                                            <priority id="10000" iconUrl="https://pfspipe.ipmu.jp/jira/images/icons/priorities/medium.svg">Normal</priority>
                        <status id="1" iconUrl="https://pfspipe.ipmu.jp/jira/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="blue-gray"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="r2j.migrate">Redmine-Jira Migtation</assignee>
                                    <reporter username="r2j.migrate">Redmine-Jira Migtation</reporter>
                        <labels>
                    </labels>
                <created>Tue, 24 Oct 2023 18:15:36 +0000</created>
                <updated>Mon, 4 Dec 2023 18:18:04 +0000</updated>
                                                                                <due></due>
                            <votes>0</votes>
                                    <watches>1</watches>
                                                                <comments>
                            <comment id="36264" author="r2j.migrate" created="Mon, 4 Dec 2023 18:17:44 +0000"  >&lt;p&gt;Comment by Didier Vibert on 2023-11-07 08:42:15:&lt;br/&gt;
may be implemented at the same time than the handling of the scope at python level with the management of the stage level. &lt;/p&gt;

&lt;p&gt;I propose to define a python context manager for dealing with stage/solver scopes, pushing a new scope at beginning, popping the scope and collect/store the warning flag in the resultStore at finalization. The use of the context manager (@with@ statement) could also be embedded in a decorator (as it is the case already for trapping exceptions). The advantage of using a context manager instead of explicitly storing the warning flag at the exception level, is that there will then be only one place (in the code) for storing each warning flag: at the ending of the corresponding context, whatever causes the end, ie exception or normal ending.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10500" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|zzt03j:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    </customfields>
    </item>
</channel>
</rss>