Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Pipes and the StateMachine Walkthrough  (Read 11974 times)
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« on: May 18, 2009, 01:44:52 »

http://joelhooks.com/2009/05/18/piping-the-machine-puremvc-multicore-with-pipes-and-the-finite-state-machine-fsm/

I took the Sea of Arrows player and deconstructed the elements to create this walkthrough of the process of combining Multicore PureMVC, Pipes, and the StateMachine in an application.
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
Ondina
Sr. Member
****
Posts: 86


View Profile Email
« Reply #1 on: May 19, 2009, 12:52:40 »

Thank you Joel!
Your addition to Cliff's demo has great didactic value.

Ondina.
Logged

~ Ondina ~
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: May 19, 2009, 08:48:48 »

Nice. Thanks much for this, Joel.  ;)

-=Cliff>
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #3 on: May 19, 2009, 10:19:49 »

Nice. Thanks much for this, Joel.  ;)

-=Cliff>

Best way to understand something for me is to break it down, rebuild, and document. Did I mention how much I dig your music on SoA? I was grooving to it all weekend while I worked on this :>

I have a question regarding Pipes. I know it has been hashed over a bit and I've read the existing discussion, but I am still unclear about cleanly separating modules on unload.

When the module receives the notification to disconnect, its JunctionMediator grabs its pipes (STDIN & STDOUT), calls their disconnect methods and then calls removePipe() on the mediated Junction. This effectively disconnects the dedicated pipe to the shell, but leaves me with a null output on the shell's STDOUT which causes an exception when the shell tries to broadcast a message. If I simply call removePipe() it doesn't cause the exception, but it also leaves the JunctionMediator in memory. It is disconnected from any facade, so it doesn't do aything in response to the messages, but it is still there (LEAK!) and I want it to die ;)

So what I did was create a ManagedJunctionMediator that keeps a HashMap of the modules UID and the connections. It then goes through and physically removes the output from STDOUT. This is so nasty and stinks my code up, but I can't figure out how to remove individual outputs from a Pipe. I feel like disconnect() should remove the null output on the other end on the connection...

What am I doing wrong?
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: May 20, 2009, 06:14:14 »

Thanks for the kind words about the noodling :)

Have a look at this:
http://www.nutrixinteractive.com/blog/?p=132

Simon beat his head against this for days to get reliable disconnection.

One thing I can say is that Flex/Flash GC doesn't always seem to play by the rules and it's a little maddening to me sometimes. In the SoA app, currently, I've got a problem destroying visualizers. I can't seem to shake the little buggers loose. Of course I'm not connecting and disconnecting cores, just trying to make view components go away.

-=Cliff>
PS: I added fullscreen mode for the app yesterday. Click on the application control bar or the visualizer to make it go fullscreen. Clicking again on the app control bar restores to normal, but the visualizer is one way;  go full screen if not already, otherwise change the current visualizer. The code isn't up there because it's in a library now which'll be out as soon as I finish PureMVC TV with it.
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #5 on: May 20, 2009, 07:04:30 »

...as soon as I finish PureMVC TV with it.

*perks up*

Ok, I'll admit you sparked my curiosity! What is this "TV" you speak of?
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #6 on: May 20, 2009, 07:28:46 »

Thanks for the kind words about the noodling :)

Have a look at this:
http://www.nutrixinteractive.com/blog/?p=132

Simon beat his head against this for days to get reliable disconnection.

One thing I can say is that Flex/Flash GC doesn't always seem to play by the rules and it's a little maddening to me sometimes. In the SoA app, currently, I've got a problem destroying visualizers. I can't seem to shake the little buggers loose. Of course I'm not connecting and disconnecting cores, just trying to make view components go away.

-=Cliff>
PS: I added fullscreen mode for the app yesterday. Click on the application control bar or the visualizer to make it go fullscreen. Clicking again on the app control bar restores to normal, but the visualizer is one way;  go full screen if not already, otherwise change the current visualizer. The code isn't up there because it's in a library now which'll be out as soon as I finish PureMVC TV with it.

I read Simon's post, and it isn't related to the GC. The Junction in a JunctionMediator isn't garbage collected because the fittings are still held. disconect() solves this, but leaves a null pointer in the array held by the other end of the pipe. The null is really my issue, when I disconnect I want it to cleanly disconnect, and don't see a reason why it would leave a null object in the other side's array of outputs.

I've found that the GC is really sensitive to the retain count of objects. As it should be, but it is so easy to have rogue objects being stored on other objects which will ruin GC all the way up the display list.

/edit
so I am hacking at my issue and I made Pipe and TeeSplit extend EventDispatcher. When an output is connected to the TeeSplit is registers an EventListener (IPipeFitting got an addEventListener method). When a Pipe disconnects it dispatches a PipeEvent.DISCONNECT_FITTING event that the TeeSplit uses to invoke its disconnectFitting method on the event.target. Outside of the fact that I am hacking at the utility, this solution solves my problem and smells pretty good.

Why is it bad? ;)
« Last Edit: May 20, 2009, 10:01:15 by Joel Hooks » Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: May 22, 2009, 04:41:01 »

Its not good or bad, but because you might not be able to do it that way in, say, Java or some other Port (real or hypothetical) that supports multicore/pipes, its not a solution I would advocate.

Since PureMVC has proven to be a portable system I need to seek best practices that work across platforms.

I use events often in my Flex work at the boudaries (services and view components), but for plumbing and other things inside the sandwich, I stick to portable answers.

-=Cliff>
Logged
Pages: [1]
Print