perl-workflow-devel — discussion list for developers of Perl Workflow

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Stockdale, R. <rf...@bu...>]

Jonas,

I already have a SourceForge account so that is probably the easiest
solution for everyone.

Could you please grant me commit rights? Also, which branch would you prefer
I work in?

--
Bob Stockdale
Administrative Computing Services
University at Buffalo
(716) 645-5334
rf...@bu...


> From: Jonas Brømsø Nielsen <jo...@gm...>
> Date: Tue, 18 Nov 2008 14:45:59 -0500
> To: Robert Stockdale <rf...@bu...>
> Cc: "Brandt, Carl" <cb...@bu...>, Workflow development list
> <per...@li...>
> Subject: Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with
> 'test' attirbute appears to be cached as 'evaluate'
>
> Hi Robert,
>
> You are more than welcome to get commit rights to our hosted
> subversion repository.
>
> We are currently hosted at SourceForge so it requires an account there.
>
> Or you can send me the whole thing and I will sort it out.
>
> Thanks for taking the time and effort to do the extra iteration, I
> think it will prove to be worth while.
>
> jonasbn
>
> On 18/11/2008, at 20.37, Stockdale, Robert wrote:
>
>> I attached the updated patch file to the RT ticket:
>>
>>    http://rt.cpan.org/Ticket/Display.html?id=38024
>>
>> Also, I wrote some automated tests for this change. What is the best
>> way to
>> get them into the distribution?
>>
>> --
>> Bob Stockdale
>> Administrative Computing Services
>> University at Buffalo
>> (716) 645-5334
>> rf...@bu...
>>
>>
>>> From: Jonas Brømsø Nielsen <jo...@gm...>
>>> Date: Mon, 17 Nov 2008 15:22:42 -0500
>>> To: "Brandt, Carl" <cb...@bu...>
>>> Cc: Workflow development list <per...@li...>
>>> Subject: Re: [Perl-workflow-devel] [rt.cpan.org #38024] all
>>> conditions with
>>> 'test' attirbute appears to be cached as 'evaluate'
>>>
>>> Sounds good.
>>>
>>> I was started to thinking along the lines of using Data::UUID to
>>> generate the unique names, but that would probably just warp the
>>> developers minds completely.
>>>
>>> I am looking for to the patch - we can get a development release out
>>> of the door the moment it can be applied. This will also let other
>>> developers evaluate the patch easily.
>>>
>>>
>>> jonasbn
>>>
>>> On 17/11/2008, at 21.18, Jim Brandt wrote:
>>>
>>>> We discussed and came up with the following. Bob will be following
>>>> up with a patch after some testing.
>>>>
>>>> * With regard to conditions, the name 'evaluate' is only used when
>>>> creating the Condition::Evaluate object. It seems when conditions
>>>> are evaluated, the sub just cycles through all conditions in the
>>>> conditions array, so the name 'evaluate' isn't special in any way.
>>>>
>>>> * Naming for the auto-generated conditions
>>>>
>>>> When the condition fails, the name of the condition is written out
>>>> to log4perl, so previous to the patch users would see that the
>>>> 'evaluate' condition failed, which tells them that it was a 'test'
>>>> condition, but does not tell them which one.
>>>>
>>>> Bob suggested even more detail in the name, like:
>>>>
>>>> "_$state\_$action\_condition\_$counter" so for example:
>>>>
>>>> _Begin_SA_condition_1
>>>>
>>>> If you had a problem, this would point you directly to the state-
>>>>> action->in-line condition where your perl code is. I believe Bob
>>>> said all of that information is easy to get inside the state object.
>>>>
>>>>
>>>> Jim
>>>>
>>>> Jonas Brømsø Nielsen wrote:
>>>>> Hi Jim,
>>>>> Thanks for the explanation, it was something along the lines of
>>>>> what I
>>>>> expected. Not being a user of this functionality however, I just
>>>>> needed some hand-holding on the patch evaluation.
>>>>> I will await your feedback from talking to Robert.
>>>>> jonasbn
>>>>> On 12/11/2008, at 21.37, Jim Brandt wrote:
>>>>>> I'm ok with the principle of the patch. The special 'test'
>>>>>> conditions are conditions with raw Perl code rather than an
>>>>>> explicit
>>>>>> condition object. The _create_condition_objects sub then creates a
>>>>>> condition object on the fly for each of these. The problem is the
>>>>>> name of each auto-generated condition object is hard-coded to
>>>>>> 'evaluate'.
>>>>>>
>>>>>> I would want to verify if the 'evaluate' name is a magic name used
>>>>>> somewhere else in the code such that it expects it to be hard
>>>>>> coded
>>>>>> that way.
>>>>>>
>>>>>> Also, the patch uses the value of the test attribute as the name.
>>>>>> While this would guarantee that it will be unique, it could be an
>>>>>> arbitrarily large hash key (you can put in as much perl code as
>>>>>> you
>>>>>> want) and it wouldn't be very human readable if you were ever
>>>>>> debugging.
>>>>>>
>>>>>> I would suggest adding some code to name it something like:
>>>>>>
>>>>>> "_" . <action_name> . "_condition_" . $counter
>>>>>>
>>>>>> where action_name is the name of the enclosing action and the
>>>>>> counter is to allow us to have multiple 'test' type conditions for
>>>>>> an action. The leading underscore is just to indicate that is is
>>>>>> private (auto-generated). So if you were debugging, the names of
>>>>>> these condition objects would look something like:
>>>>>>
>>>>>> _MyAction_condition_1
>>>>>>
>>>>>> I work with Bob (Robert), so we'll discuss in the next day or two.
>>>>>>
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>> Jonas Brømsø Nielsen wrote:
>>>>>>> Hello All,
>>>>>>> I have not received any feedback and I am reluctant to making a
>>>>>>> development release for a one-line patch, I was hoping we would
>>>>>>> be
>>>>>>> able to evaluate this and decide simply on the contents of the
>>>>>>> patch.
>>>>>>> The issue is described below and the patch goes for line: 349 in
>>>>>>> HEAD
>>>>>>> The line:
>>>>>>>      name  => 'evaluate',
>>>>>>> Roberts wants changed to:
>>>>>>>      name => "_$condition_info->{test}",
>>>>>>> I have not really gotten my head around the condition objects (I
>>>>>>> should do this soon since our docs needs a serious update).
>>>>>>> But this comment just above makes me hesitate applying the patch:
>>>>>>>      # Special case: a 'test' denotes our 'evaluate' condition
>>>>>>> So I guess the evaluate name is supposed to be hard-coded.
>>>>>>> However
>>>>>>> Roberts patch does seem to offer some flexibility. But then the _
>>>>>>> (underscore) troubles me.
>>>>>>> I am going to go over the tests covering this part later tonight,
>>>>>>> but
>>>>>>> if anybody has suggestions or opinions on this please feel free
>>>>>>> to
>>>>>>> write me (the list). Jim, I am particularly interested in your
>>>>>>> opinion :)
>>>>>>> Now I will go for my run to clear my head then I will look at the
>>>>>>> code.
>>>>>>> jonasbn
>>>>>>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>>>>>>> Hiya Alll,
>>>>>>>>
>>>>>>>> We have received a patch from Robert Stockdale.
>>>>>>>>
>>>>>>>> If anybody has time to evaluate it, please feel free.
>>>>>>>>
>>>>>>>> jonasbn
>>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>>>>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>>>>>>> To: undisclosed-recipients:;
>>>>>>>>> Subject: [rt.cpan.org #38024] all conditions with 'test'
>>>>>>>>> attirbute
>>>>>>>>> appears to be cached as 'evaluate'
>>>>>>>>> Reply-To: bug...@rt...
>>>>>>>>>
>>>>>>>>>   Queue: Workflow
>>>>>>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>>>>>>>
>>>>>>>>> Hi Jonas,
>>>>>>>>>
>>>>>>>>> Sorry for the delay. I was able to confirm this bug.
>>>>>>>>>
>>>>>>>>> The name is being explicitly set to 'evaluate' in
>>>>>>>>> Workflow::State::_create_condition_objects for all conditions
>>>>>>>>> that
>>>>>>>>> specify 'test' as an attribute in the xml configuration. This,
>>>>>>>>> coupled
>>>>>>>>> along with caching of condition results means that only the
>>>>>>>>> first
>>>>>>>>> 'evaluate' condition will actually be evaluated and each
>>>>>>>>> subsequent
>>>>>>>>> call
>>>>>>>>> will use the cached result.
>>>>>>>>>
>>>>>>>>> Attached is a patch that will resolve the issue. Essentially
>>>>>>>>> I am
>>>>>>>>> just
>>>>>>>>> taking the value of the 'test' attribute and naming the
>>>>>>>>> condition
>>>>>>>>> that,
>>>>>>>>> with one small exception. Perl seems to have some issue with
>>>>>>>>> keys
>>>>>>>>> that
>>>>>>>>> start with '!' so I prefixed it with an underscore. I tested
>>>>>>>>> this
>>>>>>>>> change
>>>>>>>>> and it is working in my dev environment.
>>>>>>>>>
>>>>>>>>> An alternative option would be to allow the user to specify the
>>>>>>>>> 'name'
>>>>>>>>> attribute in the xml just like with any other condition. I did
>>>>>>>>> not
>>>>>>>>> exercise this option.
>>>>>>>>>
>>>>>>>>> -Bob
>>>>>>>> <evaluate_condition_name.patch>
>>>>>> --
>>>>>> Jim Brandt
>>>>>> Administrative Computing Services
>>>>>> University at Buffalo
>>>>>>
>>>>
>>>> --
>>>> Jim Brandt
>>>> Administrative Computing Services
>>>> University at Buffalo
>>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Perl-workflow-devel mailing list
>>> Per...@li...
>>> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
>>
>

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jonas B. N. <jo...@gm...>]

Hi Robert,

You are more than welcome to get commit rights to our hosted  
subversion repository.

We are currently hosted at SourceForge so it requires an account there.

Or you can send me the whole thing and I will sort it out.

Thanks for taking the time and effort to do the extra iteration, I  
think it will prove to be worth while.

jonasbn

On 18/11/2008, at 20.37, Stockdale, Robert wrote:

