Re: javaflow & aranea continuations

[Stefano Bagnara <ap...@bago.org>]

Torsten Curdt ha scritto:
> Hey Stefano
 >> [...]
>> I read this:
>> http://svn.apache.org/repos/asf/commons/sandbox/javaflow/trunk/TODO
>> but it seems a bit outdated (asm support marked as "maybe" seems to be 
>> there, the BCEL issues seems fixed following rhe links)... Running the 
>> tests seems that ASM and BCEL enhancer have the same quality level, 
>> but I may be missing something as I simply looked at test results.
> 
> Well, the ASM enhancer should still be considered experimental. And 
> someone reported it to be much slower than the BCEL one.
> (Which is a bit of a surprise) Still I would love to see ASM being used 
> as the main engine. Just because the library has a much better community.

I've worked only on the ASM enhancer because it seems much more simple 
to understand.
Is the enhancing process or the enhanced code to be slower?

>> I see there is no action around javaflow in the last year: is this 
>> because of critical issues with its continuation approach or simply 
>> lack of interest?
> 
> Well, I don't really use it at work anymore. And rarely people even just 
> gave feedback. Not talking about any contributions. Especially when in 
> the end I hear about people using it in their PhD thesis or some cool 
> projects I am a little in between. "Cool!" and "WTF didn't you show up 
> on the mailing lists". It's too much work if you don't get paid for it 
> and don't even use it. Plus I am not a big fan of one man shows.

I understand!
Maybe Servlet-3.0 suspend/resume stuff will make tomcat people to be 
interested in javaflow.. Maybe I'll ping them sooner or later.

>> About "talk to the RIFE guys"/"talk to the aspectwerkz and aspectj 
>> folks", did anything happen?
> 
> I only have talked briefly with Geert. He was considering changing the 
> license and working together on it. While it is not as generic as 
> javaflow he is happy with his implementation. So I guess I just did not 
> have enough energy following up on this.

I don't know anything about RIFE continuations methods. Does it still 
work with bytecode enhancement and a StackRecorder like runtime object?

>> I didn't find too much activity (docs/webpages) around RIFE 
>> continuations or any of the above and even about the JSR proposal.
> 
> Geert did file the JSR proposal though. Unfortunately it got rejected. 
> Even from the ASF. Which really annoyed me a little. But anyway.

Weird, really.

>> I checked out the sources with eclipse and enabled m2eclipse, the only 
>> issue I found is that the main pom references 
>> commons-jci-core:1.0-SNAPSHOT. I see commons-jci-core:1.0 has been 
>> released so I removed "-SNAPSHOT" and it succesfully built.
> 
> Nice
> 
>> I found at least a couple of projects around using self compiled 
>> javaflow libraries so it seems that even if it is incomplete it is 
>> useful to the world. Is there any motivation against making a 0.1 
>> release in commons or is it simply lack of time?
> 
> A few people asked for a release. But I didn't know about so many 
> projects using it. (Guess I know about 3-4 projects plus a couple of PhD 
> thesis). I would be happy to follow up and do a release. But there are a 
> couple of things that I would like to see fixed before you finalize and 
> commit to an API. And that's still quite a bit of work.

I succesfully made the ASM testsuite to fully pass 
(SANDBOX-254+SANDBOX-255 patches). If there are known limitations can 
you create failing tests for them?

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org

Re: javaflow & aranea continuations

[Torsten Curdt <tc...@apache.org>]

>> Well, the ASM enhancer should still be considered experimental. And  
>> someone reported it to be much slower than the BCEL one.
>> (Which is a bit of a surprise) Still I would love to see ASM being  
>> used as the main engine. Just because the library has a much better  
>> community.
>
> I've worked only on the ASM enhancer because it seems much more  
> simple to understand.
> Is the enhancing process or the enhanced code to be slower?

The final code should be the same. The enhancing process has been  
reported to be slower.

>>> I see there is no action around javaflow in the last year: is this  
>>> because of critical issues with its continuation approach or  
>>> simply lack of interest?
>> Well, I don't really use it at work anymore. And rarely people even  
>> just gave feedback. Not talking about any contributions. Especially  
>> when in the end I hear about people using it in their PhD thesis or  
>> some cool projects I am a little in between. "Cool!" and "WTF  
>> didn't you show up on the mailing lists". It's too much work if you  
>> don't get paid for it and don't even use it. Plus I am not a big  
>> fan of one man shows.
>
> I understand!
> Maybe Servlet-3.0 suspend/resume stuff will make tomcat people to be  
> interested in javaflow.. Maybe I'll ping them sooner or later.

Cool

>>> About "talk to the RIFE guys"/"talk to the aspectwerkz and aspectj  
>>> folks", did anything happen?
>> I only have talked briefly with Geert. He was considering changing  
>> the license and working together on it. While it is not as generic  
>> as javaflow he is happy with his implementation. So I guess I just  
>> did not have enough energy following up on this.
>
> I don't know anything about RIFE continuations methods. Does it  
> still work with bytecode enhancement and a StackRecorder like  
> runtime object?

Yes, they took a slightly different approach though.

> I succesfully made the ASM testsuite to fully pass  
> (SANDBOX-254+SANDBOX-255 patches). If there are known limitations  
> can you create failing tests for them?

I've just looked into them but (see the comment) but unfortunately  
patches also did not apply cleanly.

I hope to have some more time this week.

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org