Squeak-dev November 2009

squeak-dev@lists.squeakfoundation.org

89 participants
351 discussions

The Trunk: Morphic-dtl.222.mcz
by commits＠source.squeak.org 08 Nov '09

08 Nov '09

David T. Lewis uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-dtl.222.mcz ==================== Summary ==================== Name: Morphic-dtl.222 Author: dtl Time: 8 November 2009, 12:10:36 pm UUID: f86670be-9739-4124-a5f8-3a70136d1afe Ancestors: Morphic-ar.221 Move three methods from MorphicProject back to Project, undoing prior change. These are required for creating and entering an MVC project from Morphic. =============== Diff against Morphic-ar.221 =============== Item was removed: - ----- Method: MorphicProject>>flapsSuppressed: (in category 'flaps support') ----- - flapsSuppressed: aBoolean - "Make the setting of the flag that governs whether global flaps are suppressed in the project be as indicated and add or remove the actual flaps" - - self projectPreferenceFlagDictionary at: #showSharedFlaps put: aBoolean not. - self == Project current "Typical case" - ifTrue: - [Preferences setPreference: #showSharedFlaps toValue: aBoolean not] - ifFalse: "Anomalous case where this project is not the current one." - [aBoolean - ifTrue: - [Flaps globalFlapTabsIfAny do: - [:aFlapTab | Flaps removeFlapTab: aFlapTab keepInList: true]] - - ifFalse: - [self currentWorld addGlobalFlaps]]. - Project current assureNavigatorPresenceMatchesPreference! Item was removed: - ----- Method: MorphicProject>>showSharedFlaps (in category 'flaps support') ----- - showSharedFlaps - "Answer whether shared flaps are shown or suppressed in this project" - - | result | - result := Preferences showSharedFlaps. - ^ self == Project current - ifTrue: - [result] - ifFalse: - [self projectPreferenceAt: #showSharedFlaps ifAbsent: [result]]! Item was removed: - ----- Method: MorphicProject>>flapsSuppressed (in category 'flaps support') ----- - flapsSuppressed - "Answer whether flaps are suppressed in this project" - - ^ self showSharedFlaps not!

1 0

The Trunk: System-dtl.162.mcz
by commits＠source.squeak.org 08 Nov '09

08 Nov '09

David T. Lewis uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-dtl.162.mcz ==================== Summary ==================== Name: System-dtl.162 Author: dtl Time: 7 November 2009, 11:57:44 am UUID: 6f140160-1c75-48a9-b282-d51b609c8d0f Ancestors: System-dtl.161 Move three methods from MorphicProject back to Project, undoing prior change. These are required for creating and entering an MVC project from Morphic. =============== Diff against System-dtl.161 =============== Item was added: + ----- Method: Project>>showSharedFlaps (in category 'flaps support') ----- + showSharedFlaps + "Answer whether shared flaps are shown or suppressed in this project" + + | result | + result := Preferences showSharedFlaps. + ^ self == Project current + ifTrue: + [result] + ifFalse: + [self projectPreferenceAt: #showSharedFlaps ifAbsent: [result]]! Item was added: + ----- Method: Project>>flapsSuppressed (in category 'flaps support') ----- + flapsSuppressed + "Answer whether flaps are suppressed in this project" + + ^ self showSharedFlaps not! Item was added: + ----- Method: Project>>flapsSuppressed: (in category 'flaps support') ----- + flapsSuppressed: aBoolean + "Make the setting of the flag that governs whether global flaps are suppressed in the project be as indicated and add or remove the actual flaps" + + self projectPreferenceFlagDictionary at: #showSharedFlaps put: aBoolean not. + self == Project current "Typical case" + ifTrue: + [Preferences setPreference: #showSharedFlaps toValue: aBoolean not] + ifFalse: "Anomalous case where this project is not the current one." + [aBoolean + ifTrue: + [Flaps globalFlapTabsIfAny do: + [:aFlapTab | Flaps removeFlapTab: aFlapTab keepInList: true]] + + ifFalse: + [Smalltalk isMorphic ifTrue: + [self currentWorld addGlobalFlaps]]]. + Project current assureNavigatorPresenceMatchesPreference!

1 0

Daily Commit Log
by commits＠source.squeak.org 08 Nov '09

08 Nov '09

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2009-November/001734.h… Name: Network-nice.40 Ancestors: Network-nice.39 Borrow excellent fix from http://code.google.com/p/pharo/issues/detail?id=1152 and let these instVarAt:put: out of our sight =============================================

1 0

More Installer and Sake/Packages documentation
by Ken G. Brown 08 Nov '09

08 Nov '09

For those who cannot be bothered to look in an Image for documentation, here are some of the Class Comments retrieved from an 090628-1523_Squeak3.10.2-lpf-atomic image from <ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/latest/> after executing Installer install: 'Packages'. This is also being posted to <http://squeaktipsandtrickswatch.blogspot.com/>. Ken G. Brown -- Installer-Core/Installer Documentation now available at http://installer.pbwiki.com/Installer useFileIn - flag to load source.st rather than using Monticello -- Installer-Core/InstallerMantis Search feature is based upon a custom mantis query ceveloped and maintained by Ken Causey <ken(a)kencausey.com> Installer mantis bugsAll select: [ :ea | ea status = 'testing' ]. -- Installer-Formats/SARInstaller I am an object that handles the loading of SAR (Squeak ARchive) files. A SAR file is a Zip file that follows certain simple conventions: * it may have a member named "install/preamble". This member, if present, will be filed in as Smalltalk source code at the beginning of installation. Typically, the code in the preamble will make whatever installation preparations are necessary, and will then call methods in the "client services" method category to extract or install other zip members. * It may have a member named "install/postscript". This member, if present, will be filed in as Smalltalk source code at the end of installation. Typically, the code in the postscript will set up the operating environment, and will perhaps put objects in flaps, open projects or README files, or launch samples. Within the code in the preamble and postscript, "self" is set to the instance of the SARInstaller. If neither an "install/preamble" nor an "install/postscript" file is present, all the members will be installed after prompting the user, based on a best guess of the member file types that is based on member filename extensions. This is new behavior. -- Installer-Scripts/InstallerScripts (self new addPackage: 'Example') options collect: [ :ea | ea value asLegalSelector asSymbol ] #(#scriptExampleSqueak310forKPH #scriptExampleSqueak310 #scriptExampleSqueak310) -- Installer-Launcher/Launcher A Launcher provides squeak with a range of capabilities that are intended to be used from the command line. As a design goal, the startup process can invoke Launcher several times at several points in the startup sequence. In particular 1) below aims to provide a mechanism for getting in to images that are broken in some form, so as to enable a script to be run before morphic has attempted to startup. 1) Launcher is registered to handle startup notification after Security manager any class which wishes to provide a service to be usable at this time implements startFrom: 2) Launcher is wired in to ProjectLauncher to handle startup notification when squeak is fully initialized. Any class wishing to provide a service to be usable at this time implements launchFrom: #startFrom: and #launchFrom: are called providing a handle to the launcher which may be used to obtain parameters using the desired scheme. a) launcher getParameters . key=value +yes -no b) launcher getParametersOldStyle . key value key2 value2 Instance Variables actionSelector: #startFrom: #launchFrom: commandLineClass: aClass image: the smalltalk image or self if being a mock mock: the mock array of startup parameters nextCommandLineDocument: aString nextParameterIndex: anInteger -- Sake-Core/SakeBlock Raise this if for some reason you find that the task you are doing is blocked. This might occur in a multi builder build system where two building threads decide to build the same item. (implementation idea - not implemented yet) When a Block is detected, Sake, looks for any following dependent task that is not dependant upon the blocked task. Alternatively, Sake could simply randomise the task order and re-sort them, tryng again. -- Sake-Core/SakeCompiler Enables methods to include raw uncompiled text for documentation purposes following a line containing 6 quotes """""" -- Sake-Core/SakeMeta I'm a dictionary which can be used using any method call instead of #at:put: and at:. Use me like: - (aSakeMeta foo: 'bar') which is equivalent to (aSakeMeta at: 'foo' put: 'bar') - (aSakeMeta foo) which is equivalent to (aSakeMeta at: 'foo') The instance variable 'order' remembers the order in which the elements have been added. The methods #withIndexDo: and #printOn: use this variable to iterate in the same order. | s | s := ReadWriteStream on: String new. (self new a: 1; b: 2; yourself) storeOn: s. s reset contents -- Sake-Core/SakeTask SakeTasks are typically defined as class side methods, which return an instance of SakeTask. To obtain a list of available tasks, do "Senders of #define: " MyClass-task1: aParameter ^ SakeTask define: [ :task | task dependsOn: {self ruleL3.}. task if: [ <return true if action is needed> ]. task action: [ <do something> ] ] The 'unique id' of a task is the method context in which it is instanciated, and its paramters. Therefore only one task should be instanciated per method. Note: Sake tasks can have parameters, Rake tasks dont. To execute a task... (MyClass task1: 'param') run. Results of the prior tasks are available via #results. FAQ ==== How can I call one Sake task from inside another task? Generally, if you want invoke one task from another task, the proper way to do that is to include the task to be invoked as a prerequisite of the task doing the invoking. For example: MyTasks-c-#taskPrimary ^ SakeTask define: [ :task | task dependsOn: { self taskSecondary }. task action: [ self log sake: 'Doing Primary Task'. ]. ] MyTasks-c-#taskSecondary ^ SakeTask define: [ :task | task action: [ self log sake: 'Doing Secondary Task' ]. ] In this case, if the secondary task fails, the whole task stops. Secondary tasks can also be passed to the ifBlock. In that case, if the task succeeds then the action is performed, if the task fails then the action is considered not needed. ^ SakeTask define: [ :task | task if: { self taskSecondary }. task action: [ self log sake: 'Doing Primary Task'. ]. ] Action, can also take a list of tasks. ^ SakeTask define: [ :task | task action: { self taskSecondary. [ self log sake: 'Doing Primary Task' ]. "a block task" } ]. -- Sake-Packages/Packages Sake/Packages usage: Definitions Search Path ============================ Packages named: 'PackageName'. Will obtain a package definition. Subclasses of Packages are searched using the order defined by #findPath which is specified by #priority. e.g. Packages findPath => {PackagesSqueak310 . PackagesDev . PackagesAll . PackagesSeaside29} Packages-#priority is used to sort classes like so: The class with defns for a relevant version (listed in #relevantVersions) => 100 The class with defns for dev version (PackagesDev) => 400 The class with defns for all versions (PackagesAll) => 500 Additional package "universes" can define their own priority in order to specify where to appear in the #findPath. PackagesSeaside29 PackagesGjaller PackagesBeach Usage: ======== verbose usage specifying run style. (Packages named: 'Seaside') run. " or runQuietly, runStepping, runLogging" #runStepping , - presents a confirm/debug dialog before each action. #run - default. #runQuietly - auto-confirms any SakeConfirm dialogs. #runLogging - Writes any SakeStop warnings to self log. default usage: Packages load: 'Seaside'. Packages latest: 'Seaside'. "as above, but use latest versions of everything" Packages unload: 'Seaside'. multiples: Packages load: #('Seaside' 'Magma' 'Logging') Unloading ======== Unloading comes in two variants. Each package task loaded by Sake/Packages is remembered in the 'provided' list If you perform: Packages unload: 'Seaside' . Packages unloadStepping: 'Seaside' . Then the 'historical' unload scripts are used, as defined when the original load tasks were run. If instead you perform: (Packages current named: 'Seaside') beUnloading runStepping. Then the most recently defined unload script will be run. Note: If packages such as "Magma server" and "Magma client" provides "Magma", then Packages unload: 'Magma'. Will unload whichever of the two are loaded. === Misc notes... Universes are using 'instance side' task definition, so the task extensions mechanism does not work in this context. If a package appears in Packages under an obscure name, it can tell the PackageInfo instance what name was used to load it via #mcName: If a package has a version number with a '+' after it, then 'Packages upgrade' will always attempt to load the latest code, leaving Monticello to determine if there are any code changed that need to be applied. To generate all of the methods based upon universes definitions: Packages taskGenerateAllUniverses run. or Packages taskGenerateAll run. -- Packages-Library/PackagesDevU Package definitions for this version as obtained automatically from the Universes server. To override the definitions in the univere add to my subclass in PackagesSqueak310 To re-read the package definitions from the universes server. self taskGeneratePackageTasks run --

1 0

The Trunk: Network-nice.40.mcz
by commits＠source.squeak.org 07 Nov '09

07 Nov '09

Nicolas Cellier uploaded a new version of Network to project The Trunk: http://source.squeak.org/trunk/Network-nice.40.mcz ==================== Summary ==================== Name: Network-nice.40 Author: nice Time: 7 November 2009, 9:30:57 am UUID: 41f7cb4d-5d90-47f2-b9cf-fb68878f5012 Ancestors: Network-nice.39 Borrow excellent fix from http://code.google.com/p/pharo/issues/detail?id=1152 and let these instVarAt:put: out of our sight =============== Diff against Network-nice.39 =============== Item was changed: ----- Method: HTTPSocket>>getResponseUpTo:ignoring: (in category 'as yet unclassified') ----- getResponseUpTo: markerString ignoring: ignoreString "Keep reading, until the marker is seen, skipping characters in ignoreString when comparing to the marker. Return three parts: header, marker, beginningOfData. Fails if no marker in first 2000 chars." + | buf position bytesRead tester mm skipped | - | buf response bytesRead tester mm skipped | buf := String new: 2000. + position := 0. - response := WriteStream on: buf. tester := 1. mm := 1. skipped := 0. [tester := tester - markerString size + 1 max: 1. "rewind a little, in case the marker crosses a read boundary" + tester to: position do: [:tt | - tester to: response position do: [:tt | (buf at: tt) = (markerString at: mm) ifFalse: [[ignoreString includes: (markerString at: mm)] whileTrue: [mm := mm + 1. skipped := skipped + 1]]. (buf at: tt) = (markerString at: mm) ifTrue: [mm := mm + 1] ifFalse: [mm := 1. skipped := 0]. "Not totally correct for markers like xx0xx" mm > markerString size ifTrue: ["got it" ^ Array with: (buf copyFrom: 1 to: tt+1-mm+skipped) with: markerString + with: (buf copyFrom: tt+1 to: position)]]. + tester := 1 max: position. "OK if mm in the middle" + (position < buf size) & (self isConnected | self dataAvailable)] whileTrue: [ - with: (buf copyFrom: tt+1 to: response position)]]. - tester := 1 max: response position. "OK if mm in the middle" - (response position < buf size) & (self isConnected | self dataAvailable)] whileTrue: [ (self waitForDataUntil: (Socket deadlineSecs: 5)) ifFalse: [ Transcript show: 'data was late'; cr]. bytesRead := self primSocket: socketHandle receiveDataInto: buf + startingAt: position + 1 count: buf size - position.. + position := position + bytesRead]. - startingAt: response position + 1 count: buf size - response position. - "response position+1 to: response position+bytesRead do: [:ii | - response nextPut: (buf at: ii)]. totally redundant, but needed to advance position!!" - response instVarAt: 2 "position" put: - (response position + bytesRead)]. "horrible, but fast" + ^ Array with: (buf copyFrom: 1 to: position) - ^ Array with: response contents with: '' with: '' "Marker not found and connection closed" ! Item was changed: ----- Method: HTTPSocket>>getResponseUpTo: (in category 'as yet unclassified') ----- getResponseUpTo: markerString "Keep reading until the marker is seen. Return three parts: header, marker, beginningOfData. Fails if no marker in first 2000 chars." + | buf position bytesRead tester mm tries | - | buf response bytesRead tester mm tries | buf := String new: 2000. + position := 0. - response := WriteStream on: buf. tester := 1. mm := 1. tries := 3. [tester := tester - markerString size + 1 max: 1. "rewind a little, in case the marker crosses a read boundary" + tester to: position do: [:tt | - tester to: response position do: [:tt | (buf at: tt) = (markerString at: mm) ifTrue: [mm := mm + 1] ifFalse: [mm := 1]. "Not totally correct for markers like xx0xx" mm > markerString size ifTrue: ["got it" ^ Array with: (buf copyFrom: 1 to: tt+1-mm) with: markerString + with: (buf copyFrom: tt+1 to: position)]]. + tester := 1 max: position. "OK if mm in the middle" + (position < buf size) & (self isConnected | self dataAvailable) - with: (buf copyFrom: tt+1 to: response position)]]. - tester := 1 max: response position. "OK if mm in the middle" - (response position < buf size) & (self isConnected | self dataAvailable) & ((tries := tries - 1) >= 0)] whileTrue: [ (self waitForDataUntil: (Socket deadlineSecs: 5)) ifFalse: [ Transcript show: ' <response was late> ']. bytesRead := self primSocket: socketHandle receiveDataInto: buf + startingAt: position + 1 count: buf size - position. + position := position + bytesRead]. - startingAt: response position + 1 count: buf size - response position. - "response position+1 to: response position+bytesRead do: [:ii | - response nextPut: (buf at: ii)]. totally redundant, but needed to advance position!!" - response instVarAt: 2 "position" put: - (response position + bytesRead)]. "horrible, but fast" + ^ Array with: (buf copyFrom: 1 to position) - ^ Array with: response contents with: '' with: '' "Marker not found and connection closed" !

1 0

Re: [squeak-dev] Terms of Reference: discussion is open
by Eliot Miranda 07 Nov '09

07 Nov '09

On Sat, Nov 7, 2009 at 9:50 AM, Ken G. Brown <kbrown(a)mac.com> wrote: > At 12:00 PM -0800 11/6/09, Eliot Miranda apparently wrote: > >On Fri, Nov 6, 2009 at 11:26 AM, Ken G. Brown <<mailto:kbrown@mac.com> > kbrown(a)mac.com> wrote: > > > >At 7:15 PM +0100 11/6/09, Bert Freudenberg apparently wrote: > >>On 06.11.2009, at 18:46, Ken G. Brown wrote: > >> > >>>IMHO, such smart guys that are doing the majority of contributions to > trunk could have figured out the way forward with Keith's established future > methodology using Installer, Sake/Packages, Bob the Builder, MC 1.5/1.6 in > about ten minutes. Some were already up to speed on the way forward. They > could then have contributed fixes to the tools for that methodology where > required and we would be now in the future instead of stuck in the past, > forked yet again with the old trunk methodology (it's not a 'new' > development model) that got us into the difficulties in the first place. > >>> > >>>Ken G. Brown > >> > >>If it all sounds so easy (which in fact it wasn't, neither for the board > members nor the community at large half a year ago) then why don't you > contribute a tool everybody can use to easily harvest Mantis fixes into > Trunk? Or add Installer support for trunk development? Or set up a Bob > server to churn out ready-built trunk images and test results? Or make a > trunk image with MC 1.5/1.6? > > > >I believe you are looking at this the wrong way around. The trunk started > at an old position. > >As you surely know, latest Installer, lpf and Sake/packages are already in > the latest <http://ftp.squeak.org/3.11/Squeak3.10.2-lpf> > ftp.squeak.org/3.11/Squeak3.10.2-lpf or < > http://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/> > ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/, ready to go for Bob the > Builder. If the trunk additions were added to the latest, using > Sake/Packages I believe we would have something. Andreas and I showed that > the trunk repository gets quite far along loading into Keith's latest but > with hacks required to overcome the divergence that trunk has taken. Someone > with the intimate knowledge of what is going wrong could most likely fix the > remaining issue/issues easily. Adding lpf, MC 1.5/1.6 etc. to trunk, just > continues the divergence. > > > > > >>It may take you more then 10 minutes but *that* might get us moved > forward even faster. Trunk development does progress fine, but we're all for > improved tools and processes, so let's see them. > > > >You only need to look at Keith's documentation, videos, and emails to see > where it is all at. He has explained this all in my opinion in enough detail > over and over again. > > > > > >We've already been over this. A disparate set of communications is > inadequate. It is too onerous to try and understand the system from a long > and multi-media thread. This needs to be committed to some web pages, e.g. > a wiki. > > > > For a while (before trunk), I was saving pertinent emails to a blog at < > http://squeaktipsandtrickswatch.blogspot.com/>. Some things have changed > with Keith's stuff since but relatively minor I think. One could ask him if > really interested. > Here is Keith's video from 4 months ago > http://www.vimeo.com/groups/squeak/videos/5434330 showing how to use > Sake/Packages to load AND unload Seaside 3.0. > I am NOT sitting through a video taking notes. That should be done once by the documentor(s), not multiple times by each viewer. A video is such an ADD way of communicating technical information. It is NOT a reference document. It is great for an informal talk that provides entertainment and enlightenment in equal measure. But as a manual page it is pathetic. The medium needs to fit the message. > Ken G. Brown > > >Ken G. Brown > > > > > >>And now back to the discussion at hand, shall we? Otherwise please change > the subject. > >> > >>- Bert - > > >

2 1

Re: Squeak direction: Was: Re: [squeak-dev] Terms of Reference:
by Gary Dunn 07 Nov '09

07 Nov '09

On Fri, 6 Nov 2009 19:53:48 +0200 Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/11/6 Miguel Enrique Cob Martinez <miguel.coba(a)gmail.com>: >> El vie, 06-11-2009 a las 07:22 -0300, Juan Vuletich escribi: >> >>> Hey, nice talk. Now, what are your own great dreams with Squeak? What >>> are you doing to pursue them? [snip] >> My question, in simple terms is, what are the goals of Squeak. Something >> like, for example: >> >> - minimal under 10 MB core image. >> - Etoys removal >> - All packages removed from image and easily loaded from squeak source >> - In core only collections, compiler, kernel and I/O. >> - Purge of squeaksource or new squeak source with maintained packages >> - fix of squeakmap mess >> - new framework for managing packages/dependencies/configuration >> (sake/packages, metacello, other) in next minimal squeak core [snip] > > you are smart enough to see the Squeak's shortest reachable goals > (listed above) in same way as i do. > Manifest the plan and milestones , and i (and i hope many others) will > support you. My interest in squeak is as a foundational part of the Open Slate Project. My preference is to have a useful and engaging envirnment available right after installation. A leaner image has merits for experienced squeakers, but forcing new users to learn how to find and install packages in order to do anything will hinder it's success. I must confess to being a bit overwhelmed at first by the richness of squeak. -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from a Newton 2100 via Mail V

2 1

Re: [squeak-dev] Terms of Reference: discussion is open
by Eliot Miranda 07 Nov '09

07 Nov '09

On Fri, Nov 6, 2009 at 11:26 AM, Ken G. Brown <kbrown(a)mac.com> wrote: > At 7:15 PM +0100 11/6/09, Bert Freudenberg apparently wrote: > >On 06.11.2009, at 18:46, Ken G. Brown wrote: > > > >>IMHO, such smart guys that are doing the majority of contributions to > trunk could have figured out the way forward with Keith's established future > methodology using Installer, Sake/Packages, Bob the Builder, MC 1.5/1.6 in > about ten minutes. Some were already up to speed on the way forward. They > could then have contributed fixes to the tools for that methodology where > required and we would be now in the future instead of stuck in the past, > forked yet again with the old trunk methodology (it's not a 'new' > development model) that got us into the difficulties in the first place. > >> > >>Ken G. Brown > > > >If it all sounds so easy (which in fact it wasn't, neither for the board > members nor the community at large half a year ago) then why don't you > contribute a tool everybody can use to easily harvest Mantis fixes into > Trunk? Or add Installer support for trunk development? Or set up a Bob > server to churn out ready-built trunk images and test results? Or make a > trunk image with MC 1.5/1.6? > > I believe you are looking at this the wrong way around. The trunk started > at an old position. > As you surely know, latest Installer, lpf and Sake/packages are already in > the latest ftp.squeak.org/3.11/Squeak3.10.2-lpf or > ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/, ready to go for Bob the > Builder. If the trunk additions were added to the latest, using > Sake/Packages I believe we would have something. Andreas and I showed that > the trunk repository gets quite far along loading into Keith's latest but > with hacks required to overcome the divergence that trunk has taken. Someone > with the intimate knowledge of what is going wrong could most likely fix the > remaining issue/issues easily. Adding lpf, MC 1.5/1.6 etc. to trunk, just > continues the divergence. > > >It may take you more then 10 minutes but *that* might get us moved forward > even faster. Trunk development does progress fine, but we're all for > improved tools and processes, so let's see them. > > You only need to look at Keith's documentation, videos, and emails to see > where it is all at. He has explained this all in my opinion in enough detail > over and over again. > We've already been over this. A disparate set of communications is inadequate. It is too onerous to try and understand the system from a long and multi-media thread. This needs to be committed to some web pages, e.g. a wiki. > > Ken G. Brown > > >And now back to the discussion at hand, shall we? Otherwise please change > the subject. > > > >- Bert - > > >

2 1

Re: [squeak-dev] Terms of Reference: discussion is open
by Ken G. Brown 07 Nov '09

07 Nov '09

IMHO, such smart guys that are doing the majority of contributions to trunk could have figured out the way forward with Keith's established future methodology using Installer, Sake/Packages, Bob the Builder, MC 1.5/1.6 in about ten minutes. Some were already up to speed on the way forward. They could then have contributed fixes to the tools for that methodology where required and we would be now in the future instead of stuck in the past, forked yet again with the old trunk methodology (it's not a 'new' development model) that got us into the difficulties in the first place. Ken G. Brown At 2:23 PM -0300 11/6/09, Jecel Assumpcao Jr apparently wrote: >Ronald Spengler wrote: >> When the announcement that there was going to be a trunk repository >> and a contrib repository was made, I suddenly had hope again. The fact >> that there was a two-man release team that I didn't even know about >> (being a noob, I guess) didn't make a whit of difference to me, >> because they weren't shipping anything. > >There was actually a one man release team (Matthew for 4.0) and another >two man release team (Keith and Matthew for 3.11), and though they both >were very busy with other things in their lives I think the board's >position (which I fully agreed with) that the relicensing was the >priority and new development would complicate it was the main cause of >the seeming lack of progress in Squeak. And I actually looked at the >archives of the Pharo mailing list at the time and compared it with the >number of entries on Mantis and found out that though they seemed very >different, the level of activity in both projects was comparable. > >Unfortunately, appearance can matter more than reality. The *right* >thing for the board to have done would be to talk to Matthew and Keith >about the new direction, have a final vote in the following meeting and >then announce it here. Letting Keith find out with everybody else was >bad, so I see where the scheme explained by Phil would come in. But my >impression at the time was that two weeks of silence on squeak-dev (to >wait for the next board meeting) would cause lots of people to leave and >they might not later hear about the new process and decide to come back. >So I voted we do the wrong thing instead (the needs of the many outweigh >the needs of the few and that sort of thing) and still stand by that >decision. > >I can't imagine some higher authority defending a developer from the >board even if this episode shows the need for something like that. So >the alternative is to complain about anything you don't like here on >squeak-dev. That has been done and even though there seemed to be no >immediate results it might have an effect (or not) in the next election. > >-- Jecel

3 3

Daily Commit Log
by commits＠source.squeak.org 07 Nov '09

07 Nov '09

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2009-November/001733.h… Name: Kernel-tbn.288 Ancestors: Kernel-ul.287 categorize and format ChronologyConstants>>initialize as a first commit test =============================================

1 0

← Newer
1
...
29
30
31
32
33
34
35
36
Older →

Jump to page: