Refactoring connections

[dancrumb]

So, this is a whole host of moving code around.

As I was steadily understanding how things worked, I started renaming variable and functions, or extracting stuff, so that the code more readily explained itself.

I noticed a lot of code where Object A was making modifications to Object C or D's properties, even though they were owned by Object B.

I've tried to rejig things so that there is a little more encapsulation.

I also beefed up the tracing.

Finally, after all this, I did some profiling and made the odd tweak here and there.

All in all, it's mostly just relocation of code. I understand that it's a chunk of work, but I hope it adds clarity to you as well as me.

[dancrumb]

Ignore this PR for now... I've got a little more work to do, then I want to add some notes to the PR itself.

[jpaulm]

No problem! This is fantastic!

Bert Madeira is considering some repackaging of JavaFBP - is this something
you would be interested in participating in or advising on?

Regards,

Paul

On Tue, Jun 7, 2016 at 12:37 AM, Dan Rumney notifications@github.com
wrote:

Ignore this PR for now... I've got a little more work to do, then I want
to add some notes to the PR itself.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#74 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AATGJ5kTFeE2IYKJPZ2SDqmsWdKzzhocks5qJPWHgaJpZM4IviIh
.

[dancrumb]

Appreciate the offer, but Java is not a strength of mine and there are a few more things I'd like to make sure are supported by JSFBP

[dancrumb]

These are the logs that the node profiler generates, so we can ignore them

[dancrumb]

OK - this is ready for your reviewing

[dancrumb]

I am finding this very useful. When there's a deadlock, show all the connections and which ones are full. This may help identify why there's a deadlock.

[jpaulm]

Sounds good - is this integrated with my deadlock display - or does it
replace it?!

On Wed, Jun 8, 2016 at 11:04 AM, Dan Rumney notifications@github.com
wrote:

In core/Network.js
#74 (comment):

@@ -86,12 +87,20 @@ Network.prototype.getProcessByName = function (processName) {

Network.prototype.run = function (runtime, options, callback) {

options = options || {};

• _.forEach(this._processes, function (process) {
• _.invokeMap(process.inports, 'setRuntime', runtime);
• _.invokeMap(process.outports, 'setRuntime', runtime);
• });
• runtime.run(_.values(this._processes), options, callback || function () {});
• callback = callback || function () {};

• _.invokeMap(this._connections, 'setRuntime', runtime);

• try {
• runtime.run(_.values(this._processes), options, callback );
• } catch (e) {
• console.log('Connections');

I am finding this very useful. When there's a deadlock, show all the
connections and which ones are full. This may help identify why there's
a deadlock.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jpaulm/jsfbp/pull/74/files/d12c2b94b326314da1d5fe633ff423f329d25d0b#r66273523,
or mute the thread
https://github.com/notifications/unsubscribe/AATGJzMTFg7DyGNxVKEd04O0zZJkEXXbks5qJtoOgaJpZM4IviIh
.

[dancrumb]

Then runtime still displays the deadlock details. Network then catches the exception that gets thrown and shows the connection details.

[jpaulm]

Came across message "No process passed to input port" , apparently generated by InputPort.js . Since InputPort is not specified by the developer, it seems unlikely that it will be called with a missing or null parameter...? Just curious...

[dancrumb]

What were you running when you saw that message?

[jpaulm]

npm test

Here is the output from InputPort.js:

InputPort
No process passed to input port: undefined
Accessing IP types from IP object directly is deprecated. Please use IP.Types.NO
RMAL
V can receive IIPs
No process passed to input port: undefined
V returns null from a closed connection

[dancrumb]

Strange. You're on the master branch, I assume? And you're up to date (git
pull)?

On Wed, Jun 8, 2016, 20:54 Paul Morrison notifications@github.com wrote:

npm test

Here is the output from InputPort.js:

InputPort
No process passed to input port: undefined
Accessing IP types from IP object directly is deprecated. Please use
IP.Types.NO
RMAL
V can receive IIPs
No process passed to input port: undefined
V returns null from a closed connection

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#74 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AANhTzZBFwwUiLbe1h_MSfMrwNRZfE6mks5qJ3JygaJpZM4IviIh
.

[dancrumb]

Disregard that last comment... I see them.

I'll take a look at the tests

On Wed, Jun 8, 2016, 23:20 Dan Rumney dancrumb@gmail.com wrote:

Strange. You're on the master branch, I assume? And you're up to date (git
pull)?

On Wed, Jun 8, 2016, 20:54 Paul Morrison notifications@github.com wrote:

npm test

Here is the output from InputPort.js:

InputPort
No process passed to input port: undefined
Accessing IP types from IP object directly is deprecated. Please use
IP.Types.NO
RMAL
V can receive IIPs
No process passed to input port: undefined
V returns null from a closed connection

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#74 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AANhTzZBFwwUiLbe1h_MSfMrwNRZfE6mks5qJ3JygaJpZM4IviIh
.