How to beat Andreas at his own game
Locked
How to beat Andreas at his own game
 
|
Hi all, With all the sound and fury we've had lately, I thought I'd make a suggestion for Keith, or anyone else who isn't happy with the way the Squeak community has been evolving lately. If you think about it, the Board really has power over one thing: the name "Squeak." Even that's mostly a social convention than anything - control of the squeak-related domain names and the moral authority that comes from having been elected by the community. All Andreas did was say, "hey everybody, I've set up a repository that you can commit to, and I plan to follow process X for releasing images based on what you submit." If you don't like process X, the way to persuade the community not to follow Andreas is to provide an alternative. Keith, it sounds to me like you've got clear ideas about what a better alternative would be, and have the tools realize that vision. To that end, I suggest the following steps: * Pick a name for your project. "StableSqueak" has been used already, but what about "SolidSqueak?" From a marketing perspective, you want to emphasize your commitment to compatibility. * Create a web site. No need for anything fancy, just put a page up at solidsqueak.org that explains the process you espouse. You've posted numerous explanations to this list, so it should be trivial to pull together something coherent. * Provide some infrastructure. This depends a bit on your process, but from what I understand you'll want an issue tracker. Maybe the existing Mantis database will serve, but you could create your own. Maybe you want a mailing list. All these things can be had for free from various places - lots of folks have found Google Code projects to work out well for Smalltalk, even though we don't really need their source-code repository. * Make releases. If I understand correctly, there's already a lot of work done, and Bob can automatically build images based on various versions of Squeak and incorporating a whole raft of fixes from Mantis. That's a great place to start. * Eat the dog food. Make your own work available through this process, both as an example of how it should be done and to work out the kinks. * Talk it up. When you produce new release images, post announcements on this list, make blog posts touting the fixes and new features that are included. Announce improvements to the process too - new releases of Bob or Sake, new integration proceedures, new base images supported etc. * Provide support. As folks become interested in what you're doing, they'll want to try things out. Answer questions about how to participate, encourage experimentation and be receptive to new ideas. Above all, try to help people use your system to achieve their own goals. After that they'll be happy to contribute back to the community you've created. If you think this sounds like a lot of work, well, yeah, it is. Leadership and community-building *is* a lot of work. Andreas has demonstrated that he's willing to work hard at it. The Seaside guys are doing that work, and so is the Pharo team. You've already put a lot of work into building out your tool set and articulating your vision, so you've obviously got what it takes. As the benefits of your process start to become clear, more and more of the community will follow your lead, and the trunk will languish, just as other failed initiatives have done over the years. You may find yourself elected to the board, and SolidSqueak folded back into Squeak proper, or simply that SolidSqueak is so successful that you don't really care what goes on with the board and their moribund process. Either way, you win. Colin |
Re: [squeak-dev] How to beat Andreas at his own game
|
|
On Mon, 25 Jan 2010 01:16:29 -0300, Colin Putney <[hidden email]>
wrote: > If you don't like process X, the way to persuade the community not to > follow Andreas is to provide an alternative. Keith, it sounds to me like > you've got clear ideas about what a better alternative would be, and > have the tools realize that vision I think this is the way to go! Clear ideas! no aggravations! -- Saludos Gonzalo Romano |
|
|
Gonzalo, I think you missed the background of this conversation. I already did provide an alternative. I wrote a proposal, I put it to the board, the board approved it, and I worked on it for 3 years. Then without any discussion or warning, Andreas overruled, (something which, if the board had a constitution would surely be unconstitutional) and in doing so scuppered the process we had, causing a lot of bad feeling. The last two times this happened on this scale the consequences were off the scale, and this should not be accepted ever. The bob process has already been undermined, by "trunk" as things whose integrity the previous process depended on have been re-directed and diluted, because everyone is thinking in terms of evolving moving targets rather than having regular actual tested releases, with a migration path between them. There is no point in doing any further work on this, if that work becomes a competition. Competitions have losers. Simply put, we looked at the problem of forking, and we formulated an approach that "might" just help. We didn't know if it would work, but without it squeak as a viable movement is dead. It will degenerate into nothing more than a bunch of isolated lumps of code, with a couple of programmers hacking away at each one. The answer is not to develop another fork. The answer fundamentally requires every person's contribution to be valued highly and harnessed, through being able to support the notion of multiple lines of innovation that cross fertilise. "trunk" by being one line of innovation, and by throwing away 3 years of work shakes these principles to their core. Until the bad feeling is resolved, and the board gets a constitution the community is unable to function, and has shown that it is unable to function. Indeed it should be considered emotionally dangerous to participate in. Squeak currently is just a lump of code in the hands of one or two gifted programmers, and they will bung us a release over the fence every now and then. Every goal that has been promised in the past few years, kernel image, build your own squeak, atomic loading, has failed to happen. Because these visions have all required tools and innovation of the process to facilitate them. If you develop those tools and innovate the process, you get overruled by people who just want a new fork. Pharo, showed us how it shouldn't be done, and now we are just copying them. regards Keith |
|
|
In reply to this post by Colin Putney
That is not all he did. He conceptually re-directed the way Mantis was used. Keith |
|
|
In reply to this post by Colin Putney
> If you don't like process X, the way to persuade the community not > to follow Andreas is to provide an alternative. Keith, it sounds to > me like you've got clear ideas about what a better alternative would > be, and have the tools realize that vision. To that end, I suggest > the following steps: My time, and availability to do any of that ended when Andreas did what he did. This is the reason for having a protocol, a plan and a board in the first place. If the value of having the board approve a proposal is zero, then ok, but don't move the goal posts. Keith |
Re: [squeak-dev] How to beat Andreas at his own game
|
|
On 2010-01-25, at 8:37 AM, keith wrote: > >> If you don't like process X, the way to persuade the community not to follow Andreas is to provide an alternative. Keith, it sounds to me like you've got clear ideas about what a better alternative would be, and have the tools realize that vision. To that end, I suggest the following steps: > > My time, and availability to do any of that ended when Andreas did what he did. A shame. I had hoped that your decision to reengage the community this way was a sign that you were ready to pursue your vision despite the setback you've suffered. If that's not your purpose... um, why all the fuss? Colin |
RemoteTask for poor man's multiprocessing with Squeak
|
|
I was driving home from Peoria today, listening to podcasts on the car radio,
and here was this Industry Misinterpretations podcast about taking advantage of multi-core CPUs by spawning worker images: http://www.cincomsmalltalk.com/audio/2009/industry_misinterpretations163.mp3 I realized that this was probably the same thing I was doing with Squeak a while back using ReferenceStreams and CommandShell/OSProcess, but I don't have a multi-core CPU to test it, so I don't know if it actually produces any performance benefits. If someone has a multi-core PC running some flavor of Unix/Linux/OS X, I'd be interested to know if this provides any actual performance benefit. The multi-processing version of the test is slower on my single CPU system (as expected), but would presumably run faster if executed on a quad-core CPU. How to test it: 1) Load OSProcess and CommandShell from SqueakSource (latest versions, updated today) 2) Try this: "Make a large interval of large integers, broken into 3 chunks with elements to be tested for #isPrime." oc := OrderedCollection new. "collection of three intervals of large integers" taskCount := 3. start := 100000000000000000000000000000. "a big number" chunkSize := 2000. "integers per interval, to be tested in remote task" end := chunkSize * (taskCount - 1) + start. (start to: end by: chunkSize) do: [:e | oc add: (e to: e + chunkSize - 1)]. "Run tests in local image, processing everything serially in this Squeak image. For each interval, find all the prime elements and answer them as strings. Note: Passing large integers through a ReferenceStream seems to be buggy, hence the conversion to strings." Time millisecondsToRun: [ oc collect: [:e | e select: [:f | f isPrime] thenCollect: [:s | s asString]]] "==> 55499" "Split the work into tasks and assign the tasks to RemoteTask worker images. For each interval, find all the prime elements and answer them as strings. Processing is parallel, with each interval evaluated in a separate RemoteTask, and the results collected in this image after all RemoteTask processing is complete." Time millisecondsToRun: [ tasks := oc collect: [:e | RemoteTask start: [e select: [:f | f isPrime] thenCollect: [:s | s asString]]]. tasks collect: [:t | t result]] "==> 79280" The hope would be that the second test using RemoteTask would run faster than the first on a multi-core CPU, by virtue of using three worker images to run the three tasks more or less in parallel. Dave |
|
|
In reply to this post by Colin Putney
My decision to re-engage, was out of the realisation that, I don't have anywhere to go at all with my code base much beyond a year hence, because when I tried pharo 1.0 I didn't like it at all. I even thought I might humble myself and try Metacello, to see if it really was offering more than S/P, and I don't think it fundamentally is. In discussions in irc, some were asking about getting MC up and running in Cuis. So then I tried Cuis and I did like it as far as it goes, which isn't yet far enough to run MC let alone seaside or pier. So, as it turns out this is where the Cuis discussions are, and I signed back up. If Cuis had a separate mailing list, I would not have shown my face here again. I think Cuis has potential, since all the things that interest me (apart from adopting a Logging API to replace Transcript show: , and replacing FileDirectory) are external to the kernel of Cuis. Juan has stated he doesnt care about anything other than having a good kernel. So that is promising, no board to mess things up with politics. In Cuis-land a lot of the contributions that are being made to "trunk" would be in external packages anyway, including changes to morphic. This had been what we were aiming to achieve with putting AtomicLoading as top priority, to be able to make larger subsystems like Morphic externally manageable and loadable, so as to enable changes by revolution rather than evolution. I do think cuis + atomic loading would be cool to have. On my return, I also discovered that clearly my absence has not been of any concern. Since the board had not done anything about the "terms of reference" request I made 5 months ago, this is why I got pissed off on the day after the board meeting and had a proper rant. Apparently the board doesn't care how they treat people, and the board now represents the squeak community, until that changes, I see no reason to participate with squeak, its no fun. Overall, since I have recently learned how rape and abuse trauma may be cured, I have developed a 5 year therapy programme for resolving Multiple Personality Disorder, which I am being asked to teach, and also a cure for tourettes and dispraxia is possibly close behind, my time really would be better spent on more important things; video documenting case studies, performing research and actually helping people. Unfortunately this doesn't pay the bills (it is unethical to charge), if anyone would like to sponsor me to help people instead, I would happily drop coding and leave you all alone for good. regards Keith |
Re: [squeak-dev] RemoteTask for poor man's multiprocessing with Squeak
|
|
In reply to this post by David T. Lewis
David,
I took a quick look on a quad core 2 box running Fedora Core 10 and the Squeak 3.7-7 VM and 3.10.2 image. It seems to lock up on "RemoteTask result". Running the Tests-OSProcess does indeed cause one failure in #testCooperatingProcesses04 where the tests for version 43 were all green. Running Tests-CommandShell locks up after 71 tests with one failure (version 4.3 had all green tests after I created a /usr/bin/vi file). -- Jecel |
Re: [squeak-dev] RemoteTask for poor man's multiprocessing with Squeak
|
|
In reply to this post by David T. Lewis
On Tue, Jan 26, 2010 at 08:19:14PM -0200, Jecel Assumpcao Jr wrote:
> David, > > I took a quick look on a quad core 2 box running Fedora Core 10 and the > Squeak 3.7-7 VM and 3.10.2 image. It seems to lock up on "RemoteTask > result". Running the Tests-OSProcess does indeed cause one failure in > #testCooperatingProcesses04 where the tests for version 43 were all > green. Running Tests-CommandShell locks up after 71 tests with one > failure (version 4.3 had all green tests after I created a /usr/bin/vi > file). Jecel, Thanks very much for trying this and for the feedback. I guess it's about time I replaced my ten year old computer so I can test this myself. I am guessing that a possible culprit is signal delivery for the SIGCHLD handler, I wonder if that might behave a little differently on a multi-core machine ... Thanks again, Dave |
Re: [squeak-dev] RemoteTask for poor man's multiprocessing with Squeak
|
|
I tried it on my dual core intel mac (older 32 bit one), and the VM (Squeak4.3.1 Beta1U) crashed. So I loaded the OSProcess tests into an up to date trunk image, and running the tests in UnixProcessTestCase crashed the VM. This also happens in the Pharo Dev 1.0 RC2.
Mike Mike Hales Engineering Manager KnowledgeScape www.kscape.com On Tue, Jan 26, 2010 at 3:35 PM, David T. Lewis <[hidden email]> wrote:
|
Re: [squeak-dev] RemoteTask for poor man's multiprocessing with Squeak
|
|
On Tue, Jan 26, 2010 at 06:32:43PM -0700, Mike Hales wrote:
> > On Tue, Jan 26, 2010 at 3:35 PM, David T. Lewis <[hidden email]> wrote: > > > On Tue, Jan 26, 2010 at 08:19:14PM -0200, Jecel Assumpcao Jr wrote: > > > David, > > > > > > I took a quick look on a quad core 2 box running Fedora Core 10 and the > > > Squeak 3.7-7 VM and 3.10.2 image. It seems to lock up on "RemoteTask > > > result". Running the Tests-OSProcess does indeed cause one failure in > > > #testCooperatingProcesses04 where the tests for version 43 were all > > > green. Running Tests-CommandShell locks up after 71 tests with one > > > failure (version 4.3 had all green tests after I created a /usr/bin/vi > > > file). > > > > Jecel, > > > > Thanks very much for trying this and for the feedback. I guess it's > > about time I replaced my ten year old computer so I can test this myself. > > I am guessing that a possible culprit is signal delivery for the SIGCHLD > > handler, I wonder if that might behave a little differently on a > > multi-core machine ... > > > > Thanks again, > > > > Dave > > I tried it on my dual core intel mac (older 32 bit one), and the VM > (Squeak4.3.1 Beta1U) crashed. So I loaded the OSProcess tests into an up to > date trunk image, and running the tests in UnixProcessTestCase crashed the > VM. This also happens in the Pharo Dev 1.0 RC2. Mike, Urk. I guess I aught to get a Mac Mini one of these days too so I can try things on Mac. I'm not sure how solid this is on Pharo by the way; I know that the CommandShell tests (which do a lot of process scheduling) have problems, and I suspect that there are some things in the OSProcess / CommandShell tests that are timing dependent and for some reason get flaky on the Pharo images. Sorry I can't be more specific. Obviously crashing the VM is not acceptable regardless of what the application is doing, so something is badly wrong here. Thanks for trying this and also for the feedback. Dave |
|
|
On Wed, Jan 27, David T. Lewis wrote:
>> I tried it on my dual core intel mac (older 32 bit one), and the VM >> (Squeak4.3.1 Beta1U) crashed. So I loaded the OSProcess tests into an up to >> date trunk image, and running the tests in UnixProcessTestCase crashed the >> VM. This also happens in the Pharo Dev 1.0 RC2. > > Obviously crashing the VM is not acceptable regardless of what the application > is doing, so something is badly wrong here. As far as I can tell, the Cocoa and Carbon VMs do not ship with pre-built plugins necessary for OSProcess. I naively tried David's test with a couple and crashed the VM each time. Mike, did you build your own OSProcess and AIO plugins? (I tried one of Ian Piumarta's Unix VMs for Darwin, because it came with pre-built plugins, and it didn't crash the VM, but several of the tests in Test-OSProcess failed. I chose not to document it or pursue it further, partly because Mac OS X 10.4 is not supported by recent VMs.) David: which image and VM did you use? |
Re: RemoteTask for poor man's multiprocessing with Squeak
|
|
I did not build my own. I did look in the vm app resources, and there is a UnixOSProcessPlugin.bundle. There is definately not an AIO plugin though, and I did get a pop-up saying AIO was not found, using polling instead.
Mike Mike Hales Engineering Manager KnowledgeScape www.kscape.com On Thu, Jan 28, 2010 at 9:10 AM, David Corking <[hidden email]> wrote:
|
Re: RemoteTask for poor man's multiprocessing with Squeak
|
|
In reply to this post by dcorking
On Thu, Jan 28, 2010 at 04:10:55PM +0000, David Corking wrote:
> On Wed, Jan 27, David T. Lewis wrote: > > >> I tried it on my dual core intel mac (older 32 bit one), and the VM > >> (Squeak4.3.1 Beta1U) crashed. So I loaded the OSProcess tests into an up to > >> date trunk image, and running the tests in UnixProcessTestCase crashed the > >> VM. This also happens in the Pharo Dev 1.0 RC2. > > > > Obviously crashing the VM is not acceptable regardless of what the application > > is doing, so something is badly wrong here. > > As far as I can tell, the Cocoa and Carbon VMs do not ship with > pre-built plugins necessary for OSProcess. I naively tried David's > test with a couple and crashed the VM each time. Mike, did you build > your own OSProcess and AIO plugins? > > (I tried one of Ian Piumarta's Unix VMs for Darwin, because it came > with pre-built plugins, and it didn't crash the VM, but several of the > tests in Test-OSProcess failed. I chose not to document it or pursue > it further, partly because Mac OS X 10.4 is not supported by recent > VMs.) > > David: which image and VM did you use? I am using a 3.11.12-2146 VM compiled in 64-bit mode on my AMD-64 laptop with Linux, and a Squeak trunk image. This is a slow single-core CPU. In testing OSProcess and CommandShell, I will occasionally get test failures on one of the CommandShell or file lock tests. This is apparently due to timing variations in some of the tests that depend on synchronization of lots of external processes. Last I checked, the CommandShell tests have problems on a Pharo image. Again this is probably timing related, although I suspect that that heavy process switching in the CommandShell tests may be exposing an issue in the Pharo image (I'm not at all certain of other root cause here). I don't know how reliable this is on OS X. I know that most OSProcess functions work on OS X, but I'm not sure how solid the #forkSqueak is. AioPlugin is not included on OS X, although I expect that it would work if you try compiling it, because the Mac and Unix VMs share the same aio functions in the support code. Dave |
|
|
On Fri, Jan 29, David T. Lewis wrote:
> > I am using a 3.11.12-2146 VM compiled in 64-bit mode on my AMD-64 laptop > with Linux, and a Squeak trunk image. This is a slow single-core CPU. That is some very new code. Therefore I suspect my mileage will improve when I upgrade this dual-core Intel Mac to Linux or a recent OS X (rather than persevering with an unsupported version of Mac OS X. Darwin's binary loader changed circa 2008, among other things, so running the latest Xcode with an older Mac as target requires special care and feeding.) > I don't know how reliable this is on OS X. I know that most OSProcess > functions work on OS X, but I'm not sure how solid the #forkSqueak is. That will be very interesting to drill into (when I get the tax returns done :( ) I'm afraid I didn't know OSProcess could fork a Squeak until your post on Tuesday. > AioPlugin is not included on OS X, although I expect that it would > work if you try compiling it, because the Mac and Unix VMs share the > same aio functions in the support code. The darwin builds of the Unix VM have AioPlugin. I assume your demo won't work with the fallback I/O protocol. David |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |