- Pharo-dev - lists.pharo.org

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

jenkins and static analysis
by Norbert Hartl Dec. 15, 2014

Dec. 15, 2014

What are the best options at the moment to see the output of lint results in jenkins? Is there something to use with checkstyle or any other tools? I know the repo on http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main <http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main> but I cannot figure out what is the best way to use it. thanks, Norbert

3 3

About Pharo books
by stepharo Dec. 15, 2014

Dec. 15, 2014

Hi guys I spent a couple of days cleaning PharoForTheEntreprise. So do not stress if you chapters are not where they were used to be :). Here is what I did now there are three stages for Chapters: - Limbo (some notes) - WorkInProgress - ReadyForReviews At the end of this flow we are thinking about the following books: - Entreprise Pharo: a Web Perspective (Zinc, Neo.....) - Spec We decided to write a separate little book - Pharo: The Hidden Parts The ideas is to have many little chapters on not common aspects Stef PS: currently doing a pass on Smacc

4 3

WhatsUp from: 2014-12-15 until: 2014-12-31
by seaside＠rmod.lille.inria.fr Dec. 15, 2014

Dec. 15, 2014

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-12-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

1 0