- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Working with critiques in Calypso

by Denis Kudriashov

I commit new stable version. Now browser plugins can decorate any tool (which can be created by other plugins). I found that annotating text by class or package takes too long time. So I disable it. Look at implementors of #annotateTextWithCritiquesOf: to enable it and to see the problem. QA plugin morph still not works when it is built in background. (it hangs on "updating critiquies") 2017-01-31 9:52 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-01-30 15:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> You will see new Calypso-Plugins-Critic-Browser package. I add decorators >> support to TextEditorTool. And critic plugin just adds CriticDecorator into >> required tools. >> Sadly it is not working. Critiques are not shown somehow. >> I leave it for you to fix it. Probably reason is that full tool morph is >> prepared in background. So critiques are added when morph is not in World. >> I hope you can find solution. >> > > And to get working critiques disable background tabs: > > ClyBrowserTabTool>>addInto: aBrowser > containerTab := TabMorph > label: self defaultTitle > icon: self defaultIcon > morph: self. > self build. > containerTab when: #tabDeleted send: #tabDeleted to: self. > containerTab model: self. > aBrowser addTab: containerTab > > So question why it is not working when morph is built from background > process? >

Feb. 13, 2017

RGMethodDefinition>>gtInspectorSourceIn: does not refresh on <accept>

by Ben Coman

Anyone know if the following bug has been logged previously? I've had a quick search and not found anything. 1. #hierarchyButtonAction: inspect 2. Select [Implementors] tab. 3. Select [Source tab] 4. Edit method, the yellow dirty mark shows in the corner 5. Accept edit e.g. <Ctrl-S> ==> nothing seems to happen. The method still shows dirty, ==> but if you select [Senders] tab and back to [Source] tab ==> you see the method *was* saved. cheers -ben P.S. Its really cool to be able to edit the method here. I'm using halos to dive into a PluggableToggleButtonMorph (e.g. <Hier>) then selecting the actionSelector > Implementors > Source and insert a halt.

Feb. 13, 2017

Re: [Pharo-dev] FastTableModel switched from default single-select to multi

by Andrei Chis

Is this in the Glamour model or in the Spec one? If it's the glamour one I made some changes to the Glamour one but I don't remember changing the default to multiple selection. Maybe it's a bug :) Cheers, Andrei On Mon, Feb 13, 2017 at 12:38 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Breaking all code that expects selectedItem to be not-nil. > Is that wanted behaviour? I noticed it broke SpecGenerator. > I have no strong opinion on this, and welcome all Spec progress. > > Stephan > >

Feb. 13, 2017

Re: [Pharo-dev] inspector performance improvement

by Andrei Chis

On Sun, Feb 12, 2017 at 5:07 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Any chance for this to run on a 5.0? There are two main changes: moved inspector to fast table and some fixes in the glamour renderer. Moving the changes for the glamour renderer should be straightforward. I can point you to the list of relevant commits if you want to make a slice (We'll just need afterwards to also update ConfigurationOfGlamourCore to still work for Pharo 5) The FastTable changes could require more work but that should also be doable. However, now we still have some issues to fix there so that's not done for the moment. Cheers, Andrei > > Phil > > On Sun, Feb 12, 2017 at 3:13 PM, stepharong <stepharong(a)free.fr> wrote: >> >> Great job!!!! >> It feels lot snappier :) >> Now it is a real pleasure to navigate objects. >> This is nice to see that you are paying attention because the engine is >> getting faster and this is important >> that the tools do not eat all the power by accident. >> Tx a lot >> >> >> On Sat, 11 Feb 2017 21:31:56 +0100, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> Hi, >>> >>> Andrei and Alex did a great job at improving the performance and >>> scalability of the inspector. >>> >>> There are a couple of main improvements: >>> - Added FastTable support for the Raw presentation for all objects. This >>> implied completing the support for the tree presentation binding to fast >>> table. >>> - Moved the Items presentation for collections to FastTable. >>> - Improved the rendering of Glamour to no longer rely on the default >>> Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers a >>> relayout of the morph, even if it is not visible. We extended PanelMorph in >>> the context of Glamour with a less needy logic. >>> >>> I will not tell you how fast it is. I would rather want you to play with >>> it :). >>> >>> The change is already in the Moose image. It is not yet in Pharo, but it >>> will be soon. In the meantime you can be load it in Pharo 6 like this: >>> >>> Gofer new >>> smalltalkhubUser: 'Moose' project: 'GToolkit'; >>> package: 'ConfigurationOfGToolkitCore'; >>> load. >>> (#ConfigurationOfGToolkitCore asClass project version: #stable) >>> load >>> >>> To play with it, try this with both the current version and the new one >>> and the Spec Inspector if you want (just make sure you save the image >>> beforehand): >>> >>> collection := (1 to: 100000000) asArray. >>> [collection inspect] timeToRun. >>> >>> collection := (1 to: 100000000). >>> [collection inspect] timeToRun. >>> >>> (for these two ones notice that Items do not appear at all in the old >>> implementation) >>> >>> [World inspect] timeToRun. >>> >>> >>> There are still a couple of issues open, such as the sorting of the >>> columns. We would need your help with testing this, and report possible >>> missing issues. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Obvious things are difficult to teach." >>> >>> >>> >>> >>> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >

Feb. 13, 2017

Re: [Pharo-dev] Pharo wiki

by Alistair Grant

Hi Stef, On 13 February 2017 at 01:17, stepharong <stepharong(a)free.fr> wrote: > remember that we have this > > http://pharo.gemtalksystems.com > > stef But write access requires an account (according to http://pharo.gemtalksystems.com/book/Contribute/ContributeToPharoBook) I requested an account last year (10 May 2016 to pharo-dev) and didn't get a response. Cheers, Alistair > On Sat, 11 Feb 2017 23:22:11 +0100, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > > I try to use StackOverflow documentation to document some Pharo stuff. Itâs > very limited, but it has all the collaborative stuff from StackOverflow, so > somehow I believe there is less effort needed to manage permissions. > > Uko > > On 10 Feb 2017, at 21:14, philippe.back(a)highoctane.be > <philippe.back(a)gmail.com> wrote: > > I miss the Squeak wiki Pharo style. > > Phil > > Le 10 fÃ©vr. 2017 19:06, "Esteban A. Maringolo" <emaringolo(a)gmail.com> a > Ã©crit : >> >> 2017-02-10 14:59 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> > Mass adoption and hyper reduced friction to get people on board. >> > >> > For me: I have 10+ slack teams in my slack client and there is really no >> > point in having more clients on the desktop. >> >> +1 to this. This is key. >> >> Maybe what we're missing is a simple wiki to collect the shared >> knowledge, recipes, and other stuff. >> >> >> Esteban A. Maringolo

Feb. 13, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 6 February 2017

by Norbert Hartl

> Am 13.02.2017 um 09:38 schrieb estebanlm(a)gmail.com: > > Hello! > > This is my weekly ChangeLog, from 6 February 2017 to 12 February 2017. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/2/2017&to=12/2/2017 > > ChangeLog > ========= > > 9 February 2017: > ---------------- > > * I finished the work started yesterday and now there is a [Pull Request](https://github.com/npasserini/iceberg/pull/276) > enabling the use of SSH for iceberg :) > > > 8 February 2017: > ---------------- > > * I worked with Pablo on *iceberg*, in [issue 275](https://github.com/npasserini/iceberg/issues/275) (enable > use of ssh-agent). It is very important to provide an easy way to use the tool (otherwise you need to provide > your username/password, and there is people who do not like this). > Yes, that's right. Thanks again for this. It turned me into an iceberg user finally ;) Norbert > After one afternoon of hard work, we now have an "almost" working version, as you can see > [here](https://github.com/estebanlm/iceberg/commits/dev-0.4) > This thing in fact should be working, but there are still some UI missing stuff and it is not validated on > other platforms (linux and windows)... ut it 'should' work... we'll see tomorrow :) > > > 7 February 2017: > ---------------- > > * I'm working on restore the testing of VM builds, and so far linux tests are passing. There are some problems > in macOS (probably due to missing chunks when performing the merge), and windows is still not tested at all. > > So, I will work tomorrow on those to see if we can have finished the process this week: I need to have a stable > VM to continue with iceberg development (users will need to have a new VM, so better to have it tested :P) > > > 6 February 2017: > ---------------- > > * Working a bit on VM, I integrated a [pull request](https://github.com/pharo-project/pharo-vm/pull/114) that > will enhance the build process in linux platforms. > > This was submited by [Holger](https://github.com/zecke), and is part of his work to create VM package versions. > > > cheers! > Esteban >

Feb. 13, 2017

Re: [Pharo-dev] [QA] Re: GLMAction and PharoShortcut

by Hilaire

Ok got it. It will be great to clarify the keymap implementation and use, both for QA reasons and developers. What is the status of the KM hierarchy? Hilaire Le 12/02/2017 Ã 18:51, stepharong a Ã©crit : > For the record we were discussing with denis to have a hierarchy of > command each one encapsulating its > shortcut and other. > Now it should work for calypso and we will remove Nautilus in 70. But > the problem is all the places > where shortcuts are hardcoded and we will have to work on them. > > Now I'm not saying that we should not do anything now to fix the current > problem. > I just mention our current thoughts. -- Dr. Geo http://drgeo.eu

Feb. 13, 2017

Esteban's ChangeLog week of 6 February 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 6 February 2017 to 12 February 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/2/2017&to=12/2/2017 ChangeLog ========= 9 February 2017: ---------------- * I finished the work started yesterday and now there is a [Pull Request](https://github.com/npasserini/iceberg/pull/276) enabling the use of SSH for iceberg :) 8 February 2017: ---------------- * I worked with Pablo on *iceberg*, in [issue 275](https://github.com/npasserini/iceberg/issues/275) (enable use of ssh-agent). It is very important to provide an easy way to use the tool (otherwise you need to provide your username/password, and there is people who do not like this). After one afternoon of hard work, we now have an "almost" working version, as you can see [here](https://github.com/estebanlm/iceberg/commits/dev-0.4) This thing in fact should be working, but there are still some UI missing stuff and it is not validated on other platforms (linux and windows)... ut it 'should' work... we'll see tomorrow :) 7 February 2017: ---------------- * I'm working on restore the testing of VM builds, and so far linux tests are passing. There are some problems in macOS (probably due to missing chunks when performing the merge), and windows is still not tested at all. So, I will work tomorrow on those to see if we can have finished the process this week: I need to have a stable VM to continue with iceberg development (users will need to have a new VM, so better to have it tested :P) 6 February 2017: ---------------- * Working a bit on VM, I integrated a [pull request](https://github.com/pharo-project/pharo-vm/pull/114) that will enhance the build process in linux platforms. This was submited by [Holger](https://github.com/zecke), and is part of his work to create VM package versions. cheers! Esteban

Feb. 13, 2017

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

by phil＠highoctane.be

First option is clean but there is no way to get the surface back to do further things. Second keeps the surface around and this is pretty useful and the class name implies there is something about Athens in there. Now can't we have it both ways? By default it is the second option but when we, say, #withoutCairoDependency, we get the version 1 executed. and a #isCairoIndependent testing thing. anAthensCairoSurfaceForm asForm withoutCairoDependency -> aMundaneForm Phil On Mon, Feb 13, 2017 at 1:48 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi, > > How about changing AthensCairoSurface >> asForm into the following > definition?: > asForm > > "create a form and copy an image data there" > | form | > self checkSession. > > self flush. > form := Form extent: (self width@self height) depth: 32. > form unhibernate. > LibC memCopy: self getDataPtr to: form bits size: self width*self > height*4. > ^ form > > This involves a whole copy, but it removes completely the dependency on > the surface plugin. > > If we want to keep using the surface plugin with Cairo, the old definition > of asForm still has a bug, which can be reproduced with the following > snippet: > > Smalltalk compiler evaluate: ' > | surface | > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > ' > > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected. The solution to > that problem, is the following (attached): > asForm > > "create a form and copy an image data there" > self checkSession. > > self flush. > ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 > bits: id) > surface: self; > yourself > > Where AthensCairoSurfaceForm(attached) is just a subclass of Form, that > holds a reference to the surface object that manages the lifetime of the > pixels referenced by the bits in the form. By having an extra reference to > the surface, we can prevent the finalization of it, until is not being > referenced by a form that uses its storage. > > Best regards, > Ronie > > 2016-12-21 5:27 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> would be possible to have one of your crashing images? >> so I can testâ¦ because one of my problems is that Iâm not able to >> reproduce the problem when I try, and is hard to fix blindly... >> >> Esteban >> >> > On 21 Dec 2016, at 08:09, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> > >> > I had plenty of elements in my Roassal visualization, and on some point >> it just crashed. >> > I have the impression that having many elements and / or animations (as >> in the case of Johan Fabry) triggers the crash. >> > >> > Alexandre >> > >> > >> >> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >> >> >> So what was your crash problem? >> >> >> >> >> >> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> so did it work? >> >>> Is there something that we should do? >> >> >> >> I had no problem, but as Henrik and Peter said, the problem is likely >> to be more complex >> >> >> >> Alexandre >> >> >> >> >> >>> >> >>> On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> Okay, tryingâ¦ >> >>> >> >>> Alexandre >> >>> >> >>> >> >>>> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >> >>>> >> >>>> According to crash.dmp TRMorph>drawOn: draws an image using >> FormCanvas>>#image:at:sourceRect:rule: at a coordinate represented by a >> Float point. >> >>>> Try to round it to integer point. >> >>>> >> >>>> Cheers, >> >>>> Alex >> >>>> >> >>>> On 16 December 2016 at 16:34, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>>> Hi! >> >>>> >> >>>> Vincent and I are experiencing many crashes from GrafPort>copyBits. >> It crashes every couple of minutes. >> >>>> >> >>>> I know that not much can be done so far. Stability is my biggest >> concern with Pharo :-( >> >>>> I use the latest VM. >> >>>> >> >>>> Cheers, >> >>>> Alexandre >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>>> Alexandre Bergel http://www.bergel.eu >> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Moose-dev mailing list >> >>>> Moose-dev(a)list.inf.unibe.ch >> >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >>>> >> >>>> >> >>> >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> >

Feb. 13, 2017

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

by Ronie Salgado

Hi, How about changing AthensCairoSurface >> asForm into the following definition?: asForm "create a form and copy an image data there" | form | self checkSession. self flush. form := Form extent: (self width@self height) depth: 32. form unhibernate. LibC memCopy: self getDataPtr to: form bits size: self width*self height*4. ^ form This involves a whole copy, but it removes completely the dependency on the surface plugin. If we want to keep using the surface plugin with Cairo, the old definition of asForm still has a bug, which can be reproduced with the following snippet: Smalltalk compiler evaluate: ' | surface | surface := AthensCairoSurface extent: 640@480. surface drawDuring: [ :canvas | surface clear: Color blue. ]. surface asForm asMorph openInWindow ' The problem with asForm, is that the form returned can be used after the cairo surface which holds the pixels is garbage collected. The solution to that problem, is the following (attached): asForm "create a form and copy an image data there" self checkSession. self flush. ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 bits: id) surface: self; yourself Where AthensCairoSurfaceForm(attached) is just a subclass of Form, that holds a reference to the surface object that manages the lifetime of the pixels referenced by the bits in the form. By having an extra reference to the surface, we can prevent the finalization of it, until is not being referenced by a form that uses its storage. Best regards, Ronie 2016-12-21 5:27 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > would be possible to have one of your crashing images? > so I can testâ¦ because one of my problems is that Iâm not able to > reproduce the problem when I try, and is hard to fix blindly... > > Esteban > > > On 21 Dec 2016, at 08:09, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > I had plenty of elements in my Roassal visualization, and on some point > it just crashed. > > I have the impression that having many elements and / or animations (as > in the case of Johan Fabry) triggers the crash. > > > > Alexandre > > > > > >> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> > >> So what was your crash problem? > >> > >> > >> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >>> so did it work? > >>> Is there something that we should do? > >> > >> I had no problem, but as Henrik and Peter said, the problem is likely > to be more complex > >> > >> Alexandre > >> > >> > >>> > >>> On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >>> Okay, tryingâ¦ > >>> > >>> Alexandre > >>> > >>> > >>>> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >>>> > >>>> According to crash.dmp TRMorph>drawOn: draws an image using > FormCanvas>>#image:at:sourceRect:rule: at a coordinate represented by a > Float point. > >>>> Try to round it to integer point. > >>>> > >>>> Cheers, > >>>> Alex > >>>> > >>>> On 16 December 2016 at 16:34, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >>>> Hi! > >>>> > >>>> Vincent and I are experiencing many crashes from GrafPort>copyBits. > It crashes every couple of minutes. > >>>> > >>>> I know that not much can be done so far. Stability is my biggest > concern with Pharo :-( > >>>> I use the latest VM. > >>>> > >>>> Cheers, > >>>> Alexandre > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev(a)list.inf.unibe.ch > >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >>>> > >>>> > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >>> > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Feb. 13, 2017