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

Trigger Jenkins from Fogbugz?

by Ben Coman

It seems the CI monkey polls Fogbugz for cases at 15 minute intervals. Now if I'm troubleshooting a submitted slice, it would be nice to have a quicker turnaround. Any chance Fogbugz could be configured for a "case resolved" event to trigger a the CI to poll Fogbugz... http://www.fogcreek.com/fogbugz/docs/70/topics/plugins/URLTrigger.html https://github.com/jenkinsci/fogbugz-plugin/blob/master/URLTRIGGER.rst https://www.fogcreek.com/fogbugz/plugins/plugin.aspx?ixPlugin=5 This would help speed some development cases. cheers -ben

Dec. 16, 2014

Re: [Pharo-dev] [ANN] RProjectConnector V1.0

by csrabak＠bol.com.br

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

Dec. 16, 2014

Re: [Pharo-dev] how do you use scripts?

by Sven Van Caekenberghe

> On 12 Dec 2014, at 12:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > As input for designing new features that better support scripting in Pharo, we would benefit from a bit more input around the role scripts play in your development life. > > To this end, I would like to invite you to share your scripting experience. Here are some questions to start from, but feel free to diverge: Every image that I am working in for some time contains multiple open workspaces that I need and depend on, that I dare not close because they might contain important stuff. > - What kind of actions do you put in scripts? Starting points for coding, exploring, starting/stopping services, loading code, generally useful expressions, snippets of code that will evolve in something else later on. > - Do you rely on script files stored on the disk at all? Not really, but I tried (both using save/load and ScriptManager) - I think the extra step is too much, a permanent workspace in an image is so much easier. > - Where do you store your scripts (in one folder, in many folders)? Just next to the image, mostly. But I tried structured saving with ScriptManager. > - Do you version your scripts? No > - Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file? Both > - Do you rely on the names of the scripts? If there are names, yes. > - Why do you use a script file and not a class? Some tools end up as class methods, if not real code. But changing a class (code) is more serious than playing/experimenting/exploring code in a workspace. === One of the things that I do is mail snippets around internally, so that I and others have them in their mailbox for later reference. === We need something very low friction, like automatic saving/remembering. > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 16, 2014

Re: [Pharo-dev] Announcements & inter-thread communication

by Sven Van Caekenberghe

Ben, This is an interesting idea - and an important topic. My main concern, that you seem to share, is that the default case should be as fast as possible and free of locking, as much as possible. (For example, I consider the #mutexForPicking used by #atRandom on Collection to be very silly, since normal access does nothing at all). Have you tried what would happen if you added your safety mechanism ? Would it get tripped in various places already ? Sven PS: BTW, thank you for your enthusiasm for tackling so many difficult/dangerous topics ! > On 06 Dec 2014, at 07:10, Ben Coman <btc(a)openInWorld.com> wrote: > > _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 . > > >

Dec. 16, 2014

Re: [Pharo-dev] Spec TabManager clipping issues

by Tudor Girba

+1 Doru On Tue, Dec 16, 2014 at 7:25 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Thanks (again) ! > > It is really remarkable how fast you can solve all these very diverse bugs. > > > On 16 Dec 2014, at 00:18, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2014-12-15 21:19 GMT+01:00 stepharo <stepharo(a)free.fr>: > > Probably hard coded length instead of asking the fonts. > > > > Le 14/12/14 23:32, Peter UhnÃ¡k a Ã©crit : > >> Hi, > >> > >> there seems to be some weird clipping issue in Spec's tabs. > >> The issue is in Pharo4; Pharo3 works fine. > >> > >> Pharo4: > >> <Mail Attachment.png> > >> â > >> Pharo3: > >> <Mail Attachment.png> > >> â > >> Peter > > > > > > This happens since pharo 40150 (issue 2489) > > bug report and fix at > > 14628 > > Wrong clipping bounds in Morphic widget Tab > > > > nicolai > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 16, 2014

Re: [Pharo-dev] Spec TabManager clipping issues

by Sven Van Caekenberghe

Thanks (again) ! It is really remarkable how fast you can solve all these very diverse bugs. > On 16 Dec 2014, at 00:18, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-12-15 21:19 GMT+01:00 stepharo <stepharo(a)free.fr>: > Probably hard coded length instead of asking the fonts. > > Le 14/12/14 23:32, Peter UhnÃ¡k a Ã©crit : >> Hi, >> >> there seems to be some weird clipping issue in Spec's tabs. >> The issue is in Pharo4; Pharo3 works fine. >> >> Pharo4: >> <Mail Attachment.png> >> â >> Pharo3: >> <Mail Attachment.png> >> â >> Peter > > > This happens since pharo 40150 (issue 2489) > bug report and fix at > 14628 > Wrong clipping bounds in Morphic widget Tab > > nicolai >

Dec. 16, 2014

Re: [Pharo-dev] Funny mousedrag behavior over TxText-Morphs

by Nicolai Hess

2014-12-15 7:21 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > > The drag behavior over text was not inspected. This is feature this have > not overlooked, so expect bumps. > > On 14 December 2014 at 21:14, stepharo <stepharo(a)free.fr> wrote: > >> I do not know exactly the status of the spec version. >> I know that igor got many of problems managing the Morph into a text >> because of circumvoluted morphic erosion of design. >> I know that igor was not happy the way spec wat using text but I do not >> know more than that. >> >> Stef >> >> > > > -- > Best regards, > Igor Stasenko. > TxTextEditorMorph does not check if the hand currently holds a morph for example, in Morph or TextMorph Morph>>#handleMouseMove: ... (anEvent hand hasSubmorphs) ifTrue:[^self]. ... it explicitly returns without further action, if the hand drags an object. This is missing for TxTextEditorMorph

Dec. 15, 2014

Re: [Pharo-dev] Spec TabManager clipping issues

by Nicolai Hess

2014-12-15 21:19 GMT+01:00 stepharo <stepharo(a)free.fr>: > > Probably hard coded length instead of asking the fonts. > > Le 14/12/14 23:32, Peter UhnÃ¡k a Ã©crit : > > Hi, > > there seems to be some weird clipping issue in Spec's tabs. > The issue is in Pharo4; Pharo3 works fine. > > Pharo4: > > â > Pharo3: > > â > Peter > > > This happens since pharo 40150 (issue 2489) bug report and fix at 14628 <https://pharo.fogbugz.com/default.asp?14628> Wrong clipping bounds in Morphic widget Tab nicolai

Dec. 15, 2014

Re: [Pharo-dev] ListModel announcer insanity

by stepharo

Le 15/12/14 22:07, phil(a)highoctane.be a Ã©crit : > > > On Mon, Dec 15, 2014 at 9:21 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Nautilus is not using Spec. > > > My mistake. > > It uses tons of announcements... yes far too many. I'm writing a kind of roadmap for spec now and reading again the code because I fall apart :) > > Phil > > And yes we need to do a pass on it and simplify it. > > Stef > > Le 15/12/14 14:54, phil(a)highoctane.be <mailto:phil@highoctane.be> > a Ã©crit : >> >> >> Le 15 dÃ©c. 2014 13:00, "Henrik Johansen" >> <henrik.s.johansen(a)veloxit.no >> <mailto:henrik.s.johansen@veloxit.no>> a Ã©crit : >> > >> > 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). >> >> Yeah there are "Announcement storms" going on with Spec based >> tools. I think that it explains a lot of the sluggishness of some >> tools, like Nautilus. >> >> I saw these when doing some Nautilus plug-ins for my own use >> (e.g. bring back the original senders/implementors... buttons). >> >> Squeak tools feel very very snappy in comparison. Even on a >> superfast PC, Pharo as some annoying delays. >> >> Announcements are great but overusing them is receipe for serious >> head scratching and does not lend itself to easy discoverability >> of how things do work. >> >> Phil >> Phil >> >> > >> > Cheers, >> > Henry >> > > > > -- > --- > Philippe Back > Visible Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be <mailto:Mail%3Aphil@highoctane.be> | Web: > http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX > Value Added Reseller >

Dec. 15, 2014

Re: [Pharo-dev] ListModel announcer insanity

by phil＠highoctane.be

On Mon, Dec 15, 2014 at 9:21 PM, stepharo <stepharo(a)free.fr> wrote: > > Nautilus is not using Spec. > My mistake. It uses tons of announcements... Phil > And yes we need to do a pass on it and simplify it. > > Stef > > Le 15/12/14 14:54, phil(a)highoctane.be a Ã©crit : > > > Le 15 dÃ©c. 2014 13:00, "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> a > Ã©crit : > > > > 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). > > Yeah there are "Announcement storms" going on with Spec based tools. I > think that it explains a lot of the sluggishness of some tools, like > Nautilus. > > I saw these when doing some Nautilus plug-ins for my own use (e.g. bring > back the original senders/implementors... buttons). > > Squeak tools feel very very snappy in comparison. Even on a superfast PC, > Pharo as some annoying delays. > > Announcements are great but overusing them is receipe for serious head > scratching and does not lend itself to easy discoverability of how things > do work. > > Phil > Phil > > > > > Cheers, > > Henry > > > -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Dec. 15, 2014