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

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

FastTableModel switched from default single-select to multi

by Stephan Eggermont

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. 12, 2017

Nice library looking for clever developers for little chat and lovely documentation

by stepharong

Hi guys I realized that value: valueWithPossibleArguments: cull: and others supernice messages do not have the method comments they deserved. cull: anArg ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg] => I started https://pharo.fogbugz.com/f/cases/19689/Add-method-comments-to-cool-block-m… cull: anArg "Execute the receiver with one or zero arguments depending on the receiver number of required arguments." "([ 12 ] cull: 13) >>> 12 " "([:x | x + 12] cull: 3) >>> 15 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg] Any takers? because it would be really nice to say to newcomers that our core libraries are super cool. Stef

Feb. 12, 2017

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

by stepharong

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. Stef > Le 12/02/2017 Ã 11:53, Ben Coman a Ã©crit : >> >> Well spotted. They should be consistent. I guess the next questions >> are; >> * Does Glamour convert cross platform Meta-x definitions to platform >> specific in its rendering? Or are the Ctrl-xx hard coded? > > GLMAction comes with a method to render a print representation of shor > tcut, but it is not its responsibility to do so. It is the short cut > responsibility, so other widget can also use the same and consistent > print representation. > > The responsability should go to instance of KMModifiedKeyCombination, > not sure about that though. > > The way the modifier is selected in the GLamour looks strange, why not > using the modifier instance? > > >> * If the former, can Spec be made to do the same conversion for its >> rendering? >> * Or do we prefer to refer to the general Meta-x throughout the UI? > > > The way short cuts are rendered in menu or tool tip is not consistent. > In Nautilus you have for example: 'Ctrl + A', in debugger it is rendered > 'ctrl+a' for Ctrl-a or 'ctrl+shift+a' for Ctrl-A. > In playground you can see both depending on you are viewing a menu or a > button tool tip. > > Now I see another place where short cut gets a print representation: > MorphicMenuItemAdapter>>shortcutText > > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

Re: [Pharo-dev] inspector performance improvement

by phil＠highoctane.be

Any chance for this to run on a 5.0? 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. 12, 2017

[QA] Re: GLMAction and PharoShortcut

by Hilaire

Le 12/02/2017 Ã 11:53, Ben Coman a Ã©crit : > > Well spotted. They should be consistent. I guess the next questions are; > * Does Glamour convert cross platform Meta-x definitions to platform > specific in its rendering? Or are the Ctrl-xx hard coded? GLMAction comes with a method to render a print representation of shor tcut, but it is not its responsibility to do so. It is the short cut responsibility, so other widget can also use the same and consistent print representation. The responsability should go to instance of KMModifiedKeyCombination, not sure about that though. The way the modifier is selected in the GLamour looks strange, why not using the modifier instance? > * If the former, can Spec be made to do the same conversion for its > rendering? > * Or do we prefer to refer to the general Meta-x throughout the UI? The way short cuts are rendered in menu or tool tip is not consistent. In Nautilus you have for example: 'Ctrl + A', in debugger it is rendered 'ctrl+a' for Ctrl-a or 'ctrl+shift+a' for Ctrl-A. In playground you can see both depending on you are viewing a menu or a button tool tip. Now I see another place where short cut gets a print representation: MorphicMenuItemAdapter>>shortcutText -- Dr. Geo http://drgeo.eu

Feb. 12, 2017