December 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]
by GitHub Dec. 17, 2014

Dec. 17, 2014

Branch: refs/tags/40417 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] c234a0: 40417
by GitHub Dec. 17, 2014

Dec. 17, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c234a0e368e72ee0e0b8d2735f48f64ad5b5676c https://github.com/pharo-project/pharo-core/commit/c234a0e368e72ee0e0b8d273… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-17 (Wed, 17 Dec 2014) Changed paths: M Kernel.package/ManifestKernel.class/definition.st M Morphic-Widgets-Tabs.package/Tab.class/instance/private-tab label/modifyClippingBounds_.st M Nautilus.package/AbstractNautilusUI.class/class/menu/sourceCodeMenuExtra_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script417.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40417.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40417 14628 Wrong clipping bounds in Morphic widget Tab https://pharo.fogbugz.com/f/cases/14628 14600 ManifestKernel should be a subclass of PackageManifest https://pharo.fogbugz.com/f/cases/14600 13248 Run test menu option from text area does not work https://pharo.fogbugz.com/f/cases/13248 http://files.pharo.org/image/40/40417.zip

1 0

Spec TabManager clipping issues
by Peter UhnÃ¡k Dec. 17, 2014

Dec. 17, 2014

Hi, there seems to be some weird clipping issue in Spec's tabs. The issue is in Pharo4; Pharo3 works fine. Pharo4: â Pharo3: â Peter

5 5

Little feature for ConfigurationBrowser
by stepharo Dec. 16, 2014

Dec. 16, 2014

Hi T. would it be possible to get a menu that creates the repo in the MC Browser from the ConfigurationBrowser like that people will be able to push their configuration without having to create all the repo manually? Stef

2 2

GTInspector and huge arrays issue
by kilon alios Dec. 16, 2014

Dec. 16, 2014

so I am enjoying the new Inspector but I have come to a problem. I inspected Smalltalk global variable and has gave me an array with 4000+ items . My problem is that there is no way to quickly scroll those items for example to go forward i have to scroll down and then press next page icon. I think it would be better if the next page icon is always displayed , it does not make sense to me for it to become visible only when I scroll down. Something that would have been following normal GUI behavior it would be just few button presses, now its scroll down to make the next page button visible , then repeat. Very tedious. also if I put "image" in the search box it gives me an MNU UndefinedObject(Object)>>doesNotUnderstand: #ifTrue: GLMTreeMorphModel>>ExecuteUnOptimizedIn: UndefinedObject(Object)>>mustBeBooleanInMagic: UndefinedObject(Object)>>mustBeBoolean [ :each | check := self glamourPresentation searchStrategy value: self inputText value: each item. check ifTrue: [ newSelection add: each path ] ] in GLMTreeMorphModel>>executeSearch in Block: [ :each | ... OrderedCollection>>do: GLMTreeMorphModel>>executeSearch GLMTreeMorphModel>>doSearchOrFilter GLMTreeMorphModel>>inputText: PluggableTextFieldMorph>>acceptTextInModel PluggableTextFieldMorph(PluggableTextMorph)>>acceptBasic PluggableTextFieldMorph>>accept TextMorphForFieldView(TextMorphForEditView)>>acceptContents TextEditor>>accept TextMorphForFieldView(TextMorphForEditView)>>keyStroke: TextMorphForFieldView>>keyStroke: TextMorphForFieldView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForFieldView(Morph)>>handleEvent: TextMorphForFieldView(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: in Block: [ ... BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do:

9 24

Re: [Pharo-dev] [ANN] RProjectConnector V1.0
by csrabak＠bol.com.br Dec. 16, 2014

Dec. 16, 2014

Vincent BLONDEAU a ecrit: > Â Hello everyone, > I am glad to announce the first version of the RProjectConnector, a > binding between Pharo and R using NativeBoost. > You can now call directly your R methods from Pharo: data := (1 to: > 1000) collect: #yourself. res := (#acf asRFunctionWith: {data}) > eval > To use it, you should copy the R libraries near the Pharo VM (see > the documentation on SmalltalkHub to see how to proceed) and I attempted to follow the directions at SmalltalkHub, but the instructions there call for copying some DLLs, and in particular the "grid.dll" is not available in the present R for Win (3.1.2) installation. > Gofer it > smalltalkhubUser: 'VincentBlondeau' project: 'RProjectConnector'; > configuration; > loadStable > > Don't forget to relaunch Pharo after the installatio to > be able to use the connector. After the succesfully install via Gofer, the relaunching of Pharo with the image containing RProjectConnector never starts, and for the worse no messages are availble (even in the stderr file in image directory). [snipped] How can I troubleshooted this? Regards, -- Cesar Rabak

3 2

Announcements & inter-thread communication
by Ben Coman Dec. 16, 2014

Dec. 16, 2014

_BACKGROUND_ In relation to... https://pharo.fogbugz.com/default.asp?13182 "Refactor MCFileRepositoryInspector >> versionSearchAccept:" I am reviewing... https://pharo.fogbugz.com/default.asp?13007 "Cannot integrate a slice with monticello (red square in the UI)" and in general considering how Monticello uses multiple threads to allow you to type in the filter while its downloading info from the remote repository (which would be good to have more of this sort thing). Looking back at build 30814 just prior to slice 13007 being integrated, I notice that MCFileRepositoryInspector>>setRepository:workingCopy: [1] forks and sends #refresh, which sends #changed: #packageList. and MCFileRepositoryInspector>>packageSearchAccept: [2] also forks and sends #changed: #packageList So there were three threads (including UI [3]) modifying object state, which was compounded by #packageList method doing a lot of work. Issue 13007 worked around this by moving the work of #packageList out to #packageListUpdate, and moved the #changed: sends from [1] & [2] also out into #packageListUpdate (and wrapped in a #defer:). _QUESTIONS_ Now I am considering doing the same for issue 13182 #versionSearchAccept:, and considering Pharo's goal is to replace all Dependents/#changed: mechanisms with Announcements. 1. So I am wondering if that would be a better direction to address this? Then I wonder about how Announcements interact with threads. I see that SubscriptionRegistry>>deliver: #protect's the generation of /interestedSubscriptions/, but the actual announcement delivery occurs in the open, in AnnoucemenSubscription>>delvier:, in the sender's thread. So for an example... action := [ :it | self inform: 'removing child'.]. announcer on: RemoveChild do: action. /action/ might be executed from different concurrent threads. Now you might say that the programmer should know enough about the structure of their threaded code to wrap the action in as critical section, but Announcements are a DECOUPLING mechanism, and maybe a THIRD PARTY library subscribes to an Announcement that later someone else wraps in a fork, and no-one notices possible race conditions created. 2. So, is there something reasonable we can do to make the common/easier/safer single-threaded case the default, and make people work a bit harder to shoot themselves in the foot with multiple threads? We could introduce Announcer>>onOtherThread:do: with the purpose of making use of inter-thread announcements more explicit in a self documenting way. Announcements accidentally passed between threads to Announcer>>on:do: would generate an exception advising "use #onOtherThread:do: " with the reasonable expectation that use of #onOtherThread:do: would follow the pattern... announcer onOtherThread: RemoveChild do: [ :it | myMutex critical: [ self inform: 'removing child' ]. ]. With this arrangement, a third party subscribed to someone else's announcement, that is quietly changed to be wrapped by forked thread, the third party's code now fails EARLY and OBVIOUS, rather than letting subtle race conditions occur at random times. _PROPOSED IMPLEMENTATION_ "------------------" Announcer>>subscribe: anAnnouncementClass do: aValuable ^ registry add: ( AnnouncementSubscription new announcer: self; process: Processor activeProcess announcementClass: anAnnouncementClass; valuable: aValuable) "------------------" AnnouncementSubscription>>deliver: anAnnouncement process ~= Processor activeProcess ifTrue: [ self error: [ 'Cross thread announcements should subscribe using #onOtherThread:do: ' ]. ^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [ [action cull: anAnnouncement cull: announcer] on: UnhandledError fork: [:ex | ex pass ]] "------------------" Announcer>>threadedSubscribe: anAnnouncementClass do: aValuable ^ registry add: ( ThreadedAnnouncementSubscription new announcer: self; process: Processor activeProcess announcementClass: anAnnouncementClass; valuable: aValuable) "------------------" where ThreadedAnnouncementSubscription essentially functions the same as the existing AnnoucementSubscription .

3 3

Funny mousedrag behavior over TxText-Morphs
by Nicolai Hess Dec. 15, 2014

Dec. 15, 2014

Open a TxText based application, for example: TxApplicationWithToolbar new openWithSpec now take any other Morphic-window and drag it over the TxText-window. The window dragging movement doesn't follow the mouse movement. nicolai

3 3

ListModel announcer insanity
by Henrik Johansen Dec. 15, 2014

Dec. 15, 2014

I thought I'd fix a small bug following https://pharo.fogbugz.com/f/cases/14604 , the DiffMorphChangeRecordConverters referenceList does not get updated to the new model's list when reverting a method, so after reverting, the left pane will always show (and compare against) the last version, rather than the previous from selected. No problem, as per the discussion of Spec's excessive annoucement wrapping/ValueHolder appetite, let's try do the simple thing and add a small Announcement subscription, essentially: browser listModel announcer when: ValueChanged send: #updateReferences: to: aConverter. <rant> To my surprise, that did not work. Hmmm, must be a different announcement then, ListChanged maybe. After all, it makes sense that a MultiSelectionInList has multiple events that subscribers might be interested in. So I started looking at ListModel, <insert relevant explicits here>! There are, count them and weep, *32* different NewValueModels instance variables, each with different announcers. In the case I was looking at, in addition to a listHolder inst var (a CollectionValueHolder), there's a listAnnouncer inst var (an Announcer), so just finding the one through which announcements are made is next to impossible (with the ListModel's own announcer, that's three different ones that would potentially make sense), at least without consulting the *offical* API; #whenListChanged: Turns out, in the current implementation, listAnnouncer is the one I want. Which isn't exposed through an accessor, so you can't even use it to subscribe directly. Yay. </rant> If someone has time to restructure this, I would like to suggest changing the internals radically; - Introduce new Announcement types for all the different Value holders that make sense (SelectionChanged, ListChanged), and drop the rest. I mean, whenSortingBlockChanged: ?? Who on earth would be interested in that, and not already respond to ListChanged (or it's current equivalent) - Reduce the amount of announcers to a saner number, say, 1 (or, in a pinch, 2). Cheers, Henry

3 5

[pharo-project/pharo-core]
by GitHub Dec. 15, 2014

Dec. 15, 2014

Branch: refs/tags/40416 Home: https://github.com/pharo-project/pharo-core

1 0