Hi pavel may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload. What do you think? Stef
Hi Stef, our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users - than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload. Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel 24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
Hi Pavel, Hi All, On Sun, Nov 24, 2013 at 10:11 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users - than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
Tangentially can anyone point me to a headless image with a REPL for use in testing Spur?
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
-- best, Eliot
From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
Tangentially can anyone point me to a headless image with a REPL for use in testing Spur?
Guillermo has several bootstrapped and minimal images. I tried to find them but I could not https://ci.inria.fr/pharo-contribution/job/Bootstrap/ Guillermo? Is now on holidays. I will look around. Stef
On Mon, Nov 25, 2013 at 5:09 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
Tangentially can anyone point me to a headless image with a REPL for use in testing Spur?
Guillermo has several bootstrapped and minimal images. I tried to find them but I could not https://ci.inria.fr/pharo-contribution/job/Bootstrap/
Guillermo? Is now on holidays.
Yes, but coding when not seeing family :) https://ci.inria.fr/rmod/view/Oz/ Right now I kind of broke everything... But what we have are mini images that just have an entry point method and quits. No repl cause they don't have even a compiler.
I will look around. Stef
Hi Guillermo, Hi Stef, On Mon, Nov 25, 2013 at 2:33 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Mon, Nov 25, 2013 at 5:09 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
Tangentially can anyone point me to a headless image with a REPL for use in testing Spur?
Guillermo has several bootstrapped and minimal images. I tried to find them but I could not https://ci.inria.fr/pharo-contribution/job/Bootstrap/
Guillermo? Is now on holidays.
Yes, but coding when not seeing family :)
https://ci.inria.fr/rmod/view/Oz/
Right now I kind of broke everything... But what we have are mini images that just have an entry point method and quits. No repl cause they don't have even a compiler.
As soon as you have something with a REPL in it I'd be interested. Please let me know. Thanks and thanks for looking around Stef.
I will look around. Stef
-- best, Eliot
We have a small REPL image for Pharo 2.0 https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-2.0/job/PharoKernel... It uses this code: https://gitorious.org/pharo-build/pharo-build/source/16a7598f75c46e6a12e2f4e... -- Pavel 2013/11/26 Eliot Miranda <eliot.miranda@gmail.com>
Hi Guillermo, Hi Stef,
On Mon, Nov 25, 2013 at 2:33 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
On Mon, Nov 25, 2013 at 5:09 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
Tangentially can anyone point me to a headless image with a REPL for use in testing Spur?
Guillermo has several bootstrapped and minimal images. I tried to find them but I could not https://ci.inria.fr/pharo-contribution/job/Bootstrap/
Guillermo? Is now on holidays.
Yes, but coding when not seeing family :)
https://ci.inria.fr/rmod/view/Oz/
Right now I kind of broke everything... But what we have are mini images that just have an entry point method and quits. No repl cause they don't have even a compiler.
As soon as you have something with a REPL in it I'd be interested. Please let me know.
Thanks
and thanks for looking around Stef.
I will look around. Stef
-- best, Eliot
Guillermo has several bootstrapped and minimal images. I tried to find them but I could not https://ci.inria.fr/pharo-contribution/job/Bootstrap/
Guillermo? Is now on holidays.
Yes, but coding when not seeing family :)
:)
OK I will try to have a look but I will teach three days in a row.
Right now I kind of broke everythingâ¦
"Always have a running demo" :)
But what we have are mini images that just have an entry point method and quits. No repl cause they don't have even a compiler.
"Ok may be just loading the compiler" would work ;)
I will look around. Stef
Tangentially can anyone point me to a headless image with a REPL for use in testing Spur?
Hi Eliot, This is probably much too heavyweight for what you have in mind, but if you are able to load OSProcess and CommandShell into the test image, you can then evaluate "ExternalCommandShell start", and talk to the image on stdin/stdout from your terminal session. You'll need to start the image in the foreground (no "&") so that you are connected to it from your terminal. The command evaluator accepts simple Smalltalk expressions and various unix-ish inputs. Dave
On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users
I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have
- than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
Yes
From the practical point of view, it's always faster to remove. something than to load something.
Fun since it was difficult for me to unload I thought that I should focus on load :)
And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
Hi Stef, I started to play with this way of shrinking (see the attachment). At least it's really faster than to use MC :-) Where are the configurations you are creating? Cheers, -- Pavel 2013/11/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users
I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have
- than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
Yes
From the practical point of view, it's always faster to remove.
something than to load something. Fun since it was difficult for me to unload I thought that I should focus on load :)
And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
This is the list of newly created unimplemented calls: Tests removal: a SortedCollection('Array generateSpecFormat calls: s ' 'FreeTypeFontProvider getWindowsFontFolderPath calls: char asPointerType invokeWith:with:with:with:with: long name:module:callType:returnType:argumentTypes: ' 'WorkingCopyToolBar setConfigButton calls: createConfiguration ') Zodiac removal: a SortedCollection('ZnNetworkingUtils socketStreamToUrlDirectly: calls: connect ') Athens removal: a SortedCollection('SubwidgetItem transform calls: x0Field rebuild y0 y1 y1Field x0 classChooser x1 addInstVarNamed:forClassName: y0Field x1Field ') Deprecated30 removal: a SortedCollection('HaloMorph worldBoundsForMorph: calls: outsetBy: ' 'MailMessage class dateTimeSuffix calls: primSecondsClock ' 'ZnHTTPSocketFacade class constructMultiPartFormDataEntity: calls: pathForFile ') HudsonBuildTools20 removal: a SortedCollection() ProfStef removal: a SortedCollection('HelpBrowser shoutAboutToStyle: calls: canHaveSyntaxHighlighting ') Helps removal: a SortedCollection() Nautilus removal: a SortedCollection('AbstractEyeElement browseSelectedObjectClass calls: browser ' 'AbstractTool addCategoryIn:before: calls: selectedCategory: ' 'AbstractTool addPackagesAsGroup: calls: orderedClasses addADynamicClassGroupNamed:blocks: ' 'AbstractTool addPackagesAsGroup:named: calls: addADynamicGroupSilentlyNamed:blocks: orderedClasses ' 'AbstractTool addPackagesAsGroups: calls: groupName: groupName ' 'AbstractTool createInitializerWithInstVarsOf: calls: buildSetterFor: buildInitializerFor: ' 'AbstractTool createInstVarAccessorsOf: calls: buildGetterFor: buildSetterFor: ' 'AbstractTool findMethodIn: calls: selectorFromPattern:withCaption:startingFrom: ' 'AbstractTool findPackageIn: calls: flashPackage ' 'AbstractTool mergeGroups: calls: removable removeAGroupSilently: ' 'AbstractTool moveMethodsToPackage:in:from: calls: flashPackage ' 'AbstractTool removeMethods:inClass: calls: confirmRemovalOfSelectors:on: ' 'ChangeSorterApplication browseMethodFull calls: browser ' 'ChangeSorterApplication openChangeSetBrowser calls: forClasses: browser ' 'ClassListNodeExample browseItem calls: browser ' 'ClassTreeNodeExample browseItem calls: browser ' 'CodeHolder messageListKey:from: calls: browser ' 'CodeHolder spawnHierarchy calls: browser ' 'CompiledMethod browse calls: browser ' 'DeepCopier warnInstanceVariableNotCopiedIn:selector: calls: browser ' 'DialogGroupAdder add:into: calls: addClasses:into: ' 'DialogGroupAdderUI groups calls: isFillable ' 'DialogGroupManagerUI addAGroup calls: createAnEmptyStaticGroup ' 'DialogGroupManagerUI removeAGroup calls: removeAGroup: ' 'DialogGroupManagerUI renameGroup calls: renameAGroup: ' 'EyeAbstractInspector browseSelectedObjectClass calls: browser ' 'FileContentsBrowser browseMethodFull calls: browser ' 'FinderClassNode browseClass calls: browser ' 'FinderMethodNode browseClass calls: browser ' 'FinderNode browseClass calls: browser ' 'MCCodeTool browseMethodFull calls: browser ' 'MenuRegistrationExample class mostUsedToolsOn: calls: monticelloBrowser browser ' 'MessageBrowser class messageBrowserListMenu: calls: browser ' 'MessageListNonInspectableNode doubleClick calls: browser ' 'NECContext createModel calls: modelClass ' 'NECSelectorEntry browseWith: calls: browser ' 'PSMCPatchMorph browseClass calls: browser ' 'PSMCPatchMorph changesMenu: calls: browser ' 'PackageClassNodeExample browseItem calls: browser ' 'PackageMethodNodeExample browseItem calls: browser ' 'PasteUpMorph defaultDesktopCommandKeyTriplets calls: browser recentMessageList ' 'PluggableButtonMorph browseAction calls: browser ' 'ProcessBrowser browseContext calls: browser ' 'RGBehaviorDefinition browse calls: browser ' 'RGMethodDefinition browse calls: browser ' 'RPackageOrganizer renamePackage:in: calls: openAlreadyExistingError ' 'SearchFacade class protocolSearchFor: calls: browser openOnClass:onProtocol: ' 'SearchFacade class rPackageSearchIn: calls: openOnPackage: browser ' 'SettingNode browseDeclaration calls: browser ' 'SpecDebuggerStack browseMethodFull calls: browser ' 'Spotlight resolveSymbol: calls: browser openOnPackage: 2013/11/26 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi Stef,
I started to play with this way of shrinking (see the attachment). At least it's really faster than to use MC :-) Where are the configurations you are creating?
Cheers, -- Pavel
2013/11/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users
I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have
- than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
Yes
From the practical point of view, it's always faster to remove.
something than to load something. Fun since it was difficult for me to unload I thought that I should focus on load :)
And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
On Nov 26, 2013, at 3:27 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
I started to play with this way of shrinking (see the attachment). At least it's really faster than to use MC :-)
Sure :) Do you have a ci job to produce an image systematically?
Where are the configurations you are creating?
I started with a new configuration for RB I want Nautilus Zinc, Keymapping Gofer Fuel Morphic â¦
Cheers, -- Pavel
2013/11/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users
I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have
- than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
Yes
From the practical point of view, it's always faster to remove. something than to load something.
Fun since it was difficult for me to unload I thought that I should focus on load :)
And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
<shrink.st>
2013/11/26 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 26, 2013, at 3:27 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
I started to play with this way of shrinking (see the attachment). At least it's really faster than to use MC :-)
Sure :) Do you have a ci job to produce an image systematically?
I will setup something... -- Pavel
Where are the configurations you are creating?
I started with a new configuration for RB I want Nautilus Zinc, Keymapping Gofer Fuel Morphic â¦
Cheers, -- Pavel
2013/11/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users
I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have
- than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
Yes
From the practical point of view, it's always faster to remove.
something than to load something. Fun since it was difficult for me to unload I thought that I should focus on load :)
And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
<shrink.st>
would be great. I'm doing boring admin right now and I was trying to understand why I get a problem unload Nautilus. Stef On Nov 27, 2013, at 1:46 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2013/11/26 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 26, 2013, at 3:27 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
I started to play with this way of shrinking (see the attachment). At least it's really faster than to use MC :-)
Sure :) Do you have a ci job to produce an image systematically?
I will setup something...
-- Pavel
Where are the configurations you are creating?
I started with a new configuration for RB I want Nautilus Zinc, Keymapping Gofer Fuel Morphic â¦
Cheers, -- Pavel
2013/11/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Stef,
our starting point looks like this: - we have a method how to produce small image without network etc. - we are able to load network, Monticello and Gofer in it (this job is currently broken) - we are able to load Metacello too - this should be the basic stage for normal users
I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have
- than we are a le to load rest od the system at once - we have several configurations that we are able to load and unload.
Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting.
Yes
From the practical point of view, it's always faster to remove. something than to load something.
Fun since it was difficult for me to unload I thought that I should focus on load :)
And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy.
-- Pavel
24. 11. 2013 v 22:36, Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi pavel
may be I should start from your miniimage and start to making sure that the configurations can load then in a second step I can make sure that they can unload.
What do you think?
Stef
<shrink.st>
participants (5)
-
David T. Lewis -
Eliot Miranda -
Guillermo Polito -
Pavel Krivanek -
Stéphane Ducasse