I am considering creating a VM for Self with some language extensions and would like comments:
1) I am considering making the inheritance of structural slots declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
2) I am considering adding an annotation to a slot that will cause it to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Let me know what you think, or if there are good reasons to leave it in code.
Michael
On Friday 25 June 2004 08:48, Michael Latta wrote:
I am considering creating a VM for Self with some language extensions and would like comments:
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
- I am considering adding an annotation to a slot that will cause it
to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Let me know what you think, or if there are good reasons to leave it in code.
A little off track, but, I'd like to see the following in Self:
1) a drastically simplified VM so that it can be more easily ported. All ports but the Sparc and Mac are a little flaky in my experience (sometimes a lot flaky). Having a VM that is so difficult to port makes support and expansion of the Self "marketplace" more difficult.
2) move more of the optimization into Self rather than hardcoded in the VM in C++.
I like your ideas about the language! While I like Self's simplicity a lot, it is often nice to have reasonable short cuts for very common idioms like those you've covered above.
I'm unclear on what the current license of Self is. It was a bit restrictive at one point, but that was a long time ago.
Best, Kyle
The current license basically says do what you want with it so long as we do not get blamed.
Michael
On Jun 25, 2004, at 11:18 AM, Kyle Hayes wrote:
On Friday 25 June 2004 08:48, Michael Latta wrote:
I am considering creating a VM for Self with some language extensions and would like comments:
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
- I am considering adding an annotation to a slot that will cause it
to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Let me know what you think, or if there are good reasons to leave it in code.
A little off track, but, I'd like to see the following in Self:
- a drastically simplified VM so that it can be more easily ported.
All ports but the Sparc and Mac are a little flaky in my experience (sometimes a lot flaky). Having a VM that is so difficult to port makes support and expansion of the Self "marketplace" more difficult.
- move more of the optimization into Self rather than hardcoded in
the VM in C++.
I like your ideas about the language! While I like Self's simplicity a lot, it is often nice to have reasonable short cuts for very common idioms like those you've covered above.
I'm unclear on what the current license of Self is. It was a bit restrictive at one point, but that was a long time ago.
Best, Kyle
Yahoo! Groups Links
On Friday 25 June 2004 17:12, Michael Latta wrote:
The current license basically says do what you want with it so long as we do not get blamed.
All versions that Sun has released had a similar license, though the early versions had the infamous "advertising clause" (which I don't mind at all).
The Self 1.X VMs were never released at all. I don't remember about 2.0, but at least I don't have a copy of it. And Self 4.1 was internal to Sun four about three years before being finally released under the current license.
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
This is actually how it is done in the programming environment (you set the slots in the parent as "copydown" and they show as pink in the outliner) even though saving a module as text creates some code to actually implement this imperatively.
- I am considering adding an annotation to a slot that will cause
it to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Ok, so you want to control "deep copies". It wasn't clear to me what you meant above by "cloning a slot". This is a very interesting issue. When you clone a morph, you certainly want to clone its submorphs too.
Let me know what you think, or if there are good reasons to leave it in code.
It is easy to come up with interesting features that make some example or other nicer, as David Ungar always says in his talks. The problem is that language complexity grows exponentially since each new feature interacts with all previous ones.
Both issues you mentioned can be viewed as particular instances of something larger - how can you organize stuff so sometimes you see a single object and sometimes you see smaller pieces which can be shared in interesting ways?
My first suggestion would be for you to read the Us paper (a subjective version of Self): http://citeseer.ist.psu.edu/smith96simple.html
This won't solve your problems, but should help you think in a more general way about them.
The "an object is really a tree of stuff and not just the root" thing was a major complication for me in parallelizing Self in tinySelf 1 and in my current work. Beyond subjects/viewpoints, there is an interesting idea I used in a language called NeoLogo which is "roles". I won't go into details here, but at first I thought that viewpoints was a good replacement for this, but now I see that though very similar they actually complement each other.
I would like one solution to all of these problems, and which made the resulting language even simpler. Never, ever forget "the power of simplicity".
Kyle Hayes wrote:
A little off track, but, I'd like to see the following in Self:
- a drastically simplified VM so that it can be more easily
ported. All ports but the Sparc and Mac are a little flaky in my experience (sometimes a lot flaky). Having a VM that is so difficult to port makes support and expansion of the Self "marketplace" more difficult.
A proper Self implementation should be in Self.
- move more of the optimization into Self rather than hardcoded in
the VM in C++.
See 1 ;-)
I like your ideas about the language! While I like Self's simplicity a lot, it is often nice to have reasonable short cuts for very common idioms like those you've covered above.
Unless you want to use it in a scripting language style (like 3.0 and earlier), Self is a language and an environment. We can have as many shortcuts as you want in the latter without having to complicate the former. The copydown thing is a good example.
-- Jecel
I will read the paper for sure.
I am no hurry to add features to Self. You are correct that adding features to satisfy examples is a bad methodology for language design. Just look at UML 2.0 for an example.
I would say however that simple is not enough, it must be simply elegant. The simplicity must solve a number of issues. I am sure you had this in mind as well. Just as Self can meet all the needs of class based inheritance without needing all the attendant infrastructure or restrictions, it would be better to have a simple elegant solution to many problems such as cloning of trees of objects, and adding transactionality to objects, and concurrency control, etc. I may end up landing on something more akin to aspects than any specific features. At this early stage it is still mostly an adventure, the result of the journey can not yet be predicted.
Michael
On Jun 25, 2004, at 4:21 PM, Jecel Assumpcao Jr wrote:
On Friday 25 June 2004 17:12, Michael Latta wrote:
The current license basically says do what you want with it so long as we do not get blamed.
All versions that Sun has released had a similar license, though the early versions had the infamous "advertising clause" (which I don't mind at all).
The Self 1.X VMs were never released at all. I don't remember about 2.0, but at least I don't have a copy of it. And Self 4.1 was internal to Sun four about three years before being finally released under the current license.
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
This is actually how it is done in the programming environment (you set the slots in the parent as "copydown" and they show as pink in the outliner) even though saving a module as text creates some code to actually implement this imperatively.
- I am considering adding an annotation to a slot that will cause
it to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Ok, so you want to control "deep copies". It wasn't clear to me what you meant above by "cloning a slot". This is a very interesting issue. When you clone a morph, you certainly want to clone its submorphs too.
Let me know what you think, or if there are good reasons to leave it in code.
It is easy to come up with interesting features that make some example or other nicer, as David Ungar always says in his talks. The problem is that language complexity grows exponentially since each new feature interacts with all previous ones.
Both issues you mentioned can be viewed as particular instances of something larger - how can you organize stuff so sometimes you see a single object and sometimes you see smaller pieces which can be shared in interesting ways?
My first suggestion would be for you to read the Us paper (a subjective version of Self): http://citeseer.ist.psu.edu/smith96simple.html
This won't solve your problems, but should help you think in a more general way about them.
The "an object is really a tree of stuff and not just the root" thing was a major complication for me in parallelizing Self in tinySelf 1 and in my current work. Beyond subjects/viewpoints, there is an interesting idea I used in a language called NeoLogo which is "roles". I won't go into details here, but at first I thought that viewpoints was a good replacement for this, but now I see that though very similar they actually complement each other.
I would like one solution to all of these problems, and which made the resulting language even simpler. Never, ever forget "the power of simplicity".
Kyle Hayes wrote:
A little off track, but, I'd like to see the following in Self:
- a drastically simplified VM so that it can be more easily
ported. All ports but the Sparc and Mac are a little flaky in my experience (sometimes a lot flaky). Having a VM that is so difficult to port makes support and expansion of the Self "marketplace" more difficult.
A proper Self implementation should be in Self.
- move more of the optimization into Self rather than hardcoded in
the VM in C++.
See 1 ;-)
I like your ideas about the language! While I like Self's simplicity a lot, it is often nice to have reasonable short cuts for very common idioms like those you've covered above.
Unless you want to use it in a scripting language style (like 3.0 and earlier), Self is a language and an environment. We can have as many shortcuts as you want in the latter without having to complicate the former. The copydown thing is a good example.
-- Jecel
Yahoo! Groups Links
On Friday 25 June 2004 22:03, Michael Latta wrote:
I will read the paper for sure.
I agree with the comments you made in the other email. In fact, I had said that this could be an inspiration for you, but was not likely to be a solution.
I would say however that simple is not enough, it must be simply elegant. The simplicity must solve a number of issues. I am sure you had this in mind as well. Just as Self can meet all the needs of class based inheritance without needing all the attendant infrastructure or restrictions, it would be better to have a simple elegant solution to many problems such as cloning of trees of objects, and adding transactionality to objects, and concurrency control, etc. I may end up landing on something more akin to aspects than any specific features. At this early stage it is still mostly an adventure, the result of the journey can not yet be predicted.
One thing that is important to distinguish is whether a given instance of simplicity is "painful" or "joyful".
Imagine that you are trying to create the simplest paint program possible. The user interface could use just two keys: "space" moves the cursor to the next pixel and "tab" cycles the current pixel between all available colors. This is enough to get the job done, but nobody would say it was fun to go back a pixel (you have to press "space" (800x600)-1 times for a medium resolution drawing!).
You could make it a little more complex: four cursor keys to change the pixel selection and "tab" for the color. This is much more joyful to use. And you could add even more stuff. There is a point in which the extra complexity will make the program less fun to use.
Normally we would be coming from the opposite direction - our first attempts are much more complicated than needed. Einstein said "make things as simple as possible, but no simpler". I understood that to mean the point of maximum joy.
-- Jecel P.S.: http://www.merlintec.com:8080/software/11 shows some of my attempts to find that point, including regarding things such as optional arguments and stuff
IIRC, I read someplace that the earliest version of Self was text-based. I was wondering if the syntax is described any place. I written the engine for a small prototype-based language, but I haven't defined a syntax yet. There are a couple of directions I can go in. I can make it similar to B (predecessor of C) but frankly, this is just for fun. I don't think I want to write the parser for something like that when it would be far easier to adopt Smalltalk/Self syntax.
I've considered something like this, C-ish but with anonymous functions, but it strikes me as rather ugly:
testmaker.make = (){ var test test.passed = false test.setup = (){} test.teardown = (){} test.runTest = (result){} test.assert = (message, condition){ condition.ifTrue((){ passed = false self.message = message }) } test.run = (result){ setup() runTest() tearDown() passed.ifFalse((){ result.addFailure(message) }) } test }
Thoughts?
Michael
On Sunday 27 June 2004 11:34, Michael Feathers wrote:
IIRC, I read someplace that the earliest version of Self was text-based. I was wondering if the syntax is described any place.
The textual syntax is still there - you can run Self in a terminal and never fire up the GUI if you don't want it. What has changed is that applications are now normally created graphically and then a text version is generated automatically by the "transporter". This is far less readable than the old hand written sources.
The programming manual includes the syntax, but what was described in the very first paper ("power of simplicity") is mostly valid today.
http://research.sun.com/self/language.html
For a C-like Self variant, take a look at NewtonScript.
http://www.cc.gatech.edu/~schoedl/projects/NewtonScript/ http://wsmith.best.vwh.net/works.html
Io and Slate might also be interesting for you, though they make do without an object literal syntax.
http://www.iolanguage.com/ http://slate.tunes.org
-- Jecel
Jecel Assumpcao Jr wrote:
Normally we would be coming from the opposite direction - our first attempts are much more complicated than needed. Einstein said "make things as simple as possible, but no simpler".
I tend to think that that is always the way it goes. We first overcomplicate things, and the simplification results from spotting patterns.
There's also the other problem- oversimplification.
For example, Java forbids operator overloading, and yet the language itself uses it for Strings. For good expressibility for handling matrix multiplication or complex arithmetic it's nigh on essential.
I think Self is guilty of oversimplification:
a) no privacy/security
b)
I understood that to mean the point of maximum joy.
With computer languages we are ultimately limited by the mythical man month concept- namely that there is no silver bullet to minimise software complexity and maximise productivity.
I personally believe that at best with computer languages we can minimise the number of problems that we cause ourself, and supply libraries and language features for design patterns.
Clearly to the extent that a language design forbids certain design patterns, that language has a deficiency.
For example in C++ you can do things like:
{ FileHandle f = open("/adirectory/aFile", open);
f << "I went to the zoo"; }
And the file may be automagically closed as f goes out of scope.
But this is unreliable in Java/Self/Smalltalk- you don't know when the GC will get around to release it. I consider this to be a bug in these languages.
This isn't apriori a question of destruction of the memory of variable f- if the language specification caused a special method to be invoked on the variable as it went out of scope then the appropriate behaviour could be obtained. The inefficiency may be easily optimised away by the compiler for the usual case of variables/objects that don't do anything in that case.
There's lots of other things like that.
-- Jecel P.S.: http://www.merlintec.com:8080/software/11 shows some of my attempts to find that point, including regarding things such as optional arguments and stuff
On Jun 27, 2004, at 8:57 AM, Ian Woollard wrote:
Jecel Assumpcao Jr wrote:
Normally we would be coming from the opposite direction - our first attempts are much more complicated than needed. Einstein said "make things as simple as possible, but no simpler".
I tend to think that that is always the way it goes. We first overcomplicate things, and the simplification results from spotting patterns.
There's also the other problem- oversimplification.
For example, Java forbids operator overloading, and yet the language itself uses it for Strings. For good expressibility for handling matrix multiplication or complex arithmetic it's nigh on essential.
I think Self is guilty of oversimplification:
a) no privacy/security
b)
For the day and purpose it was designed for (1995 research) it was not a deficiency. For modern times it is an issue if you want to be able to distribute components. Applications are not an issue, as security is not a feature of applications, only components. Even Java does not provide security for applications, only components. Until such time as the OS hosts all user code on a VM that has security features, there is no security. All we can do is make it harder to find the holes.
I would not look at Java as good language design, but it has one feature that is worth thinking about. That is the ability to tag methods/classes with semantic tags like private, transient, synchronized, etc. But, rather than having a fixed set that do a fixed set of things, I would like to see the language allow an extensible set that can be mapped to the language itself. This would probably end up more like aspects in the application. For JDK 1.5 they are adding "metadata" tags, which is extensible, but have no language semantics. They are just tags tools can use to manipulate the program after compilation.
I understood that to mean the point of maximum joy.
With computer languages we are ultimately limited by the mythical man month concept- namely that there is no silver bullet to minimise software complexity and maximise productivity.
I personally believe that at best with computer languages we can minimise the number of problems that we cause ourself, and supply libraries and language features for design patterns.
Clearly to the extent that a language design forbids certain design patterns, that language has a deficiency.
For example in C++ you can do things like:
{ FileHandle f = open("/adirectory/aFile", open);
f << "I went to the zoo";}
And the file may be automagically closed as f goes out of scope.
But this is unreliable in Java/Self/Smalltalk- you don't know when the GC will get around to release it. I consider this to be a bug in these languages.
This is inly an issue if you rely on the garbage collector to close files (which most experienced programmers do not). And the C case is far worse should you pass a pointer to "f" to another module that outlives the above code. In any event this is not a language issue, but a library issue.
This isn't apriori a question of destruction of the memory of variable f- if the language specification caused a special method to be invoked on the variable as it went out of scope then the appropriate behaviour could be obtained. The inefficiency may be easily optimised away by the compiler for the usual case of variables/objects that don't do anything in that case.
There's lots of other things like that.
-- Jecel P.S.: http://www.merlintec.com:8080/software/11 shows some of my attempts to find that point, including regarding things such as optional arguments and stuff
Yahoo! Groups Links
Michael Latta wrote:
On Jun 27, 2004, at 8:57 AM, Ian Woollard wrote:
And the file may be automagically closed as f goes out of scope.
But this is unreliable in Java/Self/Smalltalk- you don't know when the GC will get around to release it. I consider this to be a bug in these languages.
This is inly an issue if you rely on the garbage collector to close files (which most experienced programmers do not).
No, no. You should not assume that because that feature involves running the destructor in C++ - that the garbage collector should be involved.
My point is that a relatively trivial change to the language gets this capability without involving the GC at all.
In any event this is not a language issue, but a library issue.
No. This problem cannot be solved in libraries- only by having a diligent programmer call the close function in all cases at the right time. I prefer for the language specification to permit the libraries to guarantee that this be done automatically.
Is this extra complexity in the language? Yes.
On Sunday 27 June 2004 12:57, Ian Woollard wrote:
I think Self is guilty of oversimplification:
a) no privacy/security
Actually, Self 1.0 did implement privacy. Every slot could be declared as public or private. Children could still access the private slots in their parents, so it wasn't quite what you were asking for in another thread.
Another feature was parent priorities. You could mark some parents to be searched only when a selector was not found in higher priority ones. This combined with privacy to make it easy to create very confusing code. So in Self 3.0 these features were eliminated with the idea that privacy would be added back when a better solution could be found. The Us perspective thing was one exploration of a possible better solution.
For backwards compatibility, the privacy syntax is still accepted - it just is ignored by the virtual machine. You also have privacy annotations which have an effect on the GUI (the outliners show public slots on top and in bold face).
-- Jecel
I read the paper on perspectives. It has some interesting ideas, but from my perspective the concluding sections seem to say that it failed to solve the problems it set out to solve.
The use of perspectives to solve security was clearly not a solution as they worked through that one. The use of perspectives for creating private interfaces only worked in the absence of other perspectives, which seems to be true in the multi-user and multi-view cases as well. I would make the following changes to their approach and see if the result was an improvement:
1) Allow access to "context" provided by enclosing activations. 2) Allow fuzzy dispatch (you think you see one object, but there is a constellation of objects that cooperate to respond to the message. The parts of an object could be managed in a way similar to the layers in the paper, but would allow "perspective" to be taken from the context, or elsewhere, and would allow multiple active perspectives to influence the dispatch.
The suggestion that extending the language requires thought and experimentation I wholly agree with. Peer review of the proposed changes will also be important. The subjectivity idea has merit as a way to mange complexity. The COM idea that you must ask an identity for a perspective is similar, but would need a contextual frame of reference to match up.
Michael
On Jun 25, 2004, at 4:21 PM, Jecel Assumpcao Jr wrote:
On Friday 25 June 2004 17:12, Michael Latta wrote:
The current license basically says do what you want with it so long as we do not get blamed.
All versions that Sun has released had a similar license, though the early versions had the infamous "advertising clause" (which I don't mind at all).
The Self 1.X VMs were never released at all. I don't remember about 2.0, but at least I don't have a copy of it. And Self 4.1 was internal to Sun four about three years before being finally released under the current license.
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
This is actually how it is done in the programming environment (you set the slots in the parent as "copydown" and they show as pink in the outliner) even though saving a module as text creates some code to actually implement this imperatively.
- I am considering adding an annotation to a slot that will cause
it to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Ok, so you want to control "deep copies". It wasn't clear to me what you meant above by "cloning a slot". This is a very interesting issue. When you clone a morph, you certainly want to clone its submorphs too.
Let me know what you think, or if there are good reasons to leave it in code.
It is easy to come up with interesting features that make some example or other nicer, as David Ungar always says in his talks. The problem is that language complexity grows exponentially since each new feature interacts with all previous ones.
Both issues you mentioned can be viewed as particular instances of something larger - how can you organize stuff so sometimes you see a single object and sometimes you see smaller pieces which can be shared in interesting ways?
My first suggestion would be for you to read the Us paper (a subjective version of Self): http://citeseer.ist.psu.edu/smith96simple.html
This won't solve your problems, but should help you think in a more general way about them.
The "an object is really a tree of stuff and not just the root" thing was a major complication for me in parallelizing Self in tinySelf 1 and in my current work. Beyond subjects/viewpoints, there is an interesting idea I used in a language called NeoLogo which is "roles". I won't go into details here, but at first I thought that viewpoints was a good replacement for this, but now I see that though very similar they actually complement each other.
I would like one solution to all of these problems, and which made the resulting language even simpler. Never, ever forget "the power of simplicity".
Kyle Hayes wrote:
A little off track, but, I'd like to see the following in Self:
- a drastically simplified VM so that it can be more easily
ported. All ports but the Sparc and Mac are a little flaky in my experience (sometimes a lot flaky). Having a VM that is so difficult to port makes support and expansion of the Self "marketplace" more difficult.
A proper Self implementation should be in Self.
- move more of the optimization into Self rather than hardcoded in
the VM in C++.
See 1 ;-)
I like your ideas about the language! While I like Self's simplicity a lot, it is often nice to have reasonable short cuts for very common idioms like those you've covered above.
Unless you want to use it in a scripting language style (like 3.0 and earlier), Self is a language and an environment. We can have as many shortcuts as you want in the latter without having to complicate the former. The copydown thing is a good example.
-- Jecel
Yahoo! Groups Links
Michael Latta wrote:
I am considering creating a VM for Self with some language extensions
Me too. Except I have some cute probably non backward-compatible changes.
and would like comments:
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
- I am considering adding an annotation to a slot that will cause it
to be cloned when the object is cloned.
Yup *very* good move.
Other ideas I've had include:
a) *optional* typed function calls (i.e. functional programming, pretty much). This allows different functions to be implemented differently based on the 'class' of their callers. This reduces the complexity of function. The type can be a class, or transitive parent(s).
b) optional parameters
c) privacy (children can't see the parents private slots)
d) children inheritance (you can inherit off your children- and they supercede any slots in self or parents without error- also in that case they would have access to private slots in self, but not children)
e) optionally executed block slots in functions
Whys:
a) IMO it improves the code, used carefully; and *only* where appropriate.
b) I've used java, which doesn't have it, and I've looked at scripting languages that do have it; the scripting languages are easier to use, and remember the APIs for, and shorter code; the language improves
c) this is a sufficient condition for securing Self (currently it has *no* security!)
d) this is spectacularly useful for some things, noteably implementing state machines; I'm *very* sure it's incredibly useful for some other things too.
e) simplified syntax of ifTrue: statements, shortcircuiting and: or: statements etc.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Let me know what you think, or if there are good reasons to leave it in code.
Michael
self-interest@lists.selflanguage.org
-
Ian Woollard -
Ian Woollard -
Jecel Assumpcao Jr -
Kyle Hayes -
Michael Feathers -
Michael Latta