> I attached the updated patch file to the RT ticket:
>
>    http://rt.cpan.org/Ticket/Display.html?id=38024
>
> Also, I wrote some automated tests for this change. What is the best  
> way to
> get them into the distribution?
>
> --
> Bob Stockdale
> Administrative Computing Services
> University at Buffalo
> (716) 645-5334
> rf...@bu...
>
>
>> From: Jonas Brømsø Nielsen <jo...@gm...>
>> Date: Mon, 17 Nov 2008 15:22:42 -0500
>> To: "Brandt, Carl" <cb...@bu...>
>> Cc: Workflow development list <per...@li...>
>> Subject: Re: [Perl-workflow-devel] [rt.cpan.org #38024] all  
>> conditions with
>> 'test' attirbute appears to be cached as 'evaluate'
>>
>> Sounds good.
>>
>> I was started to thinking along the lines of using Data::UUID to
>> generate the unique names, but that would probably just warp the
>> developers minds completely.
>>
>> I am looking for to the patch - we can get a development release out
>> of the door the moment it can be applied. This will also let other
>> developers evaluate the patch easily.
>>
>>
>> jonasbn
>>
>> On 17/11/2008, at 21.18, Jim Brandt wrote:
>>
>>> We discussed and came up with the following. Bob will be following
>>> up with a patch after some testing.
>>>
>>> * With regard to conditions, the name 'evaluate' is only used when
>>> creating the Condition::Evaluate object. It seems when conditions
>>> are evaluated, the sub just cycles through all conditions in the
>>> conditions array, so the name 'evaluate' isn't special in any way.
>>>
>>> * Naming for the auto-generated conditions
>>>
>>> When the condition fails, the name of the condition is written out
>>> to log4perl, so previous to the patch users would see that the
>>> 'evaluate' condition failed, which tells them that it was a 'test'
>>> condition, but does not tell them which one.
>>>
>>> Bob suggested even more detail in the name, like:
>>>
>>> "_$state\_$action\_condition\_$counter" so for example:
>>>
>>> _Begin_SA_condition_1
>>>
>>> If you had a problem, this would point you directly to the state-
>>>> action->in-line condition where your perl code is. I believe Bob
>>> said all of that information is easy to get inside the state object.
>>>
>>>
>>> Jim
>>>
>>> Jonas Brømsø Nielsen wrote:
>>>> Hi Jim,
>>>> Thanks for the explanation, it was something along the lines of
>>>> what I
>>>> expected. Not being a user of this functionality however, I just
>>>> needed some hand-holding on the patch evaluation.
>>>> I will await your feedback from talking to Robert.
>>>> jonasbn
>>>> On 12/11/2008, at 21.37, Jim Brandt wrote:
>>>>> I'm ok with the principle of the patch. The special 'test'
>>>>> conditions are conditions with raw Perl code rather than an  
>>>>> explicit
>>>>> condition object. The _create_condition_objects sub then creates a
>>>>> condition object on the fly for each of these. The problem is the
>>>>> name of each auto-generated condition object is hard-coded to
>>>>> 'evaluate'.
>>>>>
>>>>> I would want to verify if the 'evaluate' name is a magic name used
>>>>> somewhere else in the code such that it expects it to be hard  
>>>>> coded
>>>>> that way.
>>>>>
>>>>> Also, the patch uses the value of the test attribute as the name.
>>>>> While this would guarantee that it will be unique, it could be an
>>>>> arbitrarily large hash key (you can put in as much perl code as  
>>>>> you
>>>>> want) and it wouldn't be very human readable if you were ever
>>>>> debugging.
>>>>>
>>>>> I would suggest adding some code to name it something like:
>>>>>
>>>>> "_" . <action_name> . "_condition_" . $counter
>>>>>
>>>>> where action_name is the name of the enclosing action and the
>>>>> counter is to allow us to have multiple 'test' type conditions for
>>>>> an action. The leading underscore is just to indicate that is is
>>>>> private (auto-generated). So if you were debugging, the names of
>>>>> these condition objects would look something like:
>>>>>
>>>>> _MyAction_condition_1
>>>>>
>>>>> I work with Bob (Robert), so we'll discuss in the next day or two.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>> Jonas Brømsø Nielsen wrote:
>>>>>> Hello All,
>>>>>> I have not received any feedback and I am reluctant to making a
>>>>>> development release for a one-line patch, I was hoping we would  
>>>>>> be
>>>>>> able to evaluate this and decide simply on the contents of the
>>>>>> patch.
>>>>>> The issue is described below and the patch goes for line: 349 in
>>>>>> HEAD
>>>>>> The line:
>>>>>>      name  => 'evaluate',
>>>>>> Roberts wants changed to:
>>>>>>      name => "_$condition_info->{test}",
>>>>>> I have not really gotten my head around the condition objects (I
>>>>>> should do this soon since our docs needs a serious update).
>>>>>> But this comment just above makes me hesitate applying the patch:
>>>>>>      # Special case: a 'test' denotes our 'evaluate' condition
>>>>>> So I guess the evaluate name is supposed to be hard-coded.  
>>>>>> However
>>>>>> Roberts patch does seem to offer some flexibility. But then the _
>>>>>> (underscore) troubles me.
>>>>>> I am going to go over the tests covering this part later tonight,
>>>>>> but
>>>>>> if anybody has suggestions or opinions on this please feel free  
>>>>>> to
>>>>>> write me (the list). Jim, I am particularly interested in your
>>>>>> opinion :)
>>>>>> Now I will go for my run to clear my head then I will look at the
>>>>>> code.
>>>>>> jonasbn
>>>>>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>>>>>> Hiya Alll,
>>>>>>>
>>>>>>> We have received a patch from Robert Stockdale.
>>>>>>>
>>>>>>> If anybody has time to evaluate it, please feel free.
>>>>>>>
>>>>>>> jonasbn
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>>>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>>>>>> To: undisclosed-recipients:;
>>>>>>>> Subject: [rt.cpan.org #38024] all conditions with 'test'
>>>>>>>> attirbute
>>>>>>>> appears to be cached as 'evaluate'
>>>>>>>> Reply-To: bug...@rt...
>>>>>>>>
>>>>>>>>   Queue: Workflow
>>>>>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>>>>>>
>>>>>>>> Hi Jonas,
>>>>>>>>
>>>>>>>> Sorry for the delay. I was able to confirm this bug.
>>>>>>>>
>>>>>>>> The name is being explicitly set to 'evaluate' in
>>>>>>>> Workflow::State::_create_condition_objects for all conditions
>>>>>>>> that
>>>>>>>> specify 'test' as an attribute in the xml configuration. This,
>>>>>>>> coupled
>>>>>>>> along with caching of condition results means that only the  
>>>>>>>> first
>>>>>>>> 'evaluate' condition will actually be evaluated and each
>>>>>>>> subsequent
>>>>>>>> call
>>>>>>>> will use the cached result.
>>>>>>>>
>>>>>>>> Attached is a patch that will resolve the issue. Essentially  
>>>>>>>> I am
>>>>>>>> just
>>>>>>>> taking the value of the 'test' attribute and naming the  
>>>>>>>> condition
>>>>>>>> that,
>>>>>>>> with one small exception. Perl seems to have some issue with  
>>>>>>>> keys
>>>>>>>> that
>>>>>>>> start with '!' so I prefixed it with an underscore. I tested  
>>>>>>>> this
>>>>>>>> change
>>>>>>>> and it is working in my dev environment.
>>>>>>>>
>>>>>>>> An alternative option would be to allow the user to specify the
>>>>>>>> 'name'
>>>>>>>> attribute in the xml just like with any other condition. I did
>>>>>>>> not
>>>>>>>> exercise this option.
>>>>>>>>
>>>>>>>> -Bob
>>>>>>> <evaluate_condition_name.patch>
>>>>> --
>>>>> Jim Brandt
>>>>> Administrative Computing Services
>>>>> University at Buffalo
>>>>>
>>>
>>> --
>>> Jim Brandt
>>> Administrative Computing Services
>>> University at Buffalo
>>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Perl-workflow-devel mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
>

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Stockdale, R. <rf...@bu...>]

I attached the updated patch file to the RT ticket:

    http://rt.cpan.org/Ticket/Display.html?id=38024

Also, I wrote some automated tests for this change. What is the best way to
get them into the distribution?

--
Bob Stockdale
Administrative Computing Services
University at Buffalo
(716) 645-5334
rf...@bu...


> From: Jonas Brømsø Nielsen <jo...@gm...>
> Date: Mon, 17 Nov 2008 15:22:42 -0500
> To: "Brandt, Carl" <cb...@bu...>
> Cc: Workflow development list <per...@li...>
> Subject: Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with
> 'test' attirbute appears to be cached as 'evaluate'
>
> Sounds good.
>
> I was started to thinking along the lines of using Data::UUID to
> generate the unique names, but that would probably just warp the
> developers minds completely.
>
> I am looking for to the patch - we can get a development release out
> of the door the moment it can be applied. This will also let other
> developers evaluate the patch easily.
>
>
> jonasbn
>
> On 17/11/2008, at 21.18, Jim Brandt wrote:
>
>> We discussed and came up with the following. Bob will be following
>> up with a patch after some testing.
>>
>> * With regard to conditions, the name 'evaluate' is only used when
>> creating the Condition::Evaluate object. It seems when conditions
>> are evaluated, the sub just cycles through all conditions in the
>> conditions array, so the name 'evaluate' isn't special in any way.
>>
>> * Naming for the auto-generated conditions
>>
>> When the condition fails, the name of the condition is written out
>> to log4perl, so previous to the patch users would see that the
>> 'evaluate' condition failed, which tells them that it was a 'test'
>> condition, but does not tell them which one.
>>
>> Bob suggested even more detail in the name, like:
>>
>> "_$state\_$action\_condition\_$counter" so for example:
>>
>> _Begin_SA_condition_1
>>
>> If you had a problem, this would point you directly to the state-
>>> action->in-line condition where your perl code is. I believe Bob
>> said all of that information is easy to get inside the state object.
>>
>>
>> Jim
>>
>> Jonas Brømsø Nielsen wrote:
>>> Hi Jim,
>>> Thanks for the explanation, it was something along the lines of
>>> what I
>>> expected. Not being a user of this functionality however, I just
>>> needed some hand-holding on the patch evaluation.
>>> I will await your feedback from talking to Robert.
>>> jonasbn
>>> On 12/11/2008, at 21.37, Jim Brandt wrote:
>>>> I'm ok with the principle of the patch. The special 'test'
>>>> conditions are conditions with raw Perl code rather than an explicit
>>>> condition object. The _create_condition_objects sub then creates a
>>>> condition object on the fly for each of these. The problem is the
>>>> name of each auto-generated condition object is hard-coded to
>>>> 'evaluate'.
>>>>
>>>> I would want to verify if the 'evaluate' name is a magic name used
>>>> somewhere else in the code such that it expects it to be hard coded
>>>> that way.
>>>>
>>>> Also, the patch uses the value of the test attribute as the name.
>>>> While this would guarantee that it will be unique, it could be an
>>>> arbitrarily large hash key (you can put in as much perl code as you
>>>> want) and it wouldn't be very human readable if you were ever
>>>> debugging.
>>>>
>>>> I would suggest adding some code to name it something like:
>>>>
>>>> "_" . <action_name> . "_condition_" . $counter
>>>>
>>>> where action_name is the name of the enclosing action and the
>>>> counter is to allow us to have multiple 'test' type conditions for
>>>> an action. The leading underscore is just to indicate that is is
>>>> private (auto-generated). So if you were debugging, the names of
>>>> these condition objects would look something like:
>>>>
>>>> _MyAction_condition_1
>>>>
>>>> I work with Bob (Robert), so we'll discuss in the next day or two.
>>>>
>>>> Jim
>>>>
>>>>
>>>> Jonas Brømsø Nielsen wrote:
>>>>> Hello All,
>>>>> I have not received any feedback and I am reluctant to making a
>>>>> development release for a one-line patch, I was hoping we would be
>>>>> able to evaluate this and decide simply on the contents of the
>>>>> patch.
>>>>> The issue is described below and the patch goes for line: 349 in
>>>>> HEAD
>>>>> The line:
>>>>>       name  => 'evaluate',
>>>>> Roberts wants changed to:
>>>>>       name => "_$condition_info->{test}",
>>>>> I have not really gotten my head around the condition objects (I
>>>>> should do this soon since our docs needs a serious update).
>>>>> But this comment just above makes me hesitate applying the patch:
>>>>>       # Special case: a 'test' denotes our 'evaluate' condition
>>>>> So I guess the evaluate name is supposed to be hard-coded. However
>>>>> Roberts patch does seem to offer some flexibility. But then the _
>>>>> (underscore) troubles me.
>>>>> I am going to go over the tests covering this part later tonight,
>>>>> but
>>>>> if anybody has suggestions or opinions on this please feel free to
>>>>> write me (the list). Jim, I am particularly interested in your
>>>>> opinion :)
>>>>> Now I will go for my run to clear my head then I will look at the
>>>>> code.
>>>>> jonasbn
>>>>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>>>>> Hiya Alll,
>>>>>>
>>>>>> We have received a patch from Robert Stockdale.
>>>>>>
>>>>>> If anybody has time to evaluate it, please feel free.
>>>>>>
>>>>>> jonasbn
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>>>>> To: undisclosed-recipients:;
>>>>>>> Subject: [rt.cpan.org #38024] all conditions with 'test'
>>>>>>> attirbute
>>>>>>> appears to be cached as 'evaluate'
>>>>>>> Reply-To: bug...@rt...
>>>>>>>
>>>>>>>    Queue: Workflow
>>>>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>>>>>
>>>>>>> Hi Jonas,
>>>>>>>
>>>>>>> Sorry for the delay. I was able to confirm this bug.
>>>>>>>
>>>>>>> The name is being explicitly set to 'evaluate' in
>>>>>>> Workflow::State::_create_condition_objects for all conditions
>>>>>>> that
>>>>>>> specify 'test' as an attribute in the xml configuration. This,
>>>>>>> coupled
>>>>>>> along with caching of condition results means that only the first
>>>>>>> 'evaluate' condition will actually be evaluated and each
>>>>>>> subsequent
>>>>>>> call
>>>>>>> will use the cached result.
>>>>>>>
>>>>>>> Attached is a patch that will resolve the issue. Essentially I am
>>>>>>> just
>>>>>>> taking the value of the 'test' attribute and naming the condition
>>>>>>> that,
>>>>>>> with one small exception. Perl seems to have some issue with keys
>>>>>>> that
>>>>>>> start with '!' so I prefixed it with an underscore. I tested this
>>>>>>> change
>>>>>>> and it is working in my dev environment.
>>>>>>>
>>>>>>> An alternative option would be to allow the user to specify the
>>>>>>> 'name'
>>>>>>> attribute in the xml just like with any other condition. I did
>>>>>>> not
>>>>>>> exercise this option.
>>>>>>>
>>>>>>> -Bob
>>>>>> <evaluate_condition_name.patch>
>>>> --
>>>> Jim Brandt
>>>> Administrative Computing Services
>>>> University at Buffalo
>>>>
>>
>> --
>> Jim Brandt
>> Administrative Computing Services
>> University at Buffalo
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jonas B. N. <jo...@gm...>]

Sounds good.

I was started to thinking along the lines of using Data::UUID to  
generate the unique names, but that would probably just warp the  
developers minds completely.

I am looking for to the patch - we can get a development release out  
of the door the moment it can be applied. This will also let other  
developers evaluate the patch easily.


jonasbn

On 17/11/2008, at 21.18, Jim Brandt wrote:

> We discussed and came up with the following. Bob will be following  
> up with a patch after some testing.
>
> * With regard to conditions, the name 'evaluate' is only used when  
> creating the Condition::Evaluate object. It seems when conditions  
> are evaluated, the sub just cycles through all conditions in the  
> conditions array, so the name 'evaluate' isn't special in any way.
>
> * Naming for the auto-generated conditions
>
> When the condition fails, the name of the condition is written out  
> to log4perl, so previous to the patch users would see that the  
> 'evaluate' condition failed, which tells them that it was a 'test'  
> condition, but does not tell them which one.
>
> Bob suggested even more detail in the name, like:
>
> "_$state\_$action\_condition\_$counter" so for example:
>
> _Begin_SA_condition_1
>
> If you had a problem, this would point you directly to the state- 
> >action->in-line condition where your perl code is. I believe Bob  
> said all of that information is easy to get inside the state object.
>
>
> Jim
>
> Jonas Brømsø Nielsen wrote:
>> Hi Jim,
>> Thanks for the explanation, it was something along the lines of  
>> what I
>> expected. Not being a user of this functionality however, I just
>> needed some hand-holding on the patch evaluation.
>> I will await your feedback from talking to Robert.
>> jonasbn
>> On 12/11/2008, at 21.37, Jim Brandt wrote:
>>> I'm ok with the principle of the patch. The special 'test'
>>> conditions are conditions with raw Perl code rather than an explicit
>>> condition object. The _create_condition_objects sub then creates a
>>> condition object on the fly for each of these. The problem is the
>>> name of each auto-generated condition object is hard-coded to
>>> 'evaluate'.
>>>
>>> I would want to verify if the 'evaluate' name is a magic name used
>>> somewhere else in the code such that it expects it to be hard coded
>>> that way.
>>>
>>> Also, the patch uses the value of the test attribute as the name.
>>> While this would guarantee that it will be unique, it could be an
>>> arbitrarily large hash key (you can put in as much perl code as you
>>> want) and it wouldn't be very human readable if you were ever
>>> debugging.
>>>
>>> I would suggest adding some code to name it something like:
>>>
>>> "_" . <action_name> . "_condition_" . $counter
>>>
>>> where action_name is the name of the enclosing action and the
>>> counter is to allow us to have multiple 'test' type conditions for
>>> an action. The leading underscore is just to indicate that is is
>>> private (auto-generated). So if you were debugging, the names of
>>> these condition objects would look something like:
>>>
>>> _MyAction_condition_1
>>>
>>> I work with Bob (Robert), so we'll discuss in the next day or two.
>>>
>>> Jim
>>>
>>>
>>> Jonas Brømsø Nielsen wrote:
>>>> Hello All,
>>>> I have not received any feedback and I am reluctant to making a
>>>> development release for a one-line patch, I was hoping we would be
>>>> able to evaluate this and decide simply on the contents of the  
>>>> patch.
>>>> The issue is described below and the patch goes for line: 349 in  
>>>> HEAD
>>>> The line:
>>>>       name  => 'evaluate',
>>>> Roberts wants changed to:
>>>>       name => "_$condition_info->{test}",
>>>> I have not really gotten my head around the condition objects (I
>>>> should do this soon since our docs needs a serious update).
>>>> But this comment just above makes me hesitate applying the patch:
>>>>       # Special case: a 'test' denotes our 'evaluate' condition
>>>> So I guess the evaluate name is supposed to be hard-coded. However
>>>> Roberts patch does seem to offer some flexibility. But then the _
>>>> (underscore) troubles me.
>>>> I am going to go over the tests covering this part later tonight,  
>>>> but
>>>> if anybody has suggestions or opinions on this please feel free to
>>>> write me (the list). Jim, I am particularly interested in your
>>>> opinion :)
>>>> Now I will go for my run to clear my head then I will look at the
>>>> code.
>>>> jonasbn
>>>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>>>> Hiya Alll,
>>>>>
>>>>> We have received a patch from Robert Stockdale.
>>>>>
>>>>> If anybody has time to evaluate it, please feel free.
>>>>>
>>>>> jonasbn
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>>>> To: undisclosed-recipients:;
>>>>>> Subject: [rt.cpan.org #38024] all conditions with 'test'  
>>>>>> attirbute
>>>>>> appears to be cached as 'evaluate'
>>>>>> Reply-To: bug...@rt...
>>>>>>
>>>>>>    Queue: Workflow
>>>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>>>>
>>>>>> Hi Jonas,
>>>>>>
>>>>>> Sorry for the delay. I was able to confirm this bug.
>>>>>>
>>>>>> The name is being explicitly set to 'evaluate' in
>>>>>> Workflow::State::_create_condition_objects for all conditions  
>>>>>> that
>>>>>> specify 'test' as an attribute in the xml configuration. This,
>>>>>> coupled
>>>>>> along with caching of condition results means that only the first
>>>>>> 'evaluate' condition will actually be evaluated and each  
>>>>>> subsequent
>>>>>> call
>>>>>> will use the cached result.
>>>>>>
>>>>>> Attached is a patch that will resolve the issue. Essentially I am
>>>>>> just
>>>>>> taking the value of the 'test' attribute and naming the condition
>>>>>> that,
>>>>>> with one small exception. Perl seems to have some issue with keys
>>>>>> that
>>>>>> start with '!' so I prefixed it with an underscore. I tested this
>>>>>> change
>>>>>> and it is working in my dev environment.
>>>>>>
>>>>>> An alternative option would be to allow the user to specify the
>>>>>> 'name'
>>>>>> attribute in the xml just like with any other condition. I did  
>>>>>> not
>>>>>> exercise this option.
>>>>>>
>>>>>> -Bob
>>>>> <evaluate_condition_name.patch>
>>> --
>>> Jim Brandt
>>> Administrative Computing Services
>>> University at Buffalo
>>>
>
> -- 
> Jim Brandt
> Administrative Computing Services
> University at Buffalo
>

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jim B. <cb...@bu...>]

We discussed and came up with the following. Bob will be following up 
with a patch after some testing.

* With regard to conditions, the name 'evaluate' is only used when 
creating the Condition::Evaluate object. It seems when conditions are 
evaluated, the sub just cycles through all conditions in the conditions 
array, so the name 'evaluate' isn't special in any way.

* Naming for the auto-generated conditions

When the condition fails, the name of the condition is written out to 
log4perl, so previous to the patch users would see that the 'evaluate' 
condition failed, which tells them that it was a 'test' condition, but 
does not tell them which one.

Bob suggested even more detail in the name, like:

"_$state\_$action\_condition\_$counter" so for example:

_Begin_SA_condition_1

If you had a problem, this would point you directly to the 
state->action->in-line condition where your perl code is. I believe Bob 
said all of that information is easy to get inside the state object.


Jim

Jonas Brømsø Nielsen wrote:
> Hi Jim,
> 
> Thanks for the explanation, it was something along the lines of what I
> expected. Not being a user of this functionality however, I just
> needed some hand-holding on the patch evaluation.
> 
> I will await your feedback from talking to Robert.
> 
> jonasbn
> 
> On 12/11/2008, at 21.37, Jim Brandt wrote:
> 
>> I'm ok with the principle of the patch. The special 'test'
>> conditions are conditions with raw Perl code rather than an explicit
>> condition object. The _create_condition_objects sub then creates a
>> condition object on the fly for each of these. The problem is the
>> name of each auto-generated condition object is hard-coded to
>> 'evaluate'.
>>
>> I would want to verify if the 'evaluate' name is a magic name used
>> somewhere else in the code such that it expects it to be hard coded
>> that way.
>>
>> Also, the patch uses the value of the test attribute as the name.
>> While this would guarantee that it will be unique, it could be an
>> arbitrarily large hash key (you can put in as much perl code as you
>> want) and it wouldn't be very human readable if you were ever
>> debugging.
>>
>> I would suggest adding some code to name it something like:
>>
>> "_" . <action_name> . "_condition_" . $counter
>>
>> where action_name is the name of the enclosing action and the
>> counter is to allow us to have multiple 'test' type conditions for
>> an action. The leading underscore is just to indicate that is is
>> private (auto-generated). So if you were debugging, the names of
>> these condition objects would look something like:
>>
>> _MyAction_condition_1
>>
>> I work with Bob (Robert), so we'll discuss in the next day or two.
>>
>> Jim
>>
>>
>> Jonas Brømsø Nielsen wrote:
>>> Hello All,
>>> I have not received any feedback and I am reluctant to making a
>>> development release for a one-line patch, I was hoping we would be
>>> able to evaluate this and decide simply on the contents of the patch.
>>> The issue is described below and the patch goes for line: 349 in HEAD
>>> The line:
>>>        name  => 'evaluate',
>>> Roberts wants changed to:
>>>        name => "_$condition_info->{test}",
>>> I have not really gotten my head around the condition objects (I
>>> should do this soon since our docs needs a serious update).
>>> But this comment just above makes me hesitate applying the patch:
>>>        # Special case: a 'test' denotes our 'evaluate' condition
>>> So I guess the evaluate name is supposed to be hard-coded. However
>>> Roberts patch does seem to offer some flexibility. But then the _
>>> (underscore) troubles me.
>>> I am going to go over the tests covering this part later tonight, but
>>> if anybody has suggestions or opinions on this please feel free to
>>> write me (the list). Jim, I am particularly interested in your
>>> opinion :)
>>> Now I will go for my run to clear my head then I will look at the
>>> code.
>>> jonasbn
>>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>>> Hiya Alll,
>>>>
>>>> We have received a patch from Robert Stockdale.
>>>>
>>>> If anybody has time to evaluate it, please feel free.
>>>>
>>>> jonasbn
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>>> To: undisclosed-recipients:;
>>>>> Subject: [rt.cpan.org #38024] all conditions with 'test' attirbute
>>>>> appears to be cached as 'evaluate'
>>>>> Reply-To: bug...@rt...
>>>>>
>>>>>     Queue: Workflow
>>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>>>
>>>>> Hi Jonas,
>>>>>
>>>>> Sorry for the delay. I was able to confirm this bug.
>>>>>
>>>>> The name is being explicitly set to 'evaluate' in
>>>>> Workflow::State::_create_condition_objects for all conditions that
>>>>> specify 'test' as an attribute in the xml configuration. This,
>>>>> coupled
>>>>> along with caching of condition results means that only the first
>>>>> 'evaluate' condition will actually be evaluated and each subsequent
>>>>> call
>>>>> will use the cached result.
>>>>>
>>>>> Attached is a patch that will resolve the issue. Essentially I am
>>>>> just
>>>>> taking the value of the 'test' attribute and naming the condition
>>>>> that,
>>>>> with one small exception. Perl seems to have some issue with keys
>>>>> that
>>>>> start with '!' so I prefixed it with an underscore. I tested this
>>>>> change
>>>>> and it is working in my dev environment.
>>>>>
>>>>> An alternative option would be to allow the user to specify the
>>>>> 'name'
>>>>> attribute in the xml just like with any other condition. I did not
>>>>> exercise this option.
>>>>>
>>>>> -Bob
>>>> <evaluate_condition_name.patch>
>> --
>> Jim Brandt
>> Administrative Computing Services
>> University at Buffalo
>>
> 

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

[Perl-workflow-devel] 0.32_5 released was: Re: 0.32_4 failing tests - addressed

[Jonas B. N. <jo...@gm...>]

Hiya,

I have released 0.32_5 addressing failing tests... this does not solve  
all the problems with failing tests, but it does address quite a few  
of the failing tests related to a path interpretation in the test suite.

jonasbn

On 13/11/2008, at 09.33, Jonas Brømsø Nielsen wrote:

> Hello All,
>
> I have fixed a problem demonstrated in a lot of failing tests.
>
> 	http://www.cpantesters.org/show/Workflow.html#Workflow-0.32_4
>
> See the branch't_vs_struct':
>
> http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/t_vs_struct/
>
> The branch itself demonstrates the bug, since the expected root  
> directory does not contain the subdirectory workflow.
>
> See:
>
> 	Changes
> 	t/TestDBUtil.pm
> 	t/persister_dbi_sqlite.t
>
> So if you have no objections I will make a developer release 0.32_5  
> sometime today
>
> jonasbn
> --
> pauseid: JONASBN
> email: jo...@cp...
> blog: http://use.perl.org/~jonasbn/journal/
>
>



--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

[Perl-workflow-devel] 0.32_4 failing tests - addressed

[Jonas B. N. <jo...@gm...>]

Hello All,

I have fixed a problem demonstrated in a lot of failing tests.

	http://www.cpantesters.org/show/Workflow.html#Workflow-0.32_4

See the branch't_vs_struct':

http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/t_vs_struct/

The branch itself demonstrates the bug, since the expected root  
directory does not contain the subdirectory workflow.

See:

	Changes
	t/TestDBUtil.pm
	t/persister_dbi_sqlite.t

So if you have no objections I will make a developer release 0.32_5  
sometime today

jonasbn
--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jonas B. N. <jo...@gm...>]

Hi Jim,

Thanks for the explanation, it was something along the lines of what I  
expected. Not being a user of this functionality however, I just  
needed some hand-holding on the patch evaluation.

I will await your feedback from talking to Robert.

jonasbn

On 12/11/2008, at 21.37, Jim Brandt wrote:

> I'm ok with the principle of the patch. The special 'test'  
> conditions are conditions with raw Perl code rather than an explicit  
> condition object. The _create_condition_objects sub then creates a  
> condition object on the fly for each of these. The problem is the  
> name of each auto-generated condition object is hard-coded to  
> 'evaluate'.
>
> I would want to verify if the 'evaluate' name is a magic name used  
> somewhere else in the code such that it expects it to be hard coded  
> that way.
>
> Also, the patch uses the value of the test attribute as the name.  
> While this would guarantee that it will be unique, it could be an  
> arbitrarily large hash key (you can put in as much perl code as you  
> want) and it wouldn't be very human readable if you were ever  
> debugging.
>
> I would suggest adding some code to name it something like:
>
> "_" . <action_name> . "_condition_" . $counter
>
> where action_name is the name of the enclosing action and the  
> counter is to allow us to have multiple 'test' type conditions for  
> an action. The leading underscore is just to indicate that is is  
> private (auto-generated). So if you were debugging, the names of  
> these condition objects would look something like:
>
> _MyAction_condition_1
>
> I work with Bob (Robert), so we'll discuss in the next day or two.
>
> Jim
>
>
> Jonas Brømsø Nielsen wrote:
>> Hello All,
>> I have not received any feedback and I am reluctant to making a
>> development release for a one-line patch, I was hoping we would be
>> able to evaluate this and decide simply on the contents of the patch.
>> The issue is described below and the patch goes for line: 349 in HEAD
>> The line:
>>        name  => 'evaluate',
>> Roberts wants changed to:
>>        name => "_$condition_info->{test}",
>> I have not really gotten my head around the condition objects (I
>> should do this soon since our docs needs a serious update).
>> But this comment just above makes me hesitate applying the patch:
>>        # Special case: a 'test' denotes our 'evaluate' condition
>> So I guess the evaluate name is supposed to be hard-coded. However
>> Roberts patch does seem to offer some flexibility. But then the _
>> (underscore) troubles me.
>> I am going to go over the tests covering this part later tonight, but
>> if anybody has suggestions or opinions on this please feel free to
>> write me (the list). Jim, I am particularly interested in your
>> opinion :)
>> Now I will go for my run to clear my head then I will look at the  
>> code.
>> jonasbn
>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>> Hiya Alll,
>>>
>>> We have received a patch from Robert Stockdale.
>>>
>>> If anybody has time to evaluate it, please feel free.
>>>
>>> jonasbn
>>>
>>> Begin forwarded message:
>>>
>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>> To: undisclosed-recipients:;
>>>> Subject: [rt.cpan.org #38024] all conditions with 'test' attirbute
>>>> appears to be cached as 'evaluate'
>>>> Reply-To: bug...@rt...
>>>>
>>>>     Queue: Workflow
>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>>
>>>> Hi Jonas,
>>>>
>>>> Sorry for the delay. I was able to confirm this bug.
>>>>
>>>> The name is being explicitly set to 'evaluate' in
>>>> Workflow::State::_create_condition_objects for all conditions that
>>>> specify 'test' as an attribute in the xml configuration. This,
>>>> coupled
>>>> along with caching of condition results means that only the first
>>>> 'evaluate' condition will actually be evaluated and each subsequent
>>>> call
>>>> will use the cached result.
>>>>
>>>> Attached is a patch that will resolve the issue. Essentially I am
>>>> just
>>>> taking the value of the 'test' attribute and naming the condition
>>>> that,
>>>> with one small exception. Perl seems to have some issue with keys
>>>> that
>>>> start with '!' so I prefixed it with an underscore. I tested this
>>>> change
>>>> and it is working in my dev environment.
>>>>
>>>> An alternative option would be to allow the user to specify the
>>>> 'name'
>>>> attribute in the xml just like with any other condition. I did not
>>>> exercise this option.
>>>>
>>>> -Bob
>>> <evaluate_condition_name.patch>
>
> -- 
> Jim Brandt
> Administrative Computing Services
> University at Buffalo
>

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jim B. <cb...@bu...>]

I'm ok with the principle of the patch. The special 'test' conditions 
are conditions with raw Perl code rather than an explicit condition 
object. The _create_condition_objects sub then creates a condition 
object on the fly for each of these. The problem is the name of each 
auto-generated condition object is hard-coded to 'evaluate'.

I would want to verify if the 'evaluate' name is a magic name used 
somewhere else in the code such that it expects it to be hard coded that 
way.

Also, the patch uses the value of the test attribute as the name. While 
this would guarantee that it will be unique, it could be an arbitrarily 
large hash key (you can put in as much perl code as you want) and it 
wouldn't be very human readable if you were ever debugging.

I would suggest adding some code to name it something like:

"_" . <action_name> . "_condition_" . $counter

where action_name is the name of the enclosing action and the counter is 
to allow us to have multiple 'test' type conditions for an action. The 
leading underscore is just to indicate that is is private 
(auto-generated). So if you were debugging, the names of these condition 
objects would look something like:

_MyAction_condition_1

I work with Bob (Robert), so we'll discuss in the next day or two.

Jim


Jonas Brømsø Nielsen wrote:
> Hello All,
> 
> I have not received any feedback and I am reluctant to making a
> development release for a one-line patch, I was hoping we would be
> able to evaluate this and decide simply on the contents of the patch.
> 
> The issue is described below and the patch goes for line: 349 in HEAD
> 
> The line:
>         name  => 'evaluate',
> 
> Roberts wants changed to:
> 
>         name => "_$condition_info->{test}",
> 
> I have not really gotten my head around the condition objects (I
> should do this soon since our docs needs a serious update).
> 
> But this comment just above makes me hesitate applying the patch:
> 
>         # Special case: a 'test' denotes our 'evaluate' condition
> 
> So I guess the evaluate name is supposed to be hard-coded. However
> Roberts patch does seem to offer some flexibility. But then the _
> (underscore) troubles me.
> 
> I am going to go over the tests covering this part later tonight, but
> if anybody has suggestions or opinions on this please feel free to
> write me (the list). Jim, I am particularly interested in your
> opinion :)
> 
> Now I will go for my run to clear my head then I will look at the code.
> 
> 
> jonasbn
> 
> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
> 
>> Hiya Alll,
>>
>> We have received a patch from Robert Stockdale.
>>
>> If anybody has time to evaluate it, please feel free.
>>
>> jonasbn
>>
>> Begin forwarded message:
>>
>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>> To: undisclosed-recipients:;
>>> Subject: [rt.cpan.org #38024] all conditions with 'test' attirbute
>>> appears to be cached as 'evaluate'
>>> Reply-To: bug...@rt...
>>>
>>>      Queue: Workflow
>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>>
>>> Hi Jonas,
>>>
>>> Sorry for the delay. I was able to confirm this bug.
>>>
>>> The name is being explicitly set to 'evaluate' in
>>> Workflow::State::_create_condition_objects for all conditions that
>>> specify 'test' as an attribute in the xml configuration. This,
>>> coupled
>>> along with caching of condition results means that only the first
>>> 'evaluate' condition will actually be evaluated and each subsequent
>>> call
>>> will use the cached result.
>>>
>>> Attached is a patch that will resolve the issue. Essentially I am
>>> just
>>> taking the value of the 'test' attribute and naming the condition
>>> that,
>>> with one small exception. Perl seems to have some issue with keys
>>> that
>>> start with '!' so I prefixed it with an underscore. I tested this
>>> change
>>> and it is working in my dev environment.
>>>
>>> An alternative option would be to allow the user to specify the
>>> 'name'
>>> attribute in the xml just like with any other condition. I did not
>>> exercise this option.
>>>
>>> -Bob
>> <evaluate_condition_name.patch>
> 

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jonas B. N. <jo...@gm...>]

Hello All,

I have not received any feedback and I am reluctant to making a  
development release for a one-line patch, I was hoping we would be  
able to evaluate this and decide simply on the contents of the patch.

The issue is described below and the patch goes for line: 349 in HEAD

The line:
	name  => 'evaluate',

Roberts wants changed to:

	name => "_$condition_info->{test}",

I have not really gotten my head around the condition objects (I  
should do this soon since our docs needs a serious update).

But this comment just above makes me hesitate applying the patch:

	# Special case: a 'test' denotes our 'evaluate' condition

So I guess the evaluate name is supposed to be hard-coded. However  
Roberts patch does seem to offer some flexibility. But then the _  
(underscore) troubles me.

I am going to go over the tests covering this part later tonight, but  
if anybody has suggestions or opinions on this please feel free to  
write me (the list). Jim, I am particularly interested in your  
opinion :)

Now I will go for my run to clear my head then I will look at the code.


jonasbn

On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:

> Hiya Alll,
>
> We have received a patch from Robert Stockdale.
>
> If anybody has time to evaluate it, please feel free.
>
> jonasbn
>
> Begin forwarded message:
>
>> From: "Robert Stockdale via RT" <bug...@rt...>
>> Date: 29. sep 2008 21.48.42 GMT+02:00
>> To: undisclosed-recipients:;
>> Subject: [rt.cpan.org #38024] all conditions with 'test' attirbute  
>> appears to be cached as 'evaluate'
>> Reply-To: bug...@rt...
>>
>>      Queue: Workflow
>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>>
>> Hi Jonas,
>>
>> Sorry for the delay. I was able to confirm this bug.
>>
>> The name is being explicitly set to 'evaluate' in
>> Workflow::State::_create_condition_objects for all conditions that
>> specify 'test' as an attribute in the xml configuration. This,  
>> coupled
>> along with caching of condition results means that only the first
>> 'evaluate' condition will actually be evaluated and each subsequent  
>> call
>> will use the cached result.
>>
>> Attached is a patch that will resolve the issue. Essentially I am  
>> just
>> taking the value of the 'test' attribute and naming the condition  
>> that,
>> with one small exception. Perl seems to have some issue with keys  
>> that
>> start with '!' so I prefixed it with an underscore. I tested this  
>> change
>> and it is working in my dev environment.
>>
>> An alternative option would be to allow the user to specify the  
>> 'name'
>> attribute in the xml just like with any other condition. I did not
>> exercise this option.
>>
>> -Bob
> <evaluate_condition_name.patch>

Re: [Perl-workflow-devel] [rt.cpan.org #40750] Version mismatch between module and tarball

[Jonas B. N. <jo...@gm...>]

Hello All,

After some consideration I have decided to comply with the lines  
suggested in the RT

The only impact will be that next public release will probably jump  
from what should have been 0.32 to 1.32 and from the on the VERSION  
will be maintained from the main module lib/Workflow.pm

This has already been committed to Subversion, so if you update to  
HEAD, the change should be reflected.

I was a bit to fast on the trigger however and I really want to  
address Robert Stockdale's patch for Workflow::State, but I have not  
gotten any feedback so this might have to wait or I will create a  
branch for releasing 0.32_5 development candidate.

I will however possibly readdress this patch in a mail to the list and  
Jim Brant in particular, since he was the driving for for the  
particular development, prior to taking these actions, since it is a  
one-line patch.

jonasbn

On 10/11/2008, at 22.06, Jonas Brømsø Nielsen wrote:

> Hola,
>
> We have received a RT, what are your thoughts on the subject.
>
> I do prefer module and distribution to live separate lives, but  
> again it makes in pretty impossible to trace back to what  
> distribution the packages come from or?
>
> I am running this by the module-authors mailing list for advice,
>
> jonasbn
>
> Begin forwarded message:
>
> <snip>
>> Date: 10. nov 2008 16.30.03 GMT+01:00
>> To: undisclosed-recipients:;
>> Subject: [rt.cpan.org #40750] Version mismatch between module and  
>> tarball
>> Reply-To: bug...@rt...
>>
>>      Queue: Workflow
>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=40750 >
>>
>> I have already had to argue this point with the author of XML::DTD,  
>> but
>> to rehash, I am rebuilding a bundle for our application since we  
>> changed
>> Perl distributions.   Out of the 70 modules I downloaded, his and  
>> yours
>> is the only ones I had a problem with.
>>
>> When users download workflow, they are not thinking what sub  
>> modules are
>> included with it since they are using 'Workflow' and not
>> 'Workflow::something' most of the time.  So when I looked up the
>> Workflow in our bundle and saw that it was 1.32 I went to download  
>> 1.32
>> and not 0.31.  This is a problem because you now have several  
>> releases
>> of Workflow that are labeled 1.32 with the only way to tell them  
>> apart
>> is to dive into each sub module and look up the versions of them (I
>> shouldn't have to argue how much a pain that is).  There are no  
>> problems
>> keeping different versions of the sub modules in the module, but when
>> you make a change to one of them, you are making a change to  
>> Workflow as
>> a whole, thus its version needs to change to reflect the update.  
>> Now we
>> just happen to be in control of what modules we install, but if we  
>> are
>> on a shared system how are we to know what version of Workflow the  
>> admin
>> has on the box (if even they know)?
>>
>> You make mention that it doesn't make sense due to Workflow's size  
>> and
>> arch, but I'm not buying that.  When you make a release you should be
>> running through a checklist of stuff to do and one of the things on  
>> that
>> list is to make sure your gateway module version and docs reflect the
>> module as a whole.  What versions are internally need to be kept  
>> track
>> with your RCS.  Case in point:
>>
>> CGI
>> Dbi
>> XML::LibXML
>> Wx
>>
>> I wouldn't consider any of them small.  If you don't want to keep  
>> your
>> module version and release verison in sync then you need to update  
>> your
>> documentation to indicate what release version your users are  
>> looking at.
>>
>> Another rehash from my XML::DTD argument.  I forwarded your  
>> response to
>> my 12 coworkers and they agree that the version number to workflow  
>> needs
>> to reflect changes to the module as a whole.
>>
>>
>>
>> On Mon Nov 10 06:26:44 2008, JONASBN wrote:
>>> Please note that the distribution version is not the same as the
>>> Workflow module version number.
>>>
>>> We version these differently so changes to the Workflow module can  
>>> be
>>> identified in the modules version number.
>>>
>>> Some releases of the distribution does however not require changes  
>>> to
>>> the Workflow module, since the distribution consist of a large  
>>> number of
>>> files, so the two numbers indicate different things.
>>>
>>> For smaller distributions it is an idea to have the two numbers  
>>> aligned,
>>> but for Workflow this does not make sense.
>>>
>>> I checked the source back to the initial revision and these  
>>> numbers have
>>> been not been aligned it seems - that the module and distribution  
>>> have
>>> had the same number at some point must be coincidence.
>>>
>>> Separating the two is however the chosen strategy because it makes  
>>> sense
>>> in the case of the Workflow distribution due to it's size and  
>>> architeture.
>>>
>>> jonasbn
>>
>>
>

[Perl-workflow-devel] Fwd: [rt.cpan.org #40750] Version mismatch between module and tarball

[Jonas B. N. <jo...@gm...>]

Hola,

We have received a RT, what are your thoughts on the subject.

I do prefer module and distribution to live separate lives, but again  
it makes in pretty impossible to trace back to what distribution the  
packages come from or?

I am running this by the module-authors mailing list for advice,

jonasbn

Begin forwarded message:

<snip>
> Date: 10. nov 2008 16.30.03 GMT+01:00
> To: undisclosed-recipients:;
> Subject: [rt.cpan.org #40750] Version mismatch between module and  
> tarball
> Reply-To: bug...@rt...
>
>       Queue: Workflow
> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=40750 >
>
> I have already had to argue this point with the author of XML::DTD,  
> but
> to rehash, I am rebuilding a bundle for our application since we  
> changed
> Perl distributions.   Out of the 70 modules I downloaded, his and  
> yours
> is the only ones I had a problem with.
>
> When users download workflow, they are not thinking what sub modules  
> are
> included with it since they are using 'Workflow' and not
> 'Workflow::something' most of the time.  So when I looked up the
> Workflow in our bundle and saw that it was 1.32 I went to download  
> 1.32
> and not 0.31.  This is a problem because you now have several releases
> of Workflow that are labeled 1.32 with the only way to tell them apart
> is to dive into each sub module and look up the versions of them (I
> shouldn't have to argue how much a pain that is).  There are no  
> problems
> keeping different versions of the sub modules in the module, but when
> you make a change to one of them, you are making a change to  
> Workflow as
> a whole, thus its version needs to change to reflect the update. Now  
> we
> just happen to be in control of what modules we install, but if we are
> on a shared system how are we to know what version of Workflow the  
> admin
> has on the box (if even they know)?
>
> You make mention that it doesn't make sense due to Workflow's size and
> arch, but I'm not buying that.  When you make a release you should be
> running through a checklist of stuff to do and one of the things on  
> that
> list is to make sure your gateway module version and docs reflect the
> module as a whole.  What versions are internally need to be kept track
> with your RCS.  Case in point:
>
> CGI
> Dbi
> XML::LibXML
> Wx
>
> I wouldn't consider any of them small.  If you don't want to keep your
> module version and release verison in sync then you need to update  
> your
> documentation to indicate what release version your users are  
> looking at.
>
> Another rehash from my XML::DTD argument.  I forwarded your response  
> to
> my 12 coworkers and they agree that the version number to workflow  
> needs
> to reflect changes to the module as a whole.
>
>
>
> On Mon Nov 10 06:26:44 2008, JONASBN wrote:
>> Please note that the distribution version is not the same as the
>> Workflow module version number.
>>
>> We version these differently so changes to the Workflow module can be
>> identified in the modules version number.
>>
>> Some releases of the distribution does however not require changes to
>> the Workflow module, since the distribution consist of a large  
>> number of
>> files, so the two numbers indicate different things.
>>
>> For smaller distributions it is an idea to have the two numbers  
>> aligned,
>> but for Workflow this does not make sense.
>>
>> I checked the source back to the initial revision and these numbers  
>> have
>> been not been aligned it seems - that the module and distribution  
>> have
>> had the same number at some point must be coincidence.
>>
>> Separating the two is however the chosen strategy because it makes  
>> sense
>> in the case of the Workflow distribution due to it's size and  
>> architeture.
>>
>> jonasbn
>
>

[Perl-workflow-devel] Fwd: [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jonas B. N. <jo...@gm...>]

Hiya Alll,

We have received a patch from Robert Stockdale.

If anybody has time to evaluate it, please feel free.

jonasbn

Begin forwarded message:

> From: "Robert Stockdale via RT" <bug...@rt...>
> Date: 29. sep 2008 21.48.42 GMT+02:00
> To: undisclosed-recipients:;
> Subject: [rt.cpan.org #38024] all conditions with 'test' attirbute  
> appears to be cached as 'evaluate'
> Reply-To: bug...@rt...
>
>       Queue: Workflow
> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38024 >
>
> Hi Jonas,
>
> Sorry for the delay. I was able to confirm this bug.
>
> The name is being explicitly set to 'evaluate' in
> Workflow::State::_create_condition_objects for all conditions that
> specify 'test' as an attribute in the xml configuration. This, coupled
> along with caching of condition results means that only the first
> 'evaluate' condition will actually be evaluated and each subsequent  
> call
> will use the cached result.
>
> Attached is a patch that will resolve the issue. Essentially I am just
> taking the value of the 'test' attribute and naming the condition  
> that,
> with one small exception. Perl seems to have some issue with keys that
> start with '!' so I prefixed it with an underscore. I tested this  
> change
> and it is working in my dev environment.
>
> An alternative option would be to allow the user to specify the 'name'
> attribute in the xml just like with any other condition. I did not
> exercise this option.
>
> -Bob

Re: [Perl-workflow-devel] Setting values in context from config file.

[phil r. <phi...@un...>]

Wahey!

Didn't realise I could do that - thanks.

In case anyone's interested, that means I can have
one SendEmail action and set up lots of different
actions to send different sorts of emails without
adding to my app's already burgeoning config system.

Cheers, Phil

Alexander Klink wrote:
> Hi Phil,
>
> On Thu, Oct 16, 2008 at 03:32:05PM +0100, phil robinson wrote:
>   
>> Both the methods you mention require keeping the
>> actual 'to' address in the app's config though, when
>> the only thing that's actually interested is the workflow;
>> annoying.
>>     
>
> What about putting it into the action config file then? i.e.
> <action name="send_mail"
>         class="Your::Mail::Sender::Actiion"
>         to="fo...@ex..."/>
>
> You can then use it from within your activity as $self->param('to')
> (and put it in the workflow context, if you need it later on in the
> workflow) ...
>
> HTH,
> Cheers,
>   Alex
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
>   


+++++++++++++++++++++++++++++++++++++
phi...@un...
+++++++++++++++++++++++++++++++++++++

Re: [Perl-workflow-devel] Setting values in context from config file.

[Alexander K. <a....@cy...>]

Hi Phil,

On Thu, Oct 16, 2008 at 03:32:05PM +0100, phil robinson wrote:
> Both the methods you mention require keeping the
> actual 'to' address in the app's config though, when
> the only thing that's actually interested is the workflow;
> annoying.

What about putting it into the action config file then? i.e.
<action name="send_mail"
        class="Your::Mail::Sender::Actiion"
        to="fo...@ex..."/>

You can then use it from within your activity as $self->param('to')
(and put it in the workflow context, if you need it later on in the
workflow) ...

HTH,
Cheers,
  Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer |    a....@cy...
 mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
     Bad Homburg v. d. Höhe |                      |      Martin Bartosch

Re: [Perl-workflow-devel] Setting values in context from config file.

[phil r. <phi...@un...>]

Hi Jim. Thanks for your fast response.

I wasn't aware of ExtraData.pm  so thanks for that.

Both the methods you mention require keeping the
actual 'to' address in the app's config though, when
the only thing that's actually interested is the workflow;
annoying. Thanks again, Cheers, Phil

Jim Brandt wrote:
> Phil,
>
> One way to do that is in code as you mentioned, probably near the code 
> where you create/load your workflow instance.
>
> You could also use the ExtraData feature, or some variation of it:
>
> http://search.cpan.org/~jonasbn/Workflow-0.31/lib/Workflow/Persister/DBI/ExtraData.pm 
>
>
> This module will pull in the data from your supporting table and load 
> it into the context automatically.
>
> The down side is it will be set in a record for each workflow 
> instance, but this could also be an advantage if you every wanted to 
> have different 'to' addresses for different instances. And you would 
> still need code somewhere to initially set this value when you create 
> the workflow.
>
> Jim  
<snip>

+++++++++++++++++++++++++++++++++++++
phi...@un...
+++++++++++++++++++++++++++++++++++++

Re: [Perl-workflow-devel] Setting values in context from config file.

[Jim B. <cb...@bu...>]

Phil,

One way to do that is in code as you mentioned, probably near the code 
where you create/load your workflow instance.

You could also use the ExtraData feature, or some variation of it:

http://search.cpan.org/~jonasbn/Workflow-0.31/lib/Workflow/Persister/DBI/ExtraData.pm

This module will pull in the data from your supporting table and load it 
into the context automatically.

The down side is it will be set in a record for each workflow instance, 
but this could also be an advantage if you every wanted to have 
different 'to' addresses for different instances. And you would still 
need code somewhere to initially set this value when you create the 
workflow.

Jim


phil robinson wrote:
> I just started using perl workflow and so far its
> great (thanks) but I have a feeling I'm missing something:
> 
> I want to set a context param value from within
> workflow.xml; is this possible, or is it a stupid idea
> for some reason I haven't yet realised?
> 
> Say I have an action called SendEmail which looks
> for context->{to} for the 'to' address.
> 
> Is there some way I can set context->{to} from the
> workflow.xml or actions.xml config file?  If not, I'll
> have to add an entry to the apps _own_ xml config file,
> then set it via code, which seems unnecessarily roundabout.
> TIA, Phil Robinson
> 
> 
> 
> 
> 
> +++++++++++++++++++++++++++++++++++++
> phi...@un...
> Tel: +44 (0)161 257 3532
> +++++++++++++++++++++++++++++++++++++
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

[Perl-workflow-devel] Setting values in context from config file.

[phil r. <phi...@un...>]

I just started using perl workflow and so far its
great (thanks) but I have a feeling I'm missing something:

I want to set a context param value from within
workflow.xml; is this possible, or is it a stupid idea
for some reason I haven't yet realised?

Say I have an action called SendEmail which looks
for context->{to} for the 'to' address.

Is there some way I can set context->{to} from the
workflow.xml or actions.xml config file?  If not, I'll
have to add an entry to the apps _own_ xml config file,
then set it via code, which seems unnecessarily roundabout.
TIA, Phil Robinson





+++++++++++++++++++++++++++++++++++++
phi...@un...
Tel: +44 (0)161 257 3532
+++++++++++++++++++++++++++++++++++++

Re: [Perl-workflow-devel] RT #5943

[Jonas B. N. <jo...@gm...>]

Hi Grant,

After much thinking and examination I have come to the conclusion that  
XML::SAX::ParserFactory has an issue.

The following:

         if (@{$self->{KnownParsers}}) {
                 return $self->{KnownParsers}[-1]{Name};
         }
         else {
                 return "XML::SAX::PurePerl"; # backup plan!
         }

Yields unpredictable behavior based on installation order of parsers.

I would suggest addressing this and documenting how to control parser  
load.

I would rewrite it to:

         if (@{$self->{KnownParsers}}) {
                 return $self->{KnownParsers}[-1]{Name};
         }
         else {
                 return "XML::SAX::PurePerl"; # backup plan!
         }

But this breaks existing installtions and require people to revisit  
their: XML/SAX/ParserDetails.ini files.

Perhaps the best solution would be to look into the feature system,  
but this will require multiple patches to a lot of distributions in  
order to get properly propagated - and I currently do not have the  
knowledge on XML::SAX/XML::Simple to conclude that it can be  
controlled that way.

Ref: http://use.perl.org/~jonasbn/journal/37344

jonasbn

Ps. I have Cc'ed the Workflow development list to keep my fellow  
developers on workflow aware of my progress, you probably cannot post  
to the list, but I will see to that a possible response from you gets  
relayed.

On 20/08/2008, at 11.59, Grant McLean wrote:

> Hi Jonas
>
> The only thing that's holding this up is lack of time.  I will get  
> to it
> but I have more important problems to deal with first.  If you want to
> get co-maintainership of XML::SAX::RTF and do a release then go right
> ahead.
>
> Cheers
> Grant
>
> On Wed, 2008-08-20 at 09:07 +0200, Jonas Brømsø Nielsen wrote:
>> Hello Grant,
>>
>> I have been chasing this bug:
>>
>> http://www.perlmonks.org/?node_id=512040
>>
>> And I ended up at this ticket:
>>
>> http://rt.cpan.org/Ticket/Display.html?id=5943
>>
>> How are things doing with this, do you need assistance, help, test,
>> patches??
>>
>> Looking forward to hearing from you,
>>
>> jonasbn
>>
>>
>> --
>> pauseid: JONASBN
>> email: jo...@cp...
>> blog: http://use.perl.org/~jonasbn/journal/
>>
>>
>

Re: [Perl-workflow-devel] 0.32_4 tests, not good :-/

[Jonas B. N. <jo...@gm...>]

Hi Alexander,

Neither do I, but it would be the least effort to avoid the problem.

Andreas Koenig sents us all the failing reports, I have wrote him and  
inquired about the contents of his:

XML/SAX/ParserDetails.ini

These are the reports:

	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2054957.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2054972.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2054967.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2054982.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2054996.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2055008.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2055019.html
	http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2055033.html

I have mailed Grant to hear if there was anything I could do in  
conjunction with the bug.

Alternatively we could write a test, which checks if the XML::Simple  
parser works and if not it complaints and ask the user to look at:

	XML/SAX/ParserDetails.ini

I do however think we will keep getting these automated test reports  
from CPAN testers as long as XML::SAX::RDF is not patched and updated.  
And does this even fix the problem in: XML/SAX/ParserDetails.ini, we  
do not know.

Lets see what we here from Grant and Andreas, based on that we can  
decide on what route to take,

jonasbn

On 20/08/2008, at 09.43, Alexander Klink wrote:

> Hi Jonas,
>
> On Wed, Aug 20, 2008 at 09:03:21AM +0200, Jonas Brms Nielsen wrote:
>> I will write Grant and ask how things are going with this and
>> hopefully we can get it out of the way by introducing a requirement
>> for XML::SAX::RTF (patched version) even though we do not use it.
>
> Hmmm, I don't particularly like this solution, I must say - requiring
> something that we don't need just so that our tests run correct in
> certain settings is IMHO a bit overkill ...
>
> Cheers,
>  Alex
> -- 
> Dipl.-Math. Alexander Klink | IT-Security Engineer |    a....@cy...
> mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
> ----------------------------+---------------------- 
> +---------------------
>      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |      
> Geschäftsführer:
>     Bad Homburg v. d. Höhe |                      |      Martin  
> Bartosch

Re: [Perl-workflow-devel] 0.32_4 tests, not good :-/

[Alexander K. <a....@cy...>]

Hi Jonas,

On Wed, Aug 20, 2008 at 09:03:21AM +0200, Jonas Brms Nielsen wrote:
> I will write Grant and ask how things are going with this and  
> hopefully we can get it out of the way by introducing a requirement  
> for XML::SAX::RTF (patched version) even though we do not use it.

Hmmm, I don't particularly like this solution, I must say - requiring
something that we don't need just so that our tests run correct in
certain settings is IMHO a bit overkill ...

Cheers,
  Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer |    a....@cy...
 mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
     Bad Homburg v. d. Höhe |                      |      Martin Bartosch

Re: [Perl-workflow-devel] 0.32_4 tests, not good :-/

[Jonas B. N. <jo...@gm...>]

Oh,

I forgot the source for the comment,

http://www.nntp.perl.org/group/perl.cpan.testers/131214

jonasbn

On 20/08/2008, at 09.03, Jonas Brømsø Nielsen wrote:

> Ok,
>
> I did some googling and I found a link to perlmonks:
>
> http://www.perlmonks.org/?node_id=512040
>
> Here is the explanation, taken from ():
>
> #######
> The problem in this case is a bug in the XML::SAX::RTF installer,
> which registers itself in ...lib.../XML/SAX/ParserDetails.ini.
> This ini file is used to determine the default SAX parser and
> since XML::SAX::RTF was installed most recently, it is the default.
> Unfortunately, XML::SAX::RTF is not an XML parser (despite
> generating SAX events) so it should be removed from the
> ParserDetails.ini file.
>
> I have reported this problem to the module maintainer some time
> ago, but I will try again and submit a patch this time.
>
> Thanks for the test.
> Grant
> #######
>
> So the problem could be with XML::SAX::RTF
> http://rt.cpan.org/Ticket/Display.html?id=5943
>
> I will write Grant and ask how things are going with this and  
> hopefully we can get it out of the way by introducing a requirement  
> for XML::SAX::RTF (patched version) even though we do not use it.
>
> jonasbn
>
> On 20/08/2008, at 08.30, Jonas Brømsø Nielsen wrote:
>
>> Hello all,
>>
>> Apparently we have some more issues, the colour report is not  
>> available yet, but from the mails and RSS I can see that we have  
>> some issues.
>>
>> The report will be here at some point:
>>
>> http://cpantesters.perl.org/show/Workflow.html#Workflow-0.32_4
>>
>> The mails can be seen online, but I have added an excerpt from one  
>> below.
>>
>> I think this is XML parser related, ideas and suggestions are  
>> welcome, I will start to dig into this shortly.
>>
>> jonasbn
>> --
>>
>> Output from '/usr/bin/make test':
>>
>> PERL_DL_NONLAZY=1 /home/src/perl/repoperls/installed-perls/ 
>> maint-5.10/pjgo6vl/perl-5.10.0@33955/bin/perl "- 
>> MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/ 
>> arch')" t/*.t
>> t/00_load..........................Log4perl: Seems like no  
>> initialization happened. Forgot to call init()?
>> ok
>> t/02_pod...........................skipped: set TEST_POD to enable  
>> this test
>> t/03_pod-coverage..................skipped: set TEST_POD to enable  
>> this test
>> t/action...........................ok
>> t/action_field.....................ok
>> t/action_mailer....................ok
>> t/action_null......................ok
>> t/base.............................ok
>> t/cached_conditions................Processing  
>> workflow_cached_condition_condition.xml: No _parse_* routine  
>> defined on this driver (If it is a filter, remember to set the  
>> Parent property. If you call the parse() method, make sure to set a  
>> Source. You may want to call parse_uri, parse_string or parse_file  
>> instead.) [XML::LibXML::SAX::ChunkParser=HASH(0x87a1b74)] at /home/ 
>> src/perl/repoperls/installed-perls/maint-5.10/pjgo6vl/ 
>> perl-5.10.0@33955/lib/site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like your test died before it could output anything.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 3/3 subtests
>> t/condition........................Processing  
>> workflow_condition.xml: No _parse_* routine defined on this driver  
>> (If it is a filter, remember to set the Parent property. If you  
>> call the parse() method, make sure to set a Source. You may want to  
>> call parse_uri, parse_string or parse_file instead.)  
>> [XML::LibXML::SAX::ChunkParser=HASH(0x87b2f60)] at /home/src/perl/ 
>> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
>> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you planned 11 tests but only ran 3.
>> # Looks like your test died just after 3.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 8/11 subtests
>> t/condition_evaluate...............ok
>> t/config...........................Processing workflow_action.xml:  
>> No _parse_* routine defined on this driver (If it is a filter,  
>> remember to set the Parent property. If you call the parse()  
>> method, make sure to set a Source. You may want to call parse_uri,  
>> parse_string or parse_file instead.)  
>> [XML::LibXML::SAX::ChunkParser=HASH(0x86dcdbc)] at /home/src/perl/ 
>> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
>> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you planned 47 tests but only ran 6.
>> # Looks like your test died just after 6.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 41/47 subtests
>> t/context..........................ok
>> t/exception........................ok
>> t/factory..........................
>> #   Failed test at t/factory.t line 30.
>> # died: Processing workflow_condition.xml: No _parse_* routine  
>> defined on this driver (If it is a filter, remember to set the  
>> Parent property. If you call the parse() method, make sure to set a  
>> Source. You may want to call parse_uri, parse_string or parse_file  
>> instead.) [XML::LibXML::SAX::ChunkParser=HASH(0x87b7ce0)] at /home/ 
>> src/perl/repoperls/installed-perls/maint-5.10/pjgo6vl/ 
>> perl-5.10.0@33955/lib/site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>>
>> #   Failed test at t/factory.t line 35.
>> # died: Processing workflow_condition.xml: No _parse_* routine  
>> defined on this driver (If it is a filter, remember to set the  
>> Parent property. If you call the parse() method, make sure to set a  
>> Source. You may want to call parse_uri, parse_string or parse_file  
>> instead.) [XML::LibXML::SAX::ChunkParser=HASH(0x87b7d80)] at /home/ 
>> src/perl/repoperls/installed-perls/maint-5.10/pjgo6vl/ 
>> perl-5.10.0@33955/lib/site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you failed 2 tests of 7.
>> Dubious, test returned 2 (wstat 512, 0x200)
>> Failed 2/7 subtests
>> t/factory_subclass.................ok
>> t/history..........................ok
>> t/persister........................ok
>> t/persister_dbi....................Processing  
>> workflow_condition.xml: No _parse_* routine defined on this driver  
>> (If it is a filter, remember to set the Parent property. If you  
>> call the parse() method, make sure to set a Source. You may want to  
>> call parse_uri, parse_string or parse_file instead.)  
>> [XML::LibXML::SAX::ChunkParser=HASH(0x88fecf4)] at /home/src/perl/ 
>> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
>> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you planned 43 tests but only ran 1.
>> # Looks like your test died just after 1.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 42/43 subtests
>> t/persister_dbi_extra_data.........ok
>> t/persister_dbi_sqlite.............Cannot read '/home/sand/.cpan/ 
>> build/Workflow-0.32_4-GPzZCN/t/struct/workflow_sqlite.sql': Datei  
>> oder Verzeichnis nicht gefunden at TestDBUtil.pm line 93.
>> Dubious, test returned 2 (wstat 512, 0x200)
>> No subtests run
>> t/persister_file...................Processing  
>> workflow_condition.xml: No _parse_* routine defined on this driver  
>> (If it is a filter, remember to set the Parent property. If you  
>> call the parse() method, make sure to set a Source. You may want to  
>> call parse_uri, parse_string or parse_file instead.)  
>> [XML::LibXML::SAX::ChunkParser=HASH(0x87e097c)] at /home/src/perl/ 
>> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
>> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you planned 19 tests but only ran 1.
>> # Looks like your test died just after 1.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 18/19 subtests
>> t/persister_random_id..............ok
>> t/persister_spops..................skipped: SPOPS not installed
>> t/persister_uuid...................ok
>> t/state............................Processing  
>> workflow_condition.xml: No _parse_* routine defined on this driver  
>> (If it is a filter, remember to set the Parent property. If you  
>> call the parse() method, make sure to set a Source. You may want to  
>> call parse_uri, parse_string or parse_file instead.)  
>> [XML::LibXML::SAX::ChunkParser=HASH(0x879ec68)] at /home/src/perl/ 
>> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
>> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you planned 19 tests but only ran 1.
>> # Looks like your test died just after 1.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 18/19 subtests
>> t/state_perl.......................# Running with perl config.
>> ok
>> t/validator........................ok
>> t/validator_has_required_field.....ok
>> t/validator_in_enumerated_type.....Use of uninitialized value in  
>> concatenation (.) or string at /home/sand/.cpan/build/ 
>> Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm line 19.
>> Use of uninitialized value in concatenation (.) or string at /home/ 
>> sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/ 
>> Validator.pm line 19.
>> Use of uninitialized value in concatenation (.) or string at /home/ 
>> sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/ 
>> Validator.pm line 19.
>> ok
>> t/validator_matches_date_format....Use of uninitialized value in  
>> concatenation (.) or string at /home/sand/.cpan/build/ 
>> Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm line 19.
>> Use of uninitialized value in concatenation (.) or string at /home/ 
>> sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/ 
>> Validator.pm line 19.
>> ok
>> t/workflow.........................Processing  
>> workflow_condition.xml: No _parse_* routine defined on this driver  
>> (If it is a filter, remember to set the Parent property. If you  
>> call the parse() method, make sure to set a Source. You may want to  
>> call parse_uri, parse_string or parse_file instead.)  
>> [XML::LibXML::SAX::ChunkParser=HASH(0x883a1d8)] at /home/src/perl/ 
>> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
>> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>> # Looks like you planned 35 tests but only ran 1.
>> # Looks like your test died just after 1.
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 34/35 subtests
>>
>> Test Summary Report
>> -------------------
>> t/cached_conditions            (Wstat: 65280 Tests: 0 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 3 tests but ran 0.
>> t/condition                    (Wstat: 65280 Tests: 3 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 11 tests but ran 3.
>> t/config                       (Wstat: 65280 Tests: 6 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 47 tests but ran 6.
>> t/factory                      (Wstat: 512 Tests: 7 Failed: 2)
>> Failed tests:  6-7
>> Non-zero exit status: 2
>> t/persister_dbi                (Wstat: 65280 Tests: 1 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 43 tests but ran 1.
>> t/persister_dbi_sqlite         (Wstat: 512 Tests: 0 Failed: 0)
>> Non-zero exit status: 2
>> Parse errors: No plan found in TAP output
>> t/persister_file               (Wstat: 65280 Tests: 1 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 19 tests but ran 1.
>> t/state                        (Wstat: 65280 Tests: 1 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 19 tests but ran 1.
>> t/workflow                     (Wstat: 65280 Tests: 1 Failed: 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan.  You planned 35 tests but ran 1.
>> Files=32, Tests=191, 19 wallclock secs ( 0.24 usr  0.05 sys + 14.34  
>> cusr  1.40 csys = 16.03 CPU)
>> Result: FAIL
>> Failed 9/32 test programs. 2/191 subtests failed.
>> make: *** [test_dynamic] Fehler 255
>>
>> ------------------------------
>> PREREQUISITES
>> ------------------------------
>>
>> Prerequisite modules loaded:
>>
>> requires:
>>
>>   Module                     Need Have
>>   -------------------------- ---- --------
>>   Class::Accessor            0.18 0.31
>>   Class::Factory             1    1.06
>>   Class::Observable          1.04 1.04
>>   Data::Dumper               0    2.121_14
>>   DateTime                   0.15 0.4304
>>   DateTime::Format::Strptime 1    1.0800
>>   DBD::Mock                  0.1  1.37
>>   DBI                        0    1.607
>>   Exception::Class           1.1  1.24
>>   List::MoreUtils            0    0.22
>>   Log::Dispatch              2    2.21
>>   Log::Log4perl              0.34 1.17
>>   Safe                       0    2.16
>>   Test::Exception            0    0.27
>>   Test::More                 0.41 0.80
>>   XML::Simple                2    2.18
>>
>>
>>
>>
>> --
>> pauseid: JONASBN
>> email: jo...@cp...
>> blog: http://use.perl.org/~jonasbn/journal/
>>
>>
>



--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

Re: [Perl-workflow-devel] 0.32_4 tests, not good :-/

[Jonas B. N. <jo...@gm...>]

Ok,

I did some googling and I found a link to perlmonks:

http://www.perlmonks.org/?node_id=512040

Here is the explanation, taken from ():

#######
The problem in this case is a bug in the XML::SAX::RTF installer,
which registers itself in ...lib.../XML/SAX/ParserDetails.ini.
This ini file is used to determine the default SAX parser and
since XML::SAX::RTF was installed most recently, it is the default.
Unfortunately, XML::SAX::RTF is not an XML parser (despite
generating SAX events) so it should be removed from the
ParserDetails.ini file.

I have reported this problem to the module maintainer some time
ago, but I will try again and submit a patch this time.

Thanks for the test.
Grant
#######

So the problem could be with XML::SAX::RTF
http://rt.cpan.org/Ticket/Display.html?id=5943

I will write Grant and ask how things are going with this and  
hopefully we can get it out of the way by introducing a requirement  
for XML::SAX::RTF (patched version) even though we do not use it.

jonasbn

On 20/08/2008, at 08.30, Jonas Brømsø Nielsen wrote:

> Hello all,
>
> Apparently we have some more issues, the colour report is not  
> available yet, but from the mails and RSS I can see that we have  
> some issues.
>
> The report will be here at some point:
>
> http://cpantesters.perl.org/show/Workflow.html#Workflow-0.32_4
>
> The mails can be seen online, but I have added an excerpt from one  
> below.
>
> I think this is XML parser related, ideas and suggestions are  
> welcome, I will start to dig into this shortly.
>
> jonasbn
> --
>
> Output from '/usr/bin/make test':
>
> PERL_DL_NONLAZY=1 /home/src/perl/repoperls/installed-perls/ 
> maint-5.10/pjgo6vl/perl-5.10.0@33955/bin/perl "- 
> MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/ 
> arch')" t/*.t
> t/00_load..........................Log4perl: Seems like no  
> initialization happened. Forgot to call init()?
> ok
> t/02_pod...........................skipped: set TEST_POD to enable  
> this test
> t/03_pod-coverage..................skipped: set TEST_POD to enable  
> this test
> t/action...........................ok
> t/action_field.....................ok
> t/action_mailer....................ok
> t/action_null......................ok
> t/base.............................ok
> t/cached_conditions................Processing  
> workflow_cached_condition_condition.xml: No _parse_* routine defined  
> on this driver (If it is a filter, remember to set the Parent  
> property. If you call the parse() method, make sure to set a Source.  
> You may want to call parse_uri, parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x87a1b74)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like your test died before it could output anything.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 3/3 subtests
> t/condition........................Processing  
> workflow_condition.xml: No _parse_* routine defined on this driver  
> (If it is a filter, remember to set the Parent property. If you call  
> the parse() method, make sure to set a Source. You may want to call  
> parse_uri, parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x87b2f60)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you planned 11 tests but only ran 3.
> # Looks like your test died just after 3.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 8/11 subtests
> t/condition_evaluate...............ok
> t/config...........................Processing workflow_action.xml:  
> No _parse_* routine defined on this driver (If it is a filter,  
> remember to set the Parent property. If you call the parse() method,  
> make sure to set a Source. You may want to call parse_uri,  
> parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x86dcdbc)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you planned 47 tests but only ran 6.
> # Looks like your test died just after 6.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 41/47 subtests
> t/context..........................ok
> t/exception........................ok
> t/factory..........................
> #   Failed test at t/factory.t line 30.
> # died: Processing workflow_condition.xml: No _parse_* routine  
> defined on this driver (If it is a filter, remember to set the  
> Parent property. If you call the parse() method, make sure to set a  
> Source. You may want to call parse_uri, parse_string or parse_file  
> instead.) [XML::LibXML::SAX::ChunkParser=HASH(0x87b7ce0)] at /home/ 
> src/perl/repoperls/installed-perls/maint-5.10/pjgo6vl/ 
> perl-5.10.0@33955/lib/site_perl/5.10.0/XML/SAX/Base.pm line 2616.
>
> #   Failed test at t/factory.t line 35.
> # died: Processing workflow_condition.xml: No _parse_* routine  
> defined on this driver (If it is a filter, remember to set the  
> Parent property. If you call the parse() method, make sure to set a  
> Source. You may want to call parse_uri, parse_string or parse_file  
> instead.) [XML::LibXML::SAX::ChunkParser=HASH(0x87b7d80)] at /home/ 
> src/perl/repoperls/installed-perls/maint-5.10/pjgo6vl/ 
> perl-5.10.0@33955/lib/site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you failed 2 tests of 7.
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/7 subtests
> t/factory_subclass.................ok
> t/history..........................ok
> t/persister........................ok
> t/persister_dbi....................Processing  
> workflow_condition.xml: No _parse_* routine defined on this driver  
> (If it is a filter, remember to set the Parent property. If you call  
> the parse() method, make sure to set a Source. You may want to call  
> parse_uri, parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x88fecf4)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you planned 43 tests but only ran 1.
> # Looks like your test died just after 1.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 42/43 subtests
> t/persister_dbi_extra_data.........ok
> t/persister_dbi_sqlite.............Cannot read '/home/sand/.cpan/ 
> build/Workflow-0.32_4-GPzZCN/t/struct/workflow_sqlite.sql': Datei  
> oder Verzeichnis nicht gefunden at TestDBUtil.pm line 93.
> Dubious, test returned 2 (wstat 512, 0x200)
> No subtests run
> t/persister_file...................Processing  
> workflow_condition.xml: No _parse_* routine defined on this driver  
> (If it is a filter, remember to set the Parent property. If you call  
> the parse() method, make sure to set a Source. You may want to call  
> parse_uri, parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x87e097c)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you planned 19 tests but only ran 1.
> # Looks like your test died just after 1.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 18/19 subtests
> t/persister_random_id..............ok
> t/persister_spops..................skipped: SPOPS not installed
> t/persister_uuid...................ok
> t/state............................Processing  
> workflow_condition.xml: No _parse_* routine defined on this driver  
> (If it is a filter, remember to set the Parent property. If you call  
> the parse() method, make sure to set a Source. You may want to call  
> parse_uri, parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x879ec68)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you planned 19 tests but only ran 1.
> # Looks like your test died just after 1.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 18/19 subtests
> t/state_perl.......................# Running with perl config.
> ok
> t/validator........................ok
> t/validator_has_required_field.....ok
> t/validator_in_enumerated_type.....Use of uninitialized value in  
> concatenation (.) or string at /home/sand/.cpan/build/ 
> Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm line 19.
> Use of uninitialized value in concatenation (.) or string at /home/ 
> sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/ 
> Validator.pm line 19.
> Use of uninitialized value in concatenation (.) or string at /home/ 
> sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/ 
> Validator.pm line 19.
> ok
> t/validator_matches_date_format....Use of uninitialized value in  
> concatenation (.) or string at /home/sand/.cpan/build/ 
> Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm line 19.
> Use of uninitialized value in concatenation (.) or string at /home/ 
> sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/ 
> Validator.pm line 19.
> ok
> t/workflow.........................Processing  
> workflow_condition.xml: No _parse_* routine defined on this driver  
> (If it is a filter, remember to set the Parent property. If you call  
> the parse() method, make sure to set a Source. You may want to call  
> parse_uri, parse_string or parse_file instead.)  
> [XML::LibXML::SAX::ChunkParser=HASH(0x883a1d8)] at /home/src/perl/ 
> repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
> site_perl/5.10.0/XML/SAX/Base.pm line 2616.
> # Looks like you planned 35 tests but only ran 1.
> # Looks like your test died just after 1.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 34/35 subtests
>
> Test Summary Report
> -------------------
> t/cached_conditions            (Wstat: 65280 Tests: 0 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 3 tests but ran 0.
> t/condition                    (Wstat: 65280 Tests: 3 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 11 tests but ran 3.
> t/config                       (Wstat: 65280 Tests: 6 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 47 tests but ran 6.
> t/factory                      (Wstat: 512 Tests: 7 Failed: 2)
>  Failed tests:  6-7
>  Non-zero exit status: 2
> t/persister_dbi                (Wstat: 65280 Tests: 1 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 43 tests but ran 1.
> t/persister_dbi_sqlite         (Wstat: 512 Tests: 0 Failed: 0)
>  Non-zero exit status: 2
>  Parse errors: No plan found in TAP output
> t/persister_file               (Wstat: 65280 Tests: 1 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 19 tests but ran 1.
> t/state                        (Wstat: 65280 Tests: 1 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 19 tests but ran 1.
> t/workflow                     (Wstat: 65280 Tests: 1 Failed: 0)
>  Non-zero exit status: 255
>  Parse errors: Bad plan.  You planned 35 tests but ran 1.
> Files=32, Tests=191, 19 wallclock secs ( 0.24 usr  0.05 sys + 14.34  
> cusr  1.40 csys = 16.03 CPU)
> Result: FAIL
> Failed 9/32 test programs. 2/191 subtests failed.
> make: *** [test_dynamic] Fehler 255
>
> ------------------------------
> PREREQUISITES
> ------------------------------
>
> Prerequisite modules loaded:
>
> requires:
>
>    Module                     Need Have
>    -------------------------- ---- --------
>    Class::Accessor            0.18 0.31
>    Class::Factory             1    1.06
>    Class::Observable          1.04 1.04
>    Data::Dumper               0    2.121_14
>    DateTime                   0.15 0.4304
>    DateTime::Format::Strptime 1    1.0800
>    DBD::Mock                  0.1  1.37
>    DBI                        0    1.607
>    Exception::Class           1.1  1.24
>    List::MoreUtils            0    0.22
>    Log::Dispatch              2    2.21
>    Log::Log4perl              0.34 1.17
>    Safe                       0    2.16
>    Test::Exception            0    0.27
>    Test::More                 0.41 0.80
>    XML::Simple                2    2.18
>
>
>
>
> --
> pauseid: JONASBN
> email: jo...@cp...
> blog: http://use.perl.org/~jonasbn/journal/
>
>

[Perl-workflow-devel] 0.32_4 tests, not good :-/

[Jonas B. N. <jo...@gm...>]

Hello all,

Apparently we have some more issues, the colour report is not  
available yet, but from the mails and RSS I can see that we have some  
issues.

The report will be here at some point:

http://cpantesters.perl.org/show/Workflow.html#Workflow-0.32_4

The mails can be seen online, but I have added an excerpt from one  
below.

I think this is XML parser related, ideas and suggestions are welcome,  
I will start to dig into this shortly.

jonasbn
--

Output from '/usr/bin/make test':

PERL_DL_NONLAZY=1 /home/src/perl/repoperls/installed-perls/maint-5.10/ 
pjgo6vl/perl-5.10.0@33955/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00_load..........................Log4perl: Seems like no  
initialization happened. Forgot to call init()?
ok
t/02_pod...........................skipped: set TEST_POD to enable  
this test
t/03_pod-coverage..................skipped: set TEST_POD to enable  
this test
t/action...........................ok
t/action_field.....................ok
t/action_mailer....................ok
t/action_null......................ok
t/base.............................ok
t/cached_conditions................Processing  
workflow_cached_condition_condition.xml: No _parse_* routine defined  
on this driver (If it is a filter, remember to set the Parent  
property. If you call the parse() method, make sure to set a Source.  
You may want to call parse_uri, parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x87a1b74)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like your test died before it could output anything.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 3/3 subtests
t/condition........................Processing workflow_condition.xml:  
No _parse_* routine defined on this driver (If it is a filter,  
remember to set the Parent property. If you call the parse() method,  
make sure to set a Source. You may want to call parse_uri,  
parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x87b2f60)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you planned 11 tests but only ran 3.
# Looks like your test died just after 3.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 8/11 subtests
t/condition_evaluate...............ok
t/config...........................Processing workflow_action.xml: No  
_parse_* routine defined on this driver (If it is a filter, remember  
to set the Parent property. If you call the parse() method, make sure  
to set a Source. You may want to call parse_uri, parse_string or  
parse_file instead.) [XML::LibXML::SAX::ChunkParser=HASH(0x86dcdbc)]  
at /home/src/perl/repoperls/installed-perls/maint-5.10/pjgo6vl/ 
perl-5.10.0@33955/lib/site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you planned 47 tests but only ran 6.
# Looks like your test died just after 6.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 41/47 subtests
t/context..........................ok
t/exception........................ok
t/factory..........................
#   Failed test at t/factory.t line 30.
# died: Processing workflow_condition.xml: No _parse_* routine defined  
on this driver (If it is a filter, remember to set the Parent  
property. If you call the parse() method, make sure to set a Source.  
You may want to call parse_uri, parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x87b7ce0)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.

#   Failed test at t/factory.t line 35.
# died: Processing workflow_condition.xml: No _parse_* routine defined  
on this driver (If it is a filter, remember to set the Parent  
property. If you call the parse() method, make sure to set a Source.  
You may want to call parse_uri, parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x87b7d80)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you failed 2 tests of 7.
  Dubious, test returned 2 (wstat 512, 0x200)
  Failed 2/7 subtests
t/factory_subclass.................ok
t/history..........................ok
t/persister........................ok
t/persister_dbi....................Processing workflow_condition.xml:  
No _parse_* routine defined on this driver (If it is a filter,  
remember to set the Parent property. If you call the parse() method,  
make sure to set a Source. You may want to call parse_uri,  
parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x88fecf4)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you planned 43 tests but only ran 1.
# Looks like your test died just after 1.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 42/43 subtests
t/persister_dbi_extra_data.........ok
t/persister_dbi_sqlite.............Cannot read '/home/sand/.cpan/build/ 
Workflow-0.32_4-GPzZCN/t/struct/workflow_sqlite.sql': Datei oder  
Verzeichnis nicht gefunden at TestDBUtil.pm line 93.
  Dubious, test returned 2 (wstat 512, 0x200)
  No subtests run
t/persister_file...................Processing workflow_condition.xml:  
No _parse_* routine defined on this driver (If it is a filter,  
remember to set the Parent property. If you call the parse() method,  
make sure to set a Source. You may want to call parse_uri,  
parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x87e097c)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you planned 19 tests but only ran 1.
# Looks like your test died just after 1.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 18/19 subtests
t/persister_random_id..............ok
t/persister_spops..................skipped: SPOPS not installed
t/persister_uuid...................ok
t/state............................Processing workflow_condition.xml:  
No _parse_* routine defined on this driver (If it is a filter,  
remember to set the Parent property. If you call the parse() method,  
make sure to set a Source. You may want to call parse_uri,  
parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x879ec68)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you planned 19 tests but only ran 1.
# Looks like your test died just after 1.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 18/19 subtests
t/state_perl.......................# Running with perl config.
ok
t/validator........................ok
t/validator_has_required_field.....ok
t/validator_in_enumerated_type.....Use of uninitialized value in  
concatenation (.) or string at /home/sand/.cpan/build/Workflow-0.32_4- 
GPzZCN/blib/lib/Workflow/Validator.pm line 19.
Use of uninitialized value in concatenation (.) or string at /home/ 
sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm  
line 19.
Use of uninitialized value in concatenation (.) or string at /home/ 
sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm  
line 19.
ok
t/validator_matches_date_format....Use of uninitialized value in  
concatenation (.) or string at /home/sand/.cpan/build/Workflow-0.32_4- 
GPzZCN/blib/lib/Workflow/Validator.pm line 19.
Use of uninitialized value in concatenation (.) or string at /home/ 
sand/.cpan/build/Workflow-0.32_4-GPzZCN/blib/lib/Workflow/Validator.pm  
line 19.
ok
t/workflow.........................Processing workflow_condition.xml:  
No _parse_* routine defined on this driver (If it is a filter,  
remember to set the Parent property. If you call the parse() method,  
make sure to set a Source. You may want to call parse_uri,  
parse_string or parse_file instead.)  
[XML::LibXML::SAX::ChunkParser=HASH(0x883a1d8)] at /home/src/perl/ 
repoperls/installed-perls/maint-5.10/pjgo6vl/perl-5.10.0@33955/lib/ 
site_perl/5.10.0/XML/SAX/Base.pm line 2616.
# Looks like you planned 35 tests but only ran 1.
# Looks like your test died just after 1.
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 34/35 subtests

Test Summary Report
-------------------
t/cached_conditions            (Wstat: 65280 Tests: 0 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 3 tests but ran 0.
t/condition                    (Wstat: 65280 Tests: 3 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 11 tests but ran 3.
t/config                       (Wstat: 65280 Tests: 6 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 47 tests but ran 6.
t/factory                      (Wstat: 512 Tests: 7 Failed: 2)
   Failed tests:  6-7
   Non-zero exit status: 2
t/persister_dbi                (Wstat: 65280 Tests: 1 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 43 tests but ran 1.
t/persister_dbi_sqlite         (Wstat: 512 Tests: 0 Failed: 0)
   Non-zero exit status: 2
   Parse errors: No plan found in TAP output
t/persister_file               (Wstat: 65280 Tests: 1 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 19 tests but ran 1.
t/state                        (Wstat: 65280 Tests: 1 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 19 tests but ran 1.
t/workflow                     (Wstat: 65280 Tests: 1 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 35 tests but ran 1.
Files=32, Tests=191, 19 wallclock secs ( 0.24 usr  0.05 sys + 14.34  
cusr  1.40 csys = 16.03 CPU)
Result: FAIL
Failed 9/32 test programs. 2/191 subtests failed.
make: *** [test_dynamic] Fehler 255

------------------------------
PREREQUISITES
------------------------------

Prerequisite modules loaded:

requires:

     Module                     Need Have
     -------------------------- ---- --------
     Class::Accessor            0.18 0.31
     Class::Factory             1    1.06
     Class::Observable          1.04 1.04
     Data::Dumper               0    2.121_14
     DateTime                   0.15 0.4304
     DateTime::Format::Strptime 1    1.0800
     DBD::Mock                  0.1  1.37
     DBI                        0    1.607
     Exception::Class           1.1  1.24
     List::MoreUtils            0    0.22
     Log::Dispatch              2    2.21
     Log::Log4perl              0.34 1.17
     Safe                       0    2.16
     Test::Exception            0    0.27
     Test::More                 0.41 0.80
     XML::Simple                2    2.18




--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

[Perl-workflow-devel] Release 0.32_4, on it's way to CPAN

[Jonas B. N. <jo...@gm...>]

Evening all,

I have just uploaded release 0.32_4 addressing numerous failing tests,  
the fix was trivial.

http://cpantesters.perl.org/show/Workflow.html#Workflow-0.32_3

Good thing we have CPAN testers to help us out.

I hope 0.32_4 will be more in the green so we can focus on the  
reported problem (see earlier mail and/or http//rt.cpan.org/).

I have just concluded the YAPC::Europe 2008 in Copenhagen, so I should  
have more time on my hands,

jonasbn
--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/