The Trunk: ReleaseBuilder-eem.172.mcz
Locked
 
|
Eliot Miranda uploaded a new version of ReleaseBuilder to project The Trunk:
http://source.squeak.org/trunk/ReleaseBuilder-eem.172.mcz ==================== Summary ==================== Name: ReleaseBuilder-eem.172 Author: eem Time: 5 January 2018, 7:20:47.150059 pm UUID: 4144895f-5617-4f80-9ab2-593eca77e2ac Ancestors: ReleaseBuilder-mt.171 Allow the ReleaseBuilder to query if the SistaV1 bytecode set should be the default in a new release. =============== Diff against ReleaseBuilder-mt.171 =============== Item was changed: ----- Method: ReleaseBuilder class>>prepareSourceCode (in category 'preparing') ----- prepareSourceCode "Update code. Remove foreign packages." MCMcmUpdater defaultUpdateURL: self buildRepository description. MCMcmUpdater updateMissingPackages: true. MCMcmUpdater enableUpdatesForAllPackages. TestCase new ensureInternetConnectionTo: self buildRepository description. "Flush all caches. If a previous download failed this is often helpful" MCFileBasedRepository flushAllCaches. "Save the current default updater, clear the registry, and re-register the current updater" MCMcmUpdater clearRegistry. [MCMcmUpdater default doUpdate: false. "non-interactive"] on: MCEmptyVersion do: [:warning | warning resume]. self unloadForeignPackages; checkForDirtyPackages; loadWellKnownPackages; + checkForUndeclaredSymbols; + recompileAll! - checkForUndeclaredSymbols. - - Compiler recompileAll.! Item was added: + ----- Method: ReleaseBuilder class>>recompileAll (in category 'scripts - support') ----- + recompileAll + + (Smalltalk classNamed: #EncoderForSistaV1) ifNotNil: + [:sistaBytecodeSet| + CompiledCode preferredBytecodeSetEncoderClass ~~ sistaBytecodeSet ifTrue: + [(Project uiManager + confirm: 'Do you want to make it the default in this release?' + orCancel: [false] + title: 'The SistaV1 Bytecode Set Is Available') ifTrue: + [CompiledCode + installSecondaryBytecodeSet: sistaBytecodeSet; + preferredBytecodeSetEncoderClass: sistaBytecodeSet]]]. + + Compiler recompileAll! |
Re: The Trunk: ReleaseBuilder-eem.172.mcz
|
|
Hi Marcel, Hi David, in modifying the ReleaseBuilder to allow the SistaV1 bytecode set to be selected I'm not happy having to wait until all the checking before prompting to use the bytecode set. One could move the query earlier, into setPreferences, but this means that the bytecode set would be in use before the Compiler recompileAll step, and that isn't desirable while debugging the byte code set. Would you object to me adding an instance variable to ReleaseBuilder class, useNewBytecodeSet or some such, which would be set in setPreferences and read in recompileAll? On Fri, Jan 5, 2018 at 7:20 PM, <[hidden email]> wrote: Eliot Miranda uploaded a new version of ReleaseBuilder to project The Trunk: _,,,^..^,,,_ best, Eliot |
Re: The Trunk: ReleaseBuilder-eem.172.mcz
|
HI Eliot, what about a method like "ReleaseBuilder >> #releaseLocally"? Then put both into a category like "testing"? Would be easier to change than a class-inst-var. Best, Marcel
|
Re: The Trunk: ReleaseBuilder-eem.172.mcz
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
I'm not sure that I understand well enough to offer guidance, but is it the case that when SistaV1 bytecode is fully in place that the preference for preferredBytecodeSetEncoderClass will allow the user to switch bytecode, and that the system will be recompiled as a side effect of selecting a different bytecode preferences? If that is the case, then you may be able to set the value of the preference from ReleaseBuilder in setPreferences, but defer the activation of that preference until later at the end of prepareSourceCode. I'm thinking of something along the lines of: CompiledCode class>>preferredBytecodeSetEncoderClass: aBytecodeEncoderSubclass recompile: aBoolean Aside from that suggestion, I am not very familiar with ReleaseBuilder so I'm not sure I can give help there. Dave On Fri, Jan 05, 2018 at 08:09:02PM -0800, Eliot Miranda wrote: > Hi Marcel, Hi David, > > in modifying the ReleaseBuilder to allow the SistaV1 bytecode set to be > selected I'm not happy having to wait until all the checking before > prompting to use the bytecode set. One could move the query earlier, into > setPreferences, but this means that the bytecode set would be in use before > the Compiler recompileAll step, and that isn't desirable while debugging > the byte code set. Would you object to me adding an instance variable to > ReleaseBuilder class, useNewBytecodeSet or some such, which would be set in > setPreferences and read in recompileAll? > > On Fri, Jan 5, 2018 at 7:20 PM, <[hidden email]> wrote: > > > Eliot Miranda uploaded a new version of ReleaseBuilder to project The > > Trunk: > > http://source.squeak.org/trunk/ReleaseBuilder-eem.172.mcz > > > > ==================== Summary ==================== > > > > Name: ReleaseBuilder-eem.172 > > Author: eem > > Time: 5 January 2018, 7:20:47.150059 pm > > UUID: 4144895f-5617-4f80-9ab2-593eca77e2ac > > Ancestors: ReleaseBuilder-mt.171 > > > > Allow the ReleaseBuilder to query if the SistaV1 bytecode set should be > > the default in a new release. > > > > =============== Diff against ReleaseBuilder-mt.171 =============== > > > > Item was changed: > > ----- Method: ReleaseBuilder class>>prepareSourceCode (in category > > 'preparing') ----- > > prepareSourceCode > > "Update code. Remove foreign packages." > > > > MCMcmUpdater defaultUpdateURL: self buildRepository description. > > > > MCMcmUpdater updateMissingPackages: true. > > MCMcmUpdater enableUpdatesForAllPackages. > > > > TestCase new ensureInternetConnectionTo: self buildRepository > > description. > > > > "Flush all caches. If a previous download failed this is often > > helpful" > > MCFileBasedRepository flushAllCaches. > > > > "Save the current default updater, clear the registry, and > > re-register the current updater" > > MCMcmUpdater clearRegistry. > > > > [MCMcmUpdater default doUpdate: false. "non-interactive"] > > on: MCEmptyVersion do: [:warning | warning resume]. > > > > self > > unloadForeignPackages; > > checkForDirtyPackages; > > loadWellKnownPackages; > > + checkForUndeclaredSymbols; > > + recompileAll! > > - checkForUndeclaredSymbols. > > - > > - Compiler recompileAll.! > > > > Item was added: > > + ----- Method: ReleaseBuilder class>>recompileAll (in category 'scripts - > > support') ----- > > + recompileAll > > + > > + (Smalltalk classNamed: #EncoderForSistaV1) ifNotNil: > > + [:sistaBytecodeSet| > > + CompiledCode preferredBytecodeSetEncoderClass ~~ > > sistaBytecodeSet ifTrue: > > + [(Project uiManager > > + confirm: 'Do you want to make it the > > default in this release?' > > + orCancel: [false] > > + title: 'The SistaV1 Bytecode Set Is > > Available') ifTrue: > > + [CompiledCode > > + > > installSecondaryBytecodeSet: sistaBytecodeSet; > > + > > preferredBytecodeSetEncoderClass: sistaBytecodeSet]]]. > > + > > + Compiler recompileAll! > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > |
Re: The Trunk: ReleaseBuilder-eem.172.mcz
|
|
Hi David,
On Sat, Jan 6, 2018 at 8:02 AM, David T. Lewis <[hidden email]> wrote: Hi Eliot, Yes. Selecting the preference will then arrange that subsequent compilations will produce methods in that set. and I don't think setting the preference should recompile the system, though. a) recompilation takes of the order of a minute, depending on system size, and b) recompilation leaves lots of unbound methods and blocks if not followed by a system reinitialization phase. Hence my focus now, after I have the bytecode set fully working, is on setting the preference during the release process with the idea that for most users it will be a default. Experimenters can of course do whatever they like, but for most of us I expect we'd rathe it "just worked" and stayed well under the covers.
Well, I'm learning :-). Right now I'm learning that I should be focussing on getting recompilation and decompilation to work without progressing to ReleaseBuilder just yet :-) My code has problems that need addressing before I slow down my development by sitting in the modify-compiler-then-test-recompile-in-the-ReleaseBuilder cycle :-)
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: ReleaseBuilder-eem.172.mcz
|
|
In reply to this post by marcel.taeumel
Hi,
First, oops, I've been sending messages in this thread to Marcel Weiher, not Marcel Taeumel. Forgive me; I of course want to talk with you Marcel Taeumel :-) On Sat, Jan 6, 2018 at 12:12 AM, Marcel Taeumel <[hidden email]> wrote:
Well, I suppose we could add class variables for major settings. We could provide a check-box dialog for selecting the major options. With this approach we'd get rid of the "Do you want to discard local changes?" prompt and move the asking of the question to the start of the process, avoiding having to sit there waiting for slow phases to complete to answer the prompts. So the two questions we want to ask right now are - do you want to discard local changes? - do you want to change the default bytecode set? Are there others?
Cheers!
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: ReleaseBuilder-eem.172.mcz
|
|
Yes, upfront Q&A sounds good. Eventually, we might want to have some guided, interactive release building process so that any new release manager can understand the process quickly. Speaking of unattended release building, our TravisCI does not simply call #saveAsNewRelease. See this: https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/prepare_image.st It has its own version of #prepareSourceCode and just calls #prepareEnvironment afterwards. Best, Marcel
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |