Want to be a Loom Contributor?

[maxim.porges]

Hello all,

I've been planning on getting back in to Loom since we got back from
our honeymoon in May. As it turns out, I haven't. I know I will get
motivated again, but it's killing me that this thing is so close to
completion and I've let it sit on the shelf for over two months.

All the hard, frustrating problems are solved. I now understand the
ABC spec inside-out, the bytecode weaving works beautifully, and the
proxies do what they are supposed to. What's left basically boils down
to the following.

(1) Optimizing constant pool entries during parsing of Tamarin-
compiled SWFs (i.e. turning off de-duplication checking),
(2) modifying the proxy generator to produce a single ABC file with
all the proxies (which is actually optional, but would be a more
correct and less bloatful method than what Loom does today),
(3) filling in the missing opcodes (grunt work, there's about 30
left), and
(4) refactoring the equals() method implementation for constant pool
objects to use a hash or some other fast lookup mechanism (also
optional but likely to be needed for the best performance).

I'm posting this message to see if anybody on the list is interested
in joining the project, tackling some/all of these items, and shaping
the future direction of Loom. If so, I'll be the project lead and will
shepherd the direction of the library; I have loads of ideas for where
to go after we have the proxying piece finished. Until I get my coding
mojo back, I'll obviously act in an advisory capacity so contributors
can come up to speed fast without having to spend ages (like I did)
deciphering the ABC file spec and opcode behavior.

Thanks again to everybody on the list for their continued interest and
support for Loom. I'm sorry I've been slacking off, but I figure it's
better to address this now and get the project moving again than let
it continue to sit there. I'm looking forward to hearing your thoughts
on the matter.

Cheers,

- max

[maxim.porges]

FYI, I just opened up the access to the discussion group so that it is
no longer private.

- max

[Drew Bourne]

Max,

I'd be happy to contribute.

I've got a bunch of specific use cases I want to tackle so getting
into the internals will help get them going.

cheers,
Drew

[Josh McDonald]

I'm happy to help out, I don't have a heap of time but I can find some, and I'll be making much use of Loom when it's done, so it's only fair :D

2009/7/29 maxim.porges <maxim....@gmail.com>

--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Josh 'G-Funk' McDonald
  -  jo...@joshmcdonald.info
  -  http://twitter.com/sophistifunk
  -  http://flex.joshmcdonald.info/

[maxim.porges]

That's awesome guys, thanks for throwing your names in the hat!

I figured the best way to get going would be for me to throw the code
in to the Google Code project, and then give you each a branch to work
from for changes. After you get a chance to look at the code and get
familiar, we can figure out how we want to proceed with the remaining
items. What do you think? If you agree, I'll start a topic on the next
release once the code is up.

I think I trashed my workspace a little while debugging the SWFLoader
issue, so I'll take a look and make sure it's all building nicely and
doesn't have any random or unnecessary traces before I post the code
to the project site. I'll plan on getting that up there this week.

Cheers,

- max

On Jul 28, 11:24 pm, Josh McDonald <j...@joshmcdonald.info> wrote:
> I'm happy to help out, I don't have a heap of time but I can find some, and
> I'll be making much use of Loom when it's done, so it's only fair :D
>

> 2009/7/29 maxim.porges <maxim.por...@gmail.com>

>   -  j...@joshmcdonald.info

[Josh McDonald]

Sounds fine Max :)

2009/7/29 maxim.porges <maxim....@gmail.com>

  -  jo...@joshmcdonald.info

[craig w]

Is there any code samples, unit tests, "tutorial" showing how it is expected to be used?  that would help those that are interested in diving into the code.

-craig

[Maxim Porges]

There are a few on the group. There should be one in each alpha release, and I put up a post about inspecting opcodes in abc files as well. We'll obviously need more of this as we go, so post your questions as they arise and I'll start filling the wiki on the Google Code site. 

http://groups.google.com/group/loom-as3/browse_thread/thread/833cc9eed0757e7c

- max

[craig w]

oh ok. I guess I was thinking that in my code I would be able to annotate (i.e. metadata tags) methods/classes to add functionality, is that not the case?

[Maxim Porges]

Yeah, you are a release or two ahead of us. :)

The problem with AS3 is that there is no generic CGLIB-style equivalent for weaving bytecode and making classes dynamically in memory. That's the bit Loom is addressing, after which we'll go crazy with mocking frameworks and aspect libraries and all that fun-ness. I started with proxying because that was the most common use case for the most useful part of having dynamic classes.

There are a few successful implementations out there that generate AS3 bytecode, but they are all pretty purpose-built. The intention for Loom is to be generic and flexible (and stay that way), while providing some utility packages for different specializations of bytecode-weaving use cases.

- max

[maxim.porges]

Hey guys,

Sorry for the delay. I got a mild case of what felt like the flu last
week, but I'm back in action now.

While cleaning up the Loom codebase tonight in readiness for getting
the source published, I figured out a shortcut for the deduping
constant pool issue and optimized the deserializer accordingly. SWF
parsing speed is about 10x faster now, and the multiname issue with
SWF parsing is now fixed.

Messing around with some coarse optimizations, I found that bytecode
parsing speed improves by roughly 1/3 if Loom skips the parsing step
for opcodes in method bodies. Technically, we don't need the method
body opcodes in order to create proxies, since all the proxy method
bodies get generated anyway. What I expect we'll end up doing is
making a variety of flags for the deserializer and then we can set it
up to be as fast as possible for each use case.

Running the largest SWF I have access to through Loom (2.7 MB
compressed) resulted in two ABC frames. The first was 116,127 bytes
uncompressed and took 204 ms to parse, and the second was 2,865,247
bytes uncompressed and took 32,862 ms to parse. This puts parsing
speed at roughly 86 KB/sec, which is probably too slow for a preloader
on a production app of this size. That being said, I ran another SWF
app through that was 280 KB and it took around 2-3 seconds on average,
which is certainly viable for runtime SWF loading and enhancement.

So, for bigger apps, we'll probably need an AIR-based compile-time
weaver. Another option is to make a proxy weaver that works off of
describeType() info, which is certainly viable. Even though this
approach doesn't yield all the in-depth goodies you can get from
looking at the ABC bytecode directly, it will run faster at load time
and be perfectly adequate for proxy generation. So again, optimized
paths for different use cases will be appropriate.

Anyway, just wanted to post a status update. Watch this space for
more.

Thanks,

- max

> >http://groups.google.com/group/loom-as3/browse_thread/thread/833cc9ee...
>
> > - max

>
> > On Jul 29, 2009, at 5:45 AM, craig w <codecr...@gmail.com> wrote:
>
> >> Is there any code samples, unit tests, "tutorial" showing how it is  
> >> expected to be used?  that would help those that are interested in  
> >> diving into the code.
>
> >> -craig
>

> >> On Tue, Jul 28, 2009 at 11:38 PM, Josh McDonald <j...@joshmcdonald.info

> >> > wrote:
> >> Sounds fine Max :)
>

> >> 2009/7/29 maxim.porges <maxim.por...@gmail.com>

[Nimrod97]

hi Maxim, what is current state of the project? it would be nice to
get source code...

[maxim.porges]

Sorry, I had not had a chance to post the source yet - but it's out
there now.

The unit test suite is a little weird in some places, and there is
some unfinished code kicking about, but it's all there. The next order
of business is to get the DynamicProxyFactory to create new proxies
from scratch instead of modifying existing AbcFile instances.

I'm looking forward to questions, comments, and submissions now that
the source is available. Enjoy!

Cheers,

- max