October 2017 - Pharo-dev - lists.pharo.org

Writeup: how to contribute to Pharo
by Guillermo Polito Oct. 19, 2017

Oct. 19, 2017

Hi, I've made some write up for the pharo part (not metacello or external projects) https://github.com/guillep/PharoIntegrationProcess/wiki/ Contribute-a-fix-to-Pharo Of course, expect bugs on it :) Not everything is smooth. If you have comments, they are welcome. Guille -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

10 37

Compiler Explorer (for the Compiler guys) #offtopic
by Esteban A. Maringolo Oct. 18, 2017

Oct. 18, 2017

I'm sure we could do this with ease, because we already can see the bytecodes. https://godbolt.org/ Regards! Esteban A. Maringolo

6 9

StringMorph removing Text styling
by Peter UhnÃ¡k Oct. 18, 2017

Oct. 18, 2017

Hi, I am not sure if this is a bug or a feature, but converting Text to StringMorph clears some of the formating. Compare: |text| text := 'hello' asText makeAllColor: Color red. text asStringMorph openInWindow. "no color" (StringMorph contents: text) openInWindow. "with color" Bug? Feature? Thanks, Peter

2 3

Pharo7 DebugSession fails because of Roassal2Spec?
by Alistair Grant Oct. 18, 2017

Oct. 18, 2017

Hi All, Attempting to load DataFrame with: Metacello new baseline: 'DataFrame'; repository: 'github://PolyMathOrg/DataFrame'; load. results in what looks like a stack trace being displayed on the window background. See the attached image. The system is unresponsive until interrupted (Ctrl-. on linux). The stack in the image appears to match the stack included below from MorphicUIManager>>onPrimitiveError: onwards. I'm not at all familiar with this code, but it looks a bit like the load has failed, and then the attempt to trap it and open a debugger has failed. One of the failures, at least, appears to be because the Roassal2Spec package overrides the inherited definition of #announcer in NewValueHolder to remove the lazy initialisation. However the NewValueHolder>>announcer extension has been there for a couple of years, so I presume it is some other change that has triggered the problem. Can someone, Alexandre? :-), comment on whether NewValueHolder>>announcer should be removed? Thanks, Alistair [ delaySemaphore wait ] in Delay>>wait in Block: [ delaySemaphore wait ] BlockClosure>>ifCurtailed: Delay>>wait [ | evt type | (Delay forMilliseconds: 20) wait. Sensor nextEvent ifNotNil: [ :evtBuf | type := evtBuf first. type = EventTypeKeyboard ifTrue: [ evt := World currentHand generateKeyboardEvent: evtBuf. evt isKeystroke ifTrue: [ | c | c := evt keyCharacter. (c asciiValue < 128 or: [ c isSeparator or: [ c isSpecial or: [ c = Character backspace ] ] ]) ifTrue: [ Sensor flushKeyboard. ^ evt keyCharacter ] ] ] ] ] in Transcripter class>>nextChar in Block: [ | evt type |... BlockClosure>>repeat Transcripter class>>nextChar Transcripter class>>askForEmergencyEvaluatorOrExitWithText: MorphicUIManager>>onPrimitiveError: DebugSession(Object)>>primitiveError: DebugSession>>signalDebuggerError: [ :ex | debugSession signalDebuggerError: ex ] in [ "schedule debugger in deferred UI message to address redraw problems after opening a debugger e.g. from the testrunner." [ Smalltalk tools debugger openOn: debugSession withFullView: bool andNotification: notificationString ] on: Error do: [ :ex | debugSession signalDebuggerError: ex ] ] in MorphicUIManager>>debugProcess:context:label:fullView:notification: in Block: [ :ex | debugSession signalDebuggerError: ex ] BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: MessageNotUnderstood(Exception)>>signal UndefinedObject(Object)>>doesNotUnderstand: #announce: DictionaryValueHolder(NewValueHolder)>>valueChanged: [ | oldValue | oldValue := value. value := anObject. self valueChanged: oldValue ] in DictionaryValueHolder(NewValueHolder)>>value: in Block: [ | oldValue |... BlockClosure>>ensure: DictionaryValueHolder(NewValueHolder)>>handleCircularReferencesWhile: DictionaryValueHolder(NewValueHolder)>>value: DictionaryValueHolder>>initialize DictionaryValueHolder class(Behavior)>>new DictionaryValueHolder class(NewValueHolder class)>>value: OrderedIdentityDictionary(OrderedDictionary)>>asValueHolder GTSpecPreDebugWindow(DynamicComposablePresenter)>>initialize GTSpecPreDebugWindow(SpecPreDebugWindow)>>initialize GTSpecPreDebugWindow class(Behavior)>>new GTGenericStackDebugger>>openWithNotification: GTGenericStackDebugger class(GTMoldableDebugger class)>>openOn:withFullView:andNotification: --

1 0

[Pharo 7.0-dev] Build #209: 17754-CheckBoxModel--RadioButtonModel-ignore-disable
by ci-pharo-ci-jenkins2＠inria.fr Oct. 18, 2017

Oct. 18, 2017

There is a new Pharo build available! The status of the build #209 was: SUCCESS. The Pull Request #372 was integrated: "17754-CheckBoxModel--RadioButtonModel-ignore-disable" Pull request url: https://github.com/pharo-project/pharo/pull/372 Issue Url: https://pharo.fogbugz.com/f/cases/17754 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Spec] Improved way of linking presenters to domain model objects
by Pavel Krivanek Oct. 18, 2017

Oct. 18, 2017

Hi, this is a simple use-case for the chagnes proposed in the pull request 374 (20551-Improve-way-how-Spec-presenters-are-linked-with-domain-models). https://github.com/pharo-project/pharo/pull/374 I would like to know your comments on it. Situation: You have a presenter that shows a form with information about a person. This form contains a submit button and restore button. Next to it it shows a table with currently saved results. It is only a demo so the domain object is stored directly in this presenter. ComposablePresenterWithModel subclass: #FormPresenter instanceVariableNames: 'form table' The instance variable "form" is a presenter of a form subcomponent, the "table" is a fast table. The ComposablePresenterWithModel stores the model in an instance variable named "specCompatibleModel". This can be a Model or a NewValueHolder (as it is a subclass of Model). We have our domain model class FormModel which contains information about a person like name, surname etc. It is a subclass of Object. Object subclass: #FormModel instanceVariableNames: 'name surname ...' At the beginning we create a new instance of this class as a model for our presenter: FormPresenter>>initialize self model: FormModel new. super initialize. This will create in the instance variable "specCompatibleModel" a value holder that will contain our domain object and subscribes yourself to announcements of this value holder. We need to have this model ready before we will initialize subpresenters because we will provide this model to our form. FormPresenter>>initializeWidgets form := self instantiate: StandaloneFormPresenter on: self specCompatibleModel ... We use here "self specCompatibleModel" and not "self model" because we want to use our value holder directly. If we would use "self model", the form would create a new value holder and then we would need to synchronize the data between the form and parent presenter manually. When the model of the presenter will change, we will fill the table. FormPresenter>>imodelChanged table items: { self model name. self model surname. } The presenter for the form is a subclass of ComposablePresenterWithModel too. It contains input boxes for name and surname. Then it includes buttons for submitting and restoring of the form content. It contains an instance variable "workingModel" to store current state of the form. It is different from the model because we want to be able to restore original data. ComposablePresenterWithModel subclass: #StandaloneFormPresenter instanceVariableNames: 'workingModel nameTextInput surnameTextInput submitButton restoreButton' To create the form is straightforward and there is nothing special on it: StandaloneFormPresenter>>initializeWidgets nameTextInput := self newTextInput autoAccept: true. surnameTextInput := self newTextInput autoAccept: true. StandaloneFormPresenter>>initializePresenter self submitButton action: [self submit]. self restoreButton action: [self restore]. When we obtain a new model, we will create a new working model as copy of it and we will fill the form with its data StandaloneFormPresenter>>modelChanged workingModel := self model copy. self fillFormWithWorkingModel. StandaloneFormPresenter>>fillFormWithWorkingModel self nameTextInput text: workingModel name. self surnameTextInput text: workingModel surname. When we restore the form, we will only do the same as in case of model change - create a new working copy and update the form StandaloneFormPresenter>>restore self modelChanged When we submit the form we obtain the current data from the inputs, store them in the working model. Then we will replace the model with it and announce change of the model to other components. submit workingModel name: self nameTextInput text. workingModel surname: self surnameTextInput text. self model: workingModel. self specCompatibleModel valueChanged. This operation will force update of the parent presenter (that will update the table). The form itself will be updated too (and a new working copy will be created). In this simple case we can make it work without need of a the model working copy. In the simpler approach we wil create parent presenter model as a subclass of Model. Model subclass: #FormModel instanceVariableNames: 'name surname ...' The instantiation of StandaloneFormPresenter can be done on the model directly but it is optional because "self model" and "self specCompatibleModel" return the same object here. self instantiate: StandaloneFormPresenter on: self model When the model will change, we will simply fill the form StandaloneFormPresenter>>modelChanged self fillForm StandaloneFormPresenter>>fillForm self nameTextInput text: self model name. self surnameTextInput text: self model surname. When the form will be submitted, we fill the model with new data and announce changes. StandaloneFormPresenter>>submit self model name: self nameTextInput text. self model surname: self surnameTextInput text. self model valueChanged. So the difference here is in absence of the value holder that will store the domain object. Instead of it we use directly announcer that is provided by the Model class and modify the domain object directly. The original version with the working copy makes more sense in case when you modify the working copy directly on the fly when the user changes data. nameTextInput := self newTextInput autoAccept: true; whenTextChanged: [ self workingModel name: nameTextInput text ]. Then during submitting you can use the the working copy directly to replace the model. submit self model: workingModel. self specCompatibleModel valueChanged. Sometimes for more complex applications it may be handy to use value holders with subinstances of Model inside, when you need to subscribe some presenters directly to models and in the same time to be able to swap then (and be notified about it). This combination is possible too, just use code linke: self model: (NewValueHolder value: FormModel new). ...but then you need to take care if you are wokring with the value holder or with the model inside. submit self specCompatibleModel value: self workingModel. self specCompatibleModel valueChanged. So I hope this proposed changes are quite flexible and will make using of Spec much easier. I'm not sure with the naming of "specCompatibleModel". Cheers, -- Pavel

