Continuation sadness

View: New views
4 Messages — Rating Filter:   Alert me  

Continuation sadness

by Patrick Lightbody-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Getting these errors in my WebWork action when using continuations:

com.uwyn.rife.continuations.exceptions.LocalVariableUncloneableException
: The implementation  
'com.autoriginate.litmus.action.IntroduceMacroAction' uses a local  
method variable of type 'java.util.AbstractList$Itr' which is not  
cloneable.

I believe it is coming from this particular line:

for (long id : commandIds) {

Though I can't be sure.

Is there any way to deal with uncloneable variables? Perhaps we can  
introduce an interface that indicates that the continuation support  
shouldn't "remember" multiple states, allowing RIFE/Continuations to  
simply use the original variable rather than clone it?

Patrick

_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

Re: Continuation sadness

by Geert Bevin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Patrick,

that is possible in the RIFE version of continuations. While  
stripping it out you seem to have removed the feature. Line 140 of  
ContinuationManager reads "if (true)", while in the RIFE version this  
checks for a setting that indicates if the cloning should happen or not.

One thing that also really helps to work around these errors, is to  
simply extract the piece of logic that contains unclonable variables  
into a dedicated method. It will then not be instrumented.

Hope this helps,

Geert

On 16-feb-06, at 03:03, Patrick Lightbody wrote:

> Getting these errors in my WebWork action when using continuations:
>
> com.uwyn.rife.continuations.exceptions.LocalVariableUncloneableExcepti
> on: The implementation  
> 'com.autoriginate.litmus.action.IntroduceMacroAction' uses a local  
> method variable of type 'java.util.AbstractList$Itr' which is not  
> cloneable.
>
> I believe it is coming from this particular line:
>
> for (long id : commandIds) {
>
> Though I can't be sure.
>
> Is there any way to deal with uncloneable variables? Perhaps we can  
> introduce an interface that indicates that the continuation support  
> shouldn't "remember" multiple states, allowing RIFE/Continuations  
> to simply use the original variable rather than clone it?
>
> Patrick
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

Re: Continuation sadness

by Patrick Lightbody-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Good catch. I've created a patch that should do the trick.

There are three patches:

* build.patch forces the compile to be for Java 1.4
* idea.patch changes the JRE to be "1.4", which is the new standard for IDEA 5.0
* non-cloning.patch is the meat of it :)

Will RIFE be using the RIFE/Continuations project at some point?

Patrick

On 2/15/06, Geert Bevin <gbevin@...> wrote:

> Hi Patrick,
>
> that is possible in the RIFE version of continuations. While
> stripping it out you seem to have removed the feature. Line 140 of
> ContinuationManager reads "if (true)", while in the RIFE version this
> checks for a setting that indicates if the cloning should happen or not.
>
> One thing that also really helps to work around these errors, is to
> simply extract the piece of logic that contains unclonable variables
> into a dedicated method. It will then not be instrumented.
>
> Hope this helps,
>
> Geert
>
> On 16-feb-06, at 03:03, Patrick Lightbody wrote:
>
> > Getting these errors in my WebWork action when using continuations:
> >
> > com.uwyn.rife.continuations.exceptions.LocalVariableUncloneableExcepti
> > on: The implementation
> > 'com.autoriginate.litmus.action.IntroduceMacroAction' uses a local
> > method variable of type 'java.util.AbstractList$Itr' which is not
> > cloneable.
> >
> > I believe it is coming from this particular line:
> >
> > for (long id : commandIds) {
> >
> > Though I can't be sure.
> >
> > Is there any way to deal with uncloneable variables? Perhaps we can
> > introduce an interface that indicates that the continuation support
> > shouldn't "remember" multiple states, allowing RIFE/Continuations
> > to simply use the original variable rather than clone it?
> >
> > Patrick
> >
> > _______________________________________________
> > Rife-devel mailing list
> > Rife-devel@...
> > http://lists.uwyn.com/mailman/listinfo/rife-devel
> >
>
> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>




_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

build.patch (640 bytes) Download Attachment
idea.patch (39K) Download Attachment
non-cloning.patch (2K) Download Attachment

Re: Continuation sadness

by Geert Bevin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Patrick,

as said on IRC, just commit these.

RIFE will certainly use RIFE/Continuations. I haven't had time to  
work on continuations at all during the past month. However, I'd like  
to improve and clean up the lib a lot before TSSJS and then fold that  
back to RIFE itself. I hope to have enough time to do that in the  
next weeks.

Best regards,

Geert

On 17-feb-06, at 01:16, Patrick Lightbody wrote:

> Good catch. I've created a patch that should do the trick.
>
> There are three patches:
>
> * build.patch forces the compile to be for Java 1.4
> * idea.patch changes the JRE to be "1.4", which is the new standard  
> for IDEA 5.0
> * non-cloning.patch is the meat of it :)
>
> Will RIFE be using the RIFE/Continuations project at some point?
>
> Patrick
>
> On 2/15/06, Geert Bevin <gbevin@...> wrote:
>> Hi Patrick,
>>
>> that is possible in the RIFE version of continuations. While
>> stripping it out you seem to have removed the feature. Line 140 of
>> ContinuationManager reads "if (true)", while in the RIFE version this
>> checks for a setting that indicates if the cloning should happen  
>> or not.
>>
>> One thing that also really helps to work around these errors, is to
>> simply extract the piece of logic that contains unclonable variables
>> into a dedicated method. It will then not be instrumented.
>>
>> Hope this helps,
>>
>> Geert
>>
>> On 16-feb-06, at 03:03, Patrick Lightbody wrote:
>>
>>> Getting these errors in my WebWork action when using continuations:
>>>
>>> com.uwyn.rife.continuations.exceptions.LocalVariableUncloneableExcep
>>> ti
>>> on: The implementation
>>> 'com.autoriginate.litmus.action.IntroduceMacroAction' uses a local
>>> method variable of type 'java.util.AbstractList$Itr' which is not
>>> cloneable.
>>>
>>> I believe it is coming from this particular line:
>>>
>>> for (long id : commandIds) {
>>>
>>> Though I can't be sure.
>>>
>>> Is there any way to deal with uncloneable variables? Perhaps we can
>>> introduce an interface that indicates that the continuation support
>>> shouldn't "remember" multiple states, allowing RIFE/Continuations
>>> to simply use the original variable rather than clone it?
>>>
>>> Patrick
>>>
>>> _______________________________________________
>>> Rife-devel mailing list
>>> Rife-devel@...
>>> http://lists.uwyn.com/mailman/listinfo/rife-devel
>>>
>>
>> --
>> Geert Bevin                       Uwyn bvba
>> "Use what you need"               Avenue de Scailmont 34
>> http://www.uwyn.com               7170 Manage, Belgium
>> gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03
>>
>> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
>> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>>
>>
>> _______________________________________________
>> Rife-devel mailing list
>> Rife-devel@...
>> http://lists.uwyn.com/mailman/listinfo/rife-devel
>>
>> <build.patch>
>> <idea.patch>
>> <non-cloning.patch>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
 
 
 
Google
rifers.org web