Do not run any spec related component when ran in CLI mode

[demarey]

Currently, when running Pharo Launcher by command-line,

PharoLauncher.app/Contents/MacOS/pharo-launcher image launch --help

a log appears on the console:

Process>>doTerminationFromAnotherProcess
Process>>terminate
PhLImageDescriptionUpdater>>terminateProcess
PhLImageDescriptionUpdater>>image:description:
PhLImageDescriptionUpdater class>>image:description:
PhLImageDetailPresenter>>updateImageDescription:
[ :text | self updateImageDescription: text ] in PhLImageDetailPresenter>>connectPresenters in Block: [ :text | self updateImageDescription: text ]
FullBlockClosure(BlockClosure)>>cull:
FullBlockClosure(BlockClosure)>>cull:cull:
[ :block | block cull: self value cull: oldValue ] in ObservableValueHolder>>valueChanged: in Block: [ :block | block cull: self value cull: oldValue ]...etc...
OrderedCollection>>do:
ObservableValueHolder>>valueChanged:
[ | oldValue |
	oldValue := value.
	value := anObject.
	self valueChanged: oldValue ] in ObservableValueHolder>>value: in Block: [ | oldValue |...
FullBlockClosure(BlockClosure)>>ensure:
ObservableValueHolder>>value:
SpTextPresenter(SpAbstractTextPresenter)>>text:
[
		self presenter text: aString.
		"Raise an announcement"
		self presenter changed: #clearUserEdits] in SpMorphicTextAdapter(SpMorphicBaseTextAdapter)>>accept:notifying: in Block: [...
FullBlockClosure(BlockClosure)>>ensure:
SpMorphicTextAdapter(SpMorphicBaseTextAdapter)>>accept:notifying:
SpMorphicTextAdapter>>accept:notifying:
SpRubScrolledTextMorph(RubScrolledTextMorph)>>acceptTextInModel
SpRubScrolledTextMorph(RubScrolledTextMorph)>>acceptContents
SpRubScrolledTextMorph(RubScrolledTextMorph)>>textChanged
RubTextScrollPane>>textChanged
RubEditingArea(RubAbstractTextArea)>>paragraphReplacedTextFrom:to:with:
[ 
			self composer emphasisHere: textArea emphasisHere.
			self composer replaceFrom: start to: stop with: aText.
			self text: self composer text.
			textArea paragraphWasComposedFrom: start to: stop.
			textArea paragraphReplacedTextFrom: start to: stop with: aText ] in RubParagraph>>replaceFrom:to:with: in Block: [ ...
FullBlockClosure(BlockClosure)>>ensure:
RubParagraph>>disableDrawingWhile:
RubParagraph>>replaceFrom:to:with:
RubCurrentLineBarDecorator(RubParagraphDecorator)>>replaceFrom:to:with:

It looks like PhLImageDescriptionUpdater is active while in CLI mode.
Also, debugging this (by modifying the pharo-launcher script to not run clap but allowing eval arguments) shows that there are instances of PhLImagesPresenter still alive.

PharoLauncherApplication reset. 
PhLDeploymentScript closeAllWindows. 
Stdio 
  stdout lf; 
  nextPutAll: ((ReferenceFinder findPathToInstanceOf: PhLImageDetailPresenter) reverse first: 8) printString; lf; 
  nextPutAll: PhLImagesPresenter allInstances size asString; lf.  
PhLImagesPresenter allInstances do: #delete. 
PharoLauncherApplication reset. 
3 timesRepeat: [ Smalltalk garbageCollect ]. 
PhLImagesPresenter allInstances size

[hernanmd]

From what I've seen there are references to the Spec application (PharoLauncherApplication) aside from the Spec run/start methods. For example in PhLDownloadManager>>displayProgress:during:. But there are others, like PhLError>>uiAlert and PhLImage>>showWarning:, etc.

Can we decouple things like job management (jobList senders) outside PharoLauncherApplication?
So it will avoid creating a Spec application just for displaying progress, or alerting notifications.

[demarey]

Hi Hernan,

Indeed, we need a PharoLauncherApplication that is an SpApplication for user interaction like newConfim, pushProgress:with:, showError:.
We should find a way to do not open presenters when in headless mode.
We should discuss with @estebanlm if he already had this use case.

[estebanlm]

I would say is arguably a program problem, not a spec problem.
you need to refactor your program to act accordingly to the ui you have.
Spec is for graphic applications and while I dream to have a TUI backend (I even started to do a prototype with Pavel ;), this is not something that will happen anytime soon.

my understanding of your problem is that you are using self application newInform... etc. to give some feedback, isn't?
then, I would refactor the app to have a stub non-GUI application object that can handle those messages and answer what is appropriated.
mmm... Let me know if what I am writing is clear, I am just assuming here :P

[demarey]

fixed by 64288ff, b2abc11 and 1408328 but also 2d47ed8