1 0

Techtalk today: AI
by Marcus Denker Oct. 18, 2017

Oct. 18, 2017

Hello! The tech talk starts in 20 minutes (17h europe time). Slides (pdf) can be downloaded here <https://github.com/AgileArtificialIntelligence/AgileArtificialIntelligence.…>. Invite for Discord (for Q&A after): http://discord.gg/Sj2rhxn <http://discord.gg/Sj2rhxn> The talk will be on Youtube, follow this link: https://www.youtube.com/c/AlexandreBergel/live <https://www.youtube.com/c/AlexandreBergel/live>

1 1

What is blocking Pharo from supporting long paths on Windows?
by Peter UhnÃ¡k Oct. 18, 2017

Oct. 18, 2017

So I wanted to update Iceberg in one of my PharoLauncher managed issues. Of course the load failed on some missing file... upon further exploration: updating Iceberg updates Metacello, and metacello contains content like Metacello-metacello-1af26bf/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.sectionIndex.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st (271 characters - longest file path) or Metacello-metacello-1af26bf/repository/Metacello-GemStone-TestsMCB.package/MetacelloScriptingRegistryDisableUndefinedSymbolsTestCase.extension/instance/ (152 characters - longest directory path) To that you need to add the path to the image (44 chars for me), name of the image (35 chars on avg for me), and the local location (github-cache\metacello\metacello\Pharo6.1) (41 chars). tl;dr: 120 chararacters out of Windows 260 is taken by fixed cost, and I need to fit 152+ characters (that's just directory, it includes files of course) into 140 chars. I have longPathsEnabled in Windows (10) and some applications indeed can go beyond the limit --- e.g. I can clone (with git) metacello to the same directory (and go over the limit), but Pharo will fail if I try to navigate to it. So clearly my system supports it, but not Pharo. In conclusion: Anyone familiar with WinAPI knows what needs to be done for Pharo to support unlimited/long paths? Thanks, Peter

2 1

[Pharo 7.0-dev] Build #208: 20548-sync-NewValueHolder-and-Model-announcing-interface-2
by ci-pharo-ci-jenkins2＠inria.fr Oct. 17, 2017

Oct. 17, 2017

There is a new Pharo build available! The status of the build #208 was: SUCCESS. The Pull Request #373 was integrated: "20548-sync-NewValueHolder-and-Model-announcing-interface-2" Pull request url: https://github.com/pharo-project/pharo/pull/373 Issue Url: https://pharo.fogbugz.com/f/cases/20548 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[ANN] Pharo Consortium New Bronze Member: OSOCO
by Marcus Denker Oct. 17, 2017

Oct. 17, 2017

The Pharo Consortium is very happy to announce that OSOCO has joined the Consortium as a Bronze Member. About - OSOCO: https://osoco.es - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

1 0