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

Re: [Pharo-dev] Two tables that share the same data source!?

by Stephane Ducasse

Hi Elhamer where can we find the code of the improvements you did on FastTable? Stef On Tue, Aug 8, 2017 at 2:42 AM, Elhamer <abdelkhalekdev(a)gmail.com> wrote: > Hi Alex and thank you for your reply :)) > > Good to know that bloc already supports that, I am definitely moving to work > on/with it after that :)) > > I've never encounter that scenario on a a Pharo package too, but since i was > working on improving FTs, i thought why not!, besides, in apps with multiple > tables, it might be handy to define a single large data source and assign > columns to each table instead of defining a ds for each table, something > like that: > > ```` > |pane table1 table2 ds| > ds:=FTCellSampleDataSource new:10. > table1 := FTTableMorph new > extent: 500@500; > selectionMode: #column; > addColumn: (FTColumn id: 'column1'); > addColumn: (FTColumn id: 'column2'); > addColumn: (FTColumn id: 'column6'); > dataSource: ds; > selectRowIndex: 1; > showFirstRowSelection; > beMultipleSelection; > yourself. > table2 := FTTableMorph new > extent: 500@500; > selectionMode: #column; > addColumn: (FTColumn id: 'column3'); > addColumn: (FTColumn id: 'column4'); > addColumn: (FTColumn id: 'column5'); > dataSource: ds; > selectRowIndex: 1; > showFirstRowSelection; > beMultipleSelection; > layoutInset: 10; > yourself. > pane := Morph new. > pane layoutPolicy: TableLayout new. > pane listDirection: #leftToRight. > pane listCentering: #center. > pane wrapCentering: #center. > pane hResizing: #spaceFill. > pane layoutInset: 10@10. > pane cellInset:10@10. > pane color: Color red. > > pane addMorph: table1. > pane addMorph: table2. > pane openInWindow . > > ``` > <http://forum.world.st/file/n4959160/two_tables_single_ds.png> > > > > > -- > View this message in context: http://forum.world.st/Two-tables-that-share-the-same-data-source-tp4959153p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 9, 2017

metalink injection into closures ?

by Ben Coman

When we execute this... counter "Greeter new counter" | count | count := 0. [100 timesRepeat: [count := count + 1. self inform: count + 1 printString. 2 seconds wait]] forkNamed: 'Count de Money' and in the dubgger correct and save the code we normally get the message... "Method for block not found on stack, can't edit and continue." and I wonder if anything with Metalinks would facilitate inject the corrected bytecode into the Process so that it oculd continue. cheers -ben

Dec. 9, 2017

About margin and 16969

by Stephane Ducasse

Hi henrik I started to rescue your fix on wrong use of rectangle. Then I noticed that you change the height of a margin. We defined it as height ^ self bottom + self top Since we were considering that the height of a margin is the total amount of space around. and you as height ^ self bottom - self top Do you have a strong reason for that? Stef

Dec. 9, 2017

Re: [Pharo-dev] [Moose-dev] [ann] gtmondrian

by StÃ©phane Ducasse

Super super cool. > On 9 Dec 2017, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are happy to announce GT Mondrian, a graph visualization engine built on top of Bloc. > > It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE. > > The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc. > > The solution was to split the typical edge implementation in graph visualization libraries into two distinct concepts: > â¢ Line is an element that draws the connections. > â¢ Edge defines constraints imposed by connections between elements. Can you give an example? BTW doru did you think about having a bloc layer on top of telescope model? Because from that perspective telescope offers a visualisation model while roassal/mondrian like design are more a pen-oriented metaphor. I wanted to do it to learn Bloc but Iâm running against time and trying to flush pilling duties (I want to also release the book that we wrote with luc and olivier and convert the seaside book and and andâ¦.. :( > > Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What's more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span. > > The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo. > > The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here: > https://github.com/feenkcom/gtoolkit <https://github.com/feenkcom/gtoolkit> > > If you download the GT code through Iceberg, the documentation can be experienced live by inspecting: > './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' asFileReference > > > <mondrian-doc.png> > > > > > > Cheers, > The feenk team > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Quality cannot be an afterthought." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 9, 2017

[ann] gtmondrian

by Tudor Girba

Hi, We are happy to announce GT Mondrian, a graph visualization engine built on top of Bloc. It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE. The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc. The solution was to split the typical edge implementation in graph visualization libraries into two distinct concepts: â¢ Line is an element that draws the connections. â¢ Edge defines constraints imposed by connections between elements. Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What's more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span. The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo. The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here: https://github.com/feenkcom/gtoolkit If you download the GT code through Iceberg, the documentation can be experienced live by inspecting: './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' asFileReference Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Dec. 9, 2017

Re: [Pharo-dev] Release: Conveniently browse, deactivate and reactivate halts and breakpoints with the HaltManager

by Stephane Ducasse

Ok I see quite sophisticated. I did not have the time to check. Did you explain this in the class comments? Tx thomas. On Fri, Dec 8, 2017 at 10:57 AM, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > HaltManager proposes the deactivation by metalink even on self halt because > you may want to deactivate the halt without changing the source code and > completely recompiling the method. > > Thomas > > > Le 07/12/2017 Ã 21:00, Stephane Ducasse a Ã©crit : >> >> Thanks Thomas and you put screenshots so this is cool. >> I have a simple question >> if there is only a self halt in the code why you propose to change >> metalinks? >> Stef >> >> On Wed, Dec 6, 2017 at 11:03 AM, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>> >>> Hello, >>> >>> I have developed a package to assist developers managing their halts and >>> breakpoints: HaltManager. >>> >>> HaltManager provides a window showing all the breakpoints and halt >>> messages >>> of the system, and allows one to toggle them on/off with a simple click. >>> Halt messages can also be toggled via source code rewriting. The >>> deactivation/reactivation feature is available in all code browsers, not >>> only in the HaltManager window. >>> >>> It is available here, with installation instructions and pictures: >>> https://github.com/dupriezt/HaltManager >>> >>> Feedback welcome. >>> >>> Cheers, >>> Thomas Dupriez >>> >>> > >

Dec. 9, 2017

Re: [Pharo-dev] Text Indentation in Pharo editor

by Norbert Hartl

> Am 08.12.2017 um 21:24 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Stef, > > Do you get the debugger issue even in a plain Pharo image? > I do Norbert > Doru > > >> On Dec 8, 2017, at 3:40 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> I would love to have Ctrl E and Ctrl A. >> And yes we should not be different for the sake of it. >> For the moment the reason is simple: we are full of work and even more. >> >> FYI: I'm starting at regular crash of the VM and regular superbad >> behavior of the debugger (like hundred of debuggers, like spawing many >> process) >> there is a really bad problem there. >> >> Setf >> >>> On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>>> On 8 December 2017 at 11:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> >>>> Torsten Bergmann wrote >>>>> so we do it with different shortcuts than regular editors >>>> >>>> I wonder if it makes sense to allow the standard shortcut. The current one >>>> is a bit like playing twister ;) >>> >>> >>> We should be different if there is a good reason, >>> but where possible (especially on UI interface) we should align with the >>> majority. >>> I feel this case is the latter. >>> >>> cheers -ben >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give."

Dec. 9, 2017

Re: [Pharo-dev] Text Indentation in Pharo editor

by Tudor Girba

Hi Stef, Do you get the debugger issue even in a plain Pharo image? Doru > On Dec 8, 2017, at 3:40 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I would love to have Ctrl E and Ctrl A. > And yes we should not be different for the sake of it. > For the moment the reason is simple: we are full of work and even more. > > FYI: I'm starting at regular crash of the VM and regular superbad > behavior of the debugger (like hundred of debuggers, like spawing many > process) > there is a really bad problem there. > > Setf > > On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On 8 December 2017 at 11:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Torsten Bergmann wrote >>>> so we do it with different shortcuts than regular editors >>> >>> I wonder if it makes sense to allow the standard shortcut. The current one >>> is a bit like playing twister ;) >> >> >> We should be different if there is a good reason, >> but where possible (especially on UI interface) we should align with the >> majority. >> I feel this case is the latter. >> >> cheers -ben >> >> > -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

Dec. 8, 2017

[Pharo 7.0-dev] Build #373: 20713 Cleanup RBRefactoringChangeTests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #373 was: SUCCESS. The Pull Request #594 was integrated: "20713 Cleanup RBRefactoringChangeTests" Pull request url: https://github.com/pharo-project/pharo/pull/594 Issue Url: https://pharo.fogbugz.com/f/cases/20713 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 8, 2017

[Pharo 7.0-dev] Build #372: 20842-create-clear-image-entry-point-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #372 was: SUCCESS. The Pull Request #592 was integrated: "20842-create-clear-image-entry-point-" Pull request url: https://github.com/pharo-project/pharo/pull/592 Issue Url: https://pharo.fogbugz.com/f/cases/20842 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 8, 2017