I hope to find more time now, but I fear that it will be another month or so till I can put some real time into this again.
Fantastic, thank you Marcus! I had asked about this a couple of years ago, and Tim Rowledge indicated that his 'New CompiledMethod' stuff was planned to be part of it.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-February/035684....
I sincerely hope this is still this case as it breaks wide open two great things; easier serialization/materialization of CompiledMethods and, hopefully, faster reflection.
Is the new CompiledMethod planned?
Thanks..
On Feb 3, 2004, at 2:42 PM, Chris Muller wrote:
Fantastic, thank you Marcus! I had asked about this a couple of years ago, and Tim Rowledge indicated that his 'New CompiledMethod' stuff was planned to be part of it.
Ah. Now that is probably a different kettle of coloured horses. Anthony included the redefined CM stuff in his initial work BUT in order to make Closures work in a more 'ordinary' VM environment he reworked things to not rely upon it. The cost of the new format is an image backwards compatibility break, and peple have been very leery of that.
tim
Am 04.02.2004 um 02:30 schrieb Timothy Rowledge:
On Feb 3, 2004, at 2:42 PM, Chris Muller wrote:
Fantastic, thank you Marcus! I had asked about this a couple of years ago, and Tim Rowledge indicated that his 'New CompiledMethod' stuff was planned to be part of it.
Ah. Now that is probably a different kettle of coloured horses. Anthony included the redefined CM stuff in his initial work BUT in order to make Closures work in a more 'ordinary' VM environment he reworked things to not rely upon it. The cost of the new format is an image backwards compatibility break, and peple have been very leery of that.
Yes... at some point we really should think about making an incompatible release and clean this (and other stuff) up.
But, as Tim said, this won't happen as part of the Closure stuff: This does not rely on any VM changes besides the new primitives added in 3.6.
Marcus
-- Marcus Denker marcus@ira.uka.de
Hi Doug and all
Here is a changeset that fixes some missing triggers for the SystemChangeNotification framework by cleaning up the ClassOrganization hierarchy. It also fixes some other issues (see below). Note that the changeset is manually edited in order to make it file in correctly.
Nathanael
"Change Set: KCP-0220-ClassOrganizerFixAndCleanup Date: 6 April 2004 Author: Nathanael Schaerli
This changeset cleans up the ClassOrganizer hierarchy and fixes some bugs in the SystemNotification framework. Furthermore, it fixes some other bugs that got appearent while I was working on this cleanup. In detail:
- Cleans up the ClassOrganizer hierarchy. This was necessary because the old hierarchy was conceptually wrong and made it therefore unnecessarily hard to extend it. - Makes sure that changes to the class organizer always trigger the corresponding system change notifier event. (This was not the case so far). - All the system change notification triggers are in the kernel where they actually happen. In particular, I removed all the triggers in the class Browser. - Removes a few minor problems with nil values in the SystemChangeNotification framework. - Removes a bug when using drag and drop between classes without having message categories selected.
IMPORTANT: - This changeset has been modified by hand in order to make it file in properly. - Close all the browser windows before filing this changeset in."
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
I will send an email with the right version as soon as I'm done with it...
Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:45 To: 'The general-purpose Squeak developers list' Subject: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Hi Doug and all
Here is a changeset that fixes some missing triggers for the SystemChangeNotification framework by cleaning up the ClassOrganization hierarchy. It also fixes some other issues (see below). Note that the changeset is manually edited in order to make it file in correctly.
Nathanael
"Change Set: KCP-0220-ClassOrganizerFixAndCleanup Date: 6 April 2004 Author: Nathanael Schaerli
This changeset cleans up the ClassOrganizer hierarchy and fixes some bugs in the SystemNotification framework. Furthermore, it fixes some other bugs that got appearent while I was working on this cleanup. In detail:
- Cleans up the ClassOrganizer hierarchy. This was necessary
because the old hierarchy was conceptually wrong and made it therefore unnecessarily hard to extend it.
- Makes sure that changes to the class organizer always
trigger the corresponding system change notifier event. (This was not the case so far).
- All the system change notification triggers are in the
kernel where they actually happen. In particular, I removed all the triggers in the class Browser.
- Removes a few minor problems with nil values in the
SystemChangeNotification framework.
- Removes a bug when using drag and drop between classes
without having message categories selected.
IMPORTANT:
- This changeset has been modified by hand in order to make
it file in properly.
- Close all the browser windows before filing this changeset in."
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
Ok. Here is the right version of the changeset.
Cheers, Nathanael
PS: Don't forget to close the close all the browsers before filing it in.
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:56 To: 'The general-purpose Squeak developers list' Subject: RE: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
I will send an email with the right version as soon as I'm done with it...
Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:45 To: 'The general-purpose Squeak developers list' Subject: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Hi Doug and all
Here is a changeset that fixes some missing triggers for the SystemChangeNotification framework by cleaning up the ClassOrganization hierarchy. It also fixes some other issues (see below). Note that the changeset is manually edited in order to make it file in correctly.
Nathanael
"Change Set: KCP-0220-ClassOrganizerFixAndCleanup Date: 6 April 2004 Author: Nathanael Schaerli
This changeset cleans up the ClassOrganizer hierarchy and fixes some bugs in the SystemNotification framework. Furthermore, it fixes some other bugs that got appearent while I was working on this cleanup. In detail:
- Cleans up the ClassOrganizer hierarchy. This was necessary
because the old hierarchy was conceptually wrong and made it therefore unnecessarily hard to extend it.
- Makes sure that changes to the class organizer always
trigger the corresponding system change notifier event. (This was not the case so far).
- All the system change notification triggers are in the
kernel where they actually happen. In particular, I removed all the triggers in the class Browser.
- Removes a few minor problems with nil values in the
SystemChangeNotification framework.
- Removes a bug when using drag and drop between classes
without having message categories selected.
IMPORTANT:
- This changeset has been modified by hand in order to make
it file in properly.
- Close all the browser windows before filing this changeset in."
Nathanael Schärli wrote:
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
Ok. Here is the right version of the changeset.
Cheers, Nathanael
PS: Don't forget to close the close all the browsers before filing it in.
Yes, this seems to work as long as I don't have any browser windows open. :-) Actually, maybe a do-it should be added to the preamble which closes all open browser windows, because this will probably bite a lot of people. (We could even have an inform: window which warns about this ahead of time.)
As to whether this "fix" should go in 3.7beta or wait until 3.8alpha, that's hard to say. Possibly it could go in 3.7beta if we made it close browser windows, etc. It seems like a big enough change that we might want to wait until 3.8alpha though, if it's not too urgent. On the plus side, Dan has been talking about an accelerated schedule for 3.8 (June/July for 3.8final), so if it were to wait for 3.8, you wouldn't have to wait *too* long.
- Doug
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:56 To: 'The general-purpose Squeak developers list' Subject: RE: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
I will send an email with the right version as soon as I'm done with it...
Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:45 To: 'The general-purpose Squeak developers list' Subject: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Hi Doug and all
Here is a changeset that fixes some missing triggers for the SystemChangeNotification framework by cleaning up the ClassOrganization hierarchy. It also fixes some other issues (see below). Note that the changeset is manually edited in order to make it file in correctly.
Nathanael
"Change Set: KCP-0220-ClassOrganizerFixAndCleanup Date: 6 April 2004 Author: Nathanael Schaerli
This changeset cleans up the ClassOrganizer hierarchy and fixes some bugs in the SystemNotification framework. Furthermore, it fixes some other bugs that got appearent while I was working on this cleanup. In detail:
- Cleans up the ClassOrganizer hierarchy. This was necessary
because the old hierarchy was conceptually wrong and made it therefore unnecessarily hard to extend it.
- Makes sure that changes to the class organizer always
trigger the corresponding system change notifier event. (This was not the case so far).
- All the system change notification triggers are in the
kernel where they actually happen. In particular, I removed all the triggers in the class Browser.
- Removes a few minor problems with nil values in the
SystemChangeNotification framework.
- Removes a bug when using drag and drop between classes
without having message categories selected.
IMPORTANT:
- This changeset has been modified by hand in order to make
it file in properly.
- Close all the browser windows before filing this changeset in."
This body part will be downloaded on demand.
Hi Doug,
Yes, this seems to work as long as I don't have any browser windows open. :-) Actually, maybe a do-it should be added to the preamble which closes all open browser windows, because this will probably bite a lot of people. (We could even have an inform: window which warns about this ahead of time.)
That is a good idea. I modfified my changeset accordingly and attached it to this email.
As to whether this "fix" should go in 3.7beta or wait until 3.8alpha, that's hard to say. Possibly it could go in 3.7beta if we made it close browser windows, etc. It seems like a big enough change that we might want to wait until 3.8alpha though, if it's not too urgent. On the plus side, Dan has been talking about an accelerated schedule for 3.8 (June/July for 3.8final), so if it were to wait for 3.8, you wouldn't have to wait *too* long.
I'm torn as well. On one hand, it would be good to have it in 3.7beta because it fixes some bugs in the SystemChangeNotification framework and with the drag'n'drop. However, these are all minor things and most programmers will never run into them.
Also, this changeset is quite big and so there is definitely a potential that it breaks some other things. (Well, I have tested it quite extensively, but I can't give a guarantee). Therefore, I can totally understand that it is too big of a risk to introduce it so late in the beta cycle.
For me, the most important thing is that this changeset gets incoprorated before the code gets "out of date" (i.e., there is new code modifying the same methods that are part of this changeset). But since this changeset mainly affects kernel methods, it should be fine if we wait until 3.8alpha.
Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Doug Way Sent: Mittwoch, 7. April 2004 22:11 To: The general-purpose Squeak developers list Subject: Re: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Nathanael Schärli wrote:
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
Ok. Here is the right version of the changeset.
Cheers, Nathanael
PS: Don't forget to close the close all the browsers before
filing it
in.
Yes, this seems to work as long as I don't have any browser windows open. :-) Actually, maybe a do-it should be added to the preamble which closes all open browser windows, because this will probably bite a lot of people. (We could even have an inform: window which warns about this ahead of time.)
As to whether this "fix" should go in 3.7beta or wait until 3.8alpha, that's hard to say. Possibly it could go in 3.7beta if we made it close browser windows, etc. It seems like a big enough change that we might want to wait until 3.8alpha though, if it's not too urgent. On the plus side, Dan has been talking about an accelerated schedule for 3.8 (June/July for 3.8final), so if it were to wait for 3.8, you wouldn't have to wait *too* long.
- Doug
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:56 To: 'The general-purpose Squeak developers list' Subject: RE: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Oops, I just noticed that I made a mistake when I manually edited the changeset (I accidentally used data from an older changeset).
I will send an email with the right version as soon as I'm done with it...
Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nathanael Schärli Sent: Mittwoch, 7. April 2004 15:45 To: 'The general-purpose Squeak developers list' Subject: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs
Hi Doug and all
Here is a changeset that fixes some missing triggers for the SystemChangeNotification framework by cleaning up the ClassOrganization hierarchy. It also fixes some other issues (see below). Note that the changeset is manually edited in
order to make
it file in correctly.
Nathanael
"Change Set: KCP-0220-ClassOrganizerFixAndCleanup Date: 6 April 2004 Author: Nathanael Schaerli
This changeset cleans up the ClassOrganizer hierarchy and
fixes some
bugs in the SystemNotification framework. Furthermore, it
fixes some
other bugs that got appearent while I was working on this
cleanup. In
detail:
- Cleans up the ClassOrganizer hierarchy. This was
necessary because
the old hierarchy was conceptually wrong and made it therefore unnecessarily hard to extend it.
- Makes sure that changes to the class organizer always
trigger the corresponding system change notifier event. (This was not the case so far).
- All the system change notification triggers are in the
kernel where they actually happen. In particular, I removed all the triggers in the class Browser.
- Removes a few minor problems with nil values in the
SystemChangeNotification framework.
- Removes a bug when using drag and drop between classes
without having message categories selected.
IMPORTANT:
- This changeset has been modified by hand in order to make
it file in properly.
- Close all the browser windows before filing this changeset in."
--
This body part will be downloaded on demand.
Doug,
When playing with and testing the "KCP-0220-ClassOrganizerFixAndCleanup" changeset, I found that recategorization of methods is not consistently logged to the active changeset. In fact, recategorization is only logged if it is done using the context menu in the protocol pane (e.g., the 'recategorize' command), but it is not logged if it is done by simply dragging methods into new categories or by choosing the 'change category' command in the context menu of the method pane.
As I wanted to make sure that this is not something that was introduced by the SystemChangeNotification framework, I went back to Squeak 3.5 and I encountered the same inconsistent behavior there. I don't know how others feel about this, but to me this really is a bug because I would expect recategorizations to be logged in the changeset no matter what recategorization command I use.
Fortunately, the SystemChangeNotifier framework allows us to fix this quite easily because changing the category of a method triggers an event already and so we just need to make sure that the changeset also reacts to this event. I have done this in the attached file-out.
Nathanael
Nathanael Schärli wrote:
Doug,
When playing with and testing the "KCP-0220-ClassOrganizerFixAndCleanup" changeset, I found that recategorization of methods is not consistently logged to the active changeset. In fact, recategorization is only logged if it is done using the context menu in the protocol pane (e.g., the 'recategorize' command), but it is not logged if it is done by simply dragging methods into new categories or by choosing the 'change category' command in the context menu of the method pane.
As I wanted to make sure that this is not something that was introduced by the SystemChangeNotification framework, I went back to Squeak 3.5 and I encountered the same inconsistent behavior there. I don't know how others feel about this, but to me this really is a bug because I would expect recategorizations to be logged in the changeset no matter what recategorization command I use.
Fortunately, the SystemChangeNotifier framework allows us to fix this quite easily because changing the category of a method triggers an event already and so we just need to make sure that the changeset also reacts to this event. I have done this in the attached file-out.
I agree that it definitely looks like a bug and your fix looks good. Although I notice that your fix doesn't cover the case of a new method category being added. :-) If you submit another fix for this, go ahead and post under a new subject, since it is separate from KCP220.
- Doug
Hi
I have now finaly gotten around to fix some bugs in the Monitor implementation that I provided a while ago (see the attached changeset). In particular, the changeset fixes the following two issues:
- There was an obvious conceptual problem regarding the reentrant semantics of the monitor. - There was a more subtle race-condition in the method Monitor>>exitAndWaitInQueue:maxMilliseconds:.
Since the first problem is quite severe, I think that it would be good if this could go into the image soon.
Nathanael
On Thursday, April 8, 2004, at 06:31 AM, Nathanael Schärli wrote:
As to whether this "fix" should go in 3.7beta or wait until 3.8alpha, that's hard to say. Possibly it could go in 3.7beta if we made it close browser windows, etc. It seems like a big enough change that we might want to wait until 3.8alpha though, if it's not too urgent. On the plus side, Dan has been talking about an accelerated schedule for 3.8 (June/July for 3.8final), so if it were to wait for 3.8, you wouldn't have to wait *too* long.
I'm torn as well. On one hand, it would be good to have it in 3.7beta because it fixes some bugs in the SystemChangeNotification framework and with the drag'n'drop. However, these are all minor things and most programmers will never run into them.
Also, this changeset is quite big and so there is definitely a potential that it breaks some other things. (Well, I have tested it quite extensively, but I can't give a guarantee). Therefore, I can totally understand that it is too big of a risk to introduce it so late in the beta cycle.
I think we should wait for 3.8alpha then.
For me, the most important thing is that this changeset gets incoprorated before the code gets "out of date" (i.e., there is new code modifying the same methods that are part of this changeset). But since this changeset mainly affects kernel methods, it should be fine if we wait until 3.8alpha.
Right, I don't think there will be a problem with it getting "out of date". If we approve this and also mark it "for 3.8alpha", I can plan on incorporating it right at the beginning of 3.8alpha. The only other big change planned for the very beginning of 3.8alpha is the i18n stuff, but even though that's a big change, I think there will probably be no overlap with your changes.
- Doug
I would prefer to see this fix in because we still have time and this way this will be fixed in 3.7
Stef
On Saturday, April 10, 2004, at 11:06 AM, stéphane ducasse wrote:
I would prefer to see this fix in because we still have time and this way this will be fixed in 3.7
(Approving this one on squeak-dev.)
Stephane and I discussed this and these fixes are important for the KCP group to have in 3.7, and they've been tested extensively by that group. So since we still have ~4 weeks of beta left, we will try these in the next batch of updates, and if there are major problems, we can back them out before we go to gamma.
- Doug
Hi Doug, Stef, and Marcus
Doug wrote:
I agree that it definitely looks like a bug and your fix looks good. Although I notice that your fix doesn't cover the case of a new method category being added. :-) If you submit another fix for this, go ahead and post under a new subject, since it is separate from KCP220.
It is true that the little fix I posted does not cover the case when method categories are added. However, this is precisely what is fixed by the changeset KCP220! This changeset addresses the fact that there were many missing notifications in the ClassOrganizer (for example when categories are added/removed).
The reason for this was the fact that the class hierarchy of ClassOrganizer was conceptually wrong and it was therefore not possible to add these notifications without breaking other code. In KCP220, all this is fixed. This means that ClassOrganizer now issues all the necessary notifications when the class organization is changed.
I would prefer to see this fix in because we still have time and this way this will be fixed in 3.7
I have attached an updated version of the KCP220 changeset to this email. The main differences to the previous changeset is that it also includes the little bugfix I sent on April 8, and that it fixes a little typo. I have now extensively used this changeset for a few days where I recompiled the whole image many times and played a lot with the class organization.
Of course, I can still not rule out that there is a small bug somewhere in this changeset. But I'm almost 100% certain that this changeset fixes much more bugs than it introduces. So, if Marcus can review this changeset in time and thinks that it is fine, I suggest to put it into v3.8. This would be good because it would mean that the SystemChangeNotification framwork would actually be working the way it is supposed to.
What do you guys think? Nathanael
You meant 3.7 :). Doug mentioned that it will be for 3.7. I think that this is important that the system notification contains as few bugs as possible. Because people working with non-alpha version should get something stable
On 15 avr. 04, at 16:01, Nathanael Schärli wrote:
Hi Doug, Stef, and Marcus
Doug wrote:
I agree that it definitely looks like a bug and your fix looks good. Although I notice that your fix doesn't cover the case of a new method category being added. :-) If you submit another fix for this, go ahead and post under a new subject, since it is separate from KCP220.
It is true that the little fix I posted does not cover the case when method categories are added. However, this is precisely what is fixed by the changeset KCP220! This changeset addresses the fact that there were many missing notifications in the ClassOrganizer (for example when categories are added/removed).
The reason for this was the fact that the class hierarchy of ClassOrganizer was conceptually wrong and it was therefore not possible to add these notifications without breaking other code. In KCP220, all this is fixed. This means that ClassOrganizer now issues all the necessary notifications when the class organization is changed.
I would prefer to see this fix in because we still have time and this way this will be fixed in 3.7
I have attached an updated version of the KCP220 changeset to this email. The main differences to the previous changeset is that it also includes the little bugfix I sent on April 8, and that it fixes a little typo. I have now extensively used this changeset for a few days where I recompiled the whole image many times and played a lot with the class organization.
Of course, I can still not rule out that there is a small bug somewhere in this changeset. But I'm almost 100% certain that this changeset fixes much more bugs than it introduces. So, if Marcus can review this changeset in time and thinks that it is fine, I suggest to put it into v3.8. This would be good because it would mean that the SystemChangeNotification framwork would actually be working the way it is supposed to.
What do you guys think? Nathanael <KCP-0220-ClassOrganizerFixAndCleanup.14.cs>
Nathanael Schärli wrote:
Hi Doug, Stef, and Marcus
Doug wrote:
I agree that it definitely looks like a bug and your fix looks good. Although I notice that your fix doesn't cover the case of a new method category being added. :-) If you submit another fix for this, go ahead and post under a new subject, since it is separate from KCP220.
It is true that the little fix I posted does not cover the case when method categories are added. However, this is precisely what is fixed by the changeset KCP220! This changeset addresses the fact that there were many missing notifications in the ClassOrganizer (for example when categories are added/removed).
Ah, cool, I didn't test that with KCP220. So then KCP220 definitely fixes some things. ;-)
I tested that with your fixes, various category modifications (adding new categories, changing categories, etc.) are now properly tracked by the current changeset. Approved for 3.7beta.
- Doug
I tested that with your fixes, various category modifications (adding new categories, changing categories, etc.) are now properly tracked by the current changeset. Approved for 3.7beta.
That's great!
Thanks very much. Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Doug Way Sent: Donnerstag, 15. April 2004 18:44 To: The general-purpose Squeak developers list Subject: Re: [KCP][FIX] KCP-0220-ClassOrganizerFixAndCleanup.8.cs ([et][approved][for 3.7beta] use Nathanael's new .14.cs)
Nathanael Schärli wrote:
Hi Doug, Stef, and Marcus
Doug wrote:
I agree that it definitely looks like a bug and your fix looks good. Although I notice that your fix doesn't cover the case of a new method category being added. :-) If you submit another fix for this, go ahead and post under a new subject, since it is separate from KCP220.
It is true that the little fix I posted does not cover the case when method categories are added. However, this is precisely what
is fixed
by the changeset KCP220! This changeset addresses the fact
that there
were many missing notifications in the ClassOrganizer (for
example when
categories are added/removed).
Ah, cool, I didn't test that with KCP220. So then KCP220 definitely fixes some things. ;-)
I tested that with your fixes, various category modifications (adding new categories, changing categories, etc.) are now properly tracked by the current changeset. Approved for 3.7beta.
- Doug
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Doug Way -
Marcus Denker -
Nathanael Schärli -
stéphane ducasse -
Timothy Rowledge