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

Re: [Pharo-dev] Changing a field value with GtInspector

by Stephane Ducasse

Andrei told me that shift + click is working. On Mon, Apr 3, 2017 at 2:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This was present before we moved to FastTable. > > With the move some things did not make it in the integration, and editing > the value is still on the to do list. > > Doru > > > > On Apr 2, 2017, at 3:33 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Hi > > > > May be I'm blind but I do not see how > > we can change a value of an instance variable with gtInspector. > > In the old inspector we could just type it and press accept. > > When will we get this behavior? > > Stef > > -- > www.tudorgirba.com > www.feenk.com > > "Every now and then stop and ask yourself if the war you're fighting is > the right one." > > > > > >

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Esteban Lorenzano

> On 4 Apr 2017, at 12:31, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 4 Apr 2017, at 12:29, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >>> On Apr 3, 2017, at 9:00 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> Hello, >>> >>> This are the things I believe still needs to be solved to be able to release Pharo 6.0: >>> >>> VM: >>> === >>> - win32, cairo fonts problem (I submitted a new VM to test, I think this is fixed :P) >> >> Does this mean that on Mac the 32bit VM should not crash when working with Athens and Roassal? >> >> What about the 64bit? > > there is no win64 bits pharo version missread :) yes it shouldnât. Athens 64 should workâ¦ still not tested intensively, TBHâ¦ but the tiger demo was working :) Roassal is responsibility of âroassalersâ :P (but they may find athens problems, which Iâm eager to hear). Esteban > > Esteban > >> >> Cheers, >> Doru >> >> >> >>> - make all tests pass (there are still some failing tests when compiling a new VM)/. >>> - libgit2: Still not there, Jan and Ben were trying and sent some suggestions but I still didnât had the time to test it. >>> Image: >>> ===== >>> >>> - iceberg still needs to go inside the image, Iâm running to release version 0.4 (maybe this week?) and then we can integrate. >>> - I'm still convinced there is a leak. I need to check this in detail. And of course some help on thisâ¦ Pavel?â¦ would be cool :) >>> >>> List is a lot smaller now :) >>> If everything goes well, we can target to release next week. >>> >>> Next: >>> - Test the new process and tape some videos explaining how we will contribute with a bootstrapped process using github :) >>> >>> cheers! >>> Esteban >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://www.feenk.com/> >> >> "To lead is not to demand things, it is to make them happen." >

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Esteban Lorenzano

> On 4 Apr 2017, at 12:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Apr 3, 2017, at 9:00 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> Hello, >> >> This are the things I believe still needs to be solved to be able to release Pharo 6.0: >> >> VM: >> === >> - win32, cairo fonts problem (I submitted a new VM to test, I think this is fixed :P) > > Does this mean that on Mac the 32bit VM should not crash when working with Athens and Roassal? > > What about the 64bit? there is no win64 bits pharo version Esteban > > Cheers, > Doru > > > >> - make all tests pass (there are still some failing tests when compiling a new VM)/. >> - libgit2: Still not there, Jan and Ben were trying and sent some suggestions but I still didnât had the time to test it. >> Image: >> ===== >> >> - iceberg still needs to go inside the image, Iâm running to release version 0.4 (maybe this week?) and then we can integrate. >> - I'm still convinced there is a leak. I need to check this in detail. And of course some help on thisâ¦ Pavel?â¦ would be cool :) >> >> List is a lot smaller now :) >> If everything goes well, we can target to release next week. >> >> Next: >> - Test the new process and tape some videos explaining how we will contribute with a bootstrapped process using github :) >> >> cheers! >> Esteban > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "To lead is not to demand things, it is to make them happen."

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Tudor Girba

Hi, > On Apr 3, 2017, at 9:00 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hello, > > This are the things I believe still needs to be solved to be able to release Pharo 6.0: > > VM: > === > - win32, cairo fonts problem (I submitted a new VM to test, I think this is fixed :P) Does this mean that on Mac the 32bit VM should not crash when working with Athens and Roassal? What about the 64bit? Cheers, Doru > - make all tests pass (there are still some failing tests when compiling a new VM)/. > - libgit2: Still not there, Jan and Ben were trying and sent some suggestions but I still didnât had the time to test it. > Image: > ===== > > - iceberg still needs to go inside the image, Iâm running to release version 0.4 (maybe this week?) and then we can integrate. > - I'm still convinced there is a leak. I need to check this in detail. And of course some help on thisâ¦ Pavel?â¦ would be cool :) > > List is a lot smaller now :) > If everything goes well, we can target to release next week. > > Next: > - Test the new process and tape some videos explaining how we will contribute with a bootstrapped process using github :) > > cheers! > Esteban -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Denis Kudriashov

2017-04-04 10:40 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > The undeclared mechanism is regularly used e.g. during loading of > packages. So if we will do something like this, rather not for Pharo 6 :-) Yes, But I am talking about runtime behaviour. It of course could fails kind of post load actions/initialization. But they will anyway fail (maybe silently) if expected variable is undeclared

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Pavel Krivanek

2017-04-04 10:31 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-04-04 10:15 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> >> initialize >> super initialize. >> noBindingBlock := [ objectSpace nilObject ] >> >> because noBindingBlock was undeclared, it created a reference from >> globals (Undeclared) to a particular context with all mess it referenced. >> > > I think system should at least skip assignment to undeclared variable. So > it should never store any value. But better would be raise error on > assignment. So user will immediately see where is a problem. > The undeclared mechanism is regularly used e.g. during loading of packages. So if we will do something like this, rather not for Pharo 6 :-) -- Pavel

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Denis Kudriashov

2017-04-04 10:15 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > initialize > super initialize. > noBindingBlock := [ objectSpace nilObject ] > > because noBindingBlock was undeclared, it created a reference from globals > (Undeclared) to a particular context with all mess it referenced. > I think system should at least skip assignment to undeclared variable. So it should never store any value. But better would be raise error on assignment. So user will immediately see where is a problem.

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Pavel Krivanek

2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hello, > > This are the things I believe still needs to be solved to be able to > release Pharo 6.0: > > VM: > === > - win32, cairo fonts problem (I submitted a new VM to test, I think this > is fixed :P) > - make all tests pass (there are still some failing tests when compiling a > new VM)/. > - libgit2: Still not there, Jan and Ben were trying and sent some > suggestions but I still didnât had the time to test it. > > Image: > ===== > > - iceberg still needs to go inside the image, Iâm running to release > version 0.4 (maybe this week?) and then we can integrate. > - I'm still convinced there is a leak. I need to check this in detail. And > of course some help on thisâ¦ Pavel?â¦ would be cool :) > I have found one memory leak related to subscription type mixing: https://pharo.fogbugz.com/f/cases/19911 Then I had here a really huge image with 1.2 GB with all known memory leaks solved. It was leaking because of Undeclared, after cleaning of them (Undeclared removeUnreferencedKeys) it shrinked to 59 MB. In this particular case it was caused by code like this: initialize super initialize. noBindingBlock := [ objectSpace nilObject ] because noBindingBlock was undeclared, it created a reference from globals (Undeclared) to a particular context with all mess it referenced. Not sure if we should make some action like clean Undeclared before every snapshot. But the case like this is quite obscure and the information that people should beware it should be enough. Cheers, -- Pavel > List is a lot smaller now :) > If everything goes well, we can target to release next week. > > Next: > - Test the new process and tape some videos explaining how we will > contribute with a bootstrapped process using github :) > > cheers! > Esteban >

April 4, 2017

Re: [Pharo-dev] ListModel Menu

by Guillermo Polito

Hi Jonathan, If you check users of MenuModel and ListModel in the image, you get a few results that could give you an idea of how to do it. For example: If you look for users of MenuModel you arrive to EpSelection>>filtersSubMenu, which will lead you to EpSelection>>populateMenu: aMenu. And this leads you to: EpSelection >> initializeItemsModel itemsModel multiSelection: true; displayBlock: [ :item | item asMorph ]; childrenBlock: [ :item | self childrenItemsOf: item ]; whenSelectedItemsChanged: [ :selectedItems | self refreshEntryContentModelWith: selectedItems. itemsModel menu: [ :aMenu | self selection populateMenu: aMenu ] ]. So apparently, the method #menu: receives a block with a menu as argument, and you have to populate it with elements. Another way to arrive to the same conclusion is to look for senders of #menu:. There you see for example: ChangeSorterApplication >> initializeWidgets ... methodsListModel menu: [:menu :shifted | self messageMenu: menu shifted: shifted ]. changesListModel menu: [:aMenu :shifted | self changeSetMenu: aMenu shifted: shifted ]. classesListModel menu: [:aMenu :shifted | self classMenu: aMenu shifted: shifted ]. ... Cheers, Guille On Mon, Apr 3, 2017 at 6:44 PM, Jonathan Khalil <jonathan(a)esp.sn> wrote: > I did it perfectly with a toolbar. > > Jonathan > > 2017-04-03 16:16 GMT+02:00 Jonathan Khalil <jonathan(a)esp.sn>: > >> Hello, >> >> I am testing the MenuModel and ListModel widgets. I wanted to create a >> popup menu and then set it with the ListModel >> menu: method. It runs >> right but once the listmodel open, when i right click on one item to see >> the pop-up menu it gives me the error as in the "#error.png" picture. >> Here is my example test (based on not significant data): >> >> [ >> >> menu := MenuModel new. >> menu addGroup: [ :group | >> group addItem: [ :item | >> item name: 'item1'; >> icon: (self iconNamed: #nautilus); >> action: [ anyAction1 ]]]; >> addGroup: [ :group | >> group addItem: [ :item | >> item name: 'item2'; >> icon: (self iconNamed: #smallSaveAs); >> action: [ anyAction2 ]]]; >> addGroup: [ :group | >> group addItem: [ :item | >> item name: 'item3'; >> icon: (self iconNamed: #smallAuthoringTools); >> action: [ anyAction4 ]]]. >> ll := LinkedList new. >> ll add: 'value1'; >> add: 'value2'; >> add: 'value3'; >> add: 'value4'; >> add: 'value5'; >> yourself. >> lm := ListModel new. >> lm >> items: ll; >> title: 'ListModel Menu Test'. >> *lm menu:menu.* >> lm openWithSpec. >> >> ] >> >> I get that the #cull:cull: message is not understood by my instance of >> MenuModel but i simply call the #menu: method defined in ListModel. Any >> ideas on the problem ? >> > >

April 4, 2017

Survey about the Roassal visualization engine

by Alexandre Bergel

Hi! We are doing a survey about Roassal. Giving about 2 minutes of your time to fill the survey can have a tremendous impact on it. https://goo.gl/forms/zEt7VdkLSYvBG6jf2 Help us improving Roassal :-) The Object Profile team

April 3, 2017