August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] SmartTest - ESUG 2017 - Trailer

by Stephane Ducasse

:) I showed to benoit the GT teaser. Benoit could have put some questions like in yours and indeed this is really nice to get some fun around the award On Fri, Aug 25, 2017 at 8:47 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > The bar is getting higher :) > > Doru > > >> On Aug 24, 2017, at 10:18 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> :) >> Ready for the ESUG innovation award competition. >> >> >> On Thu, Aug 24, 2017 at 6:49 PM, Dimitris Chloupis >> <kilon.alios(a)gmail.com> wrote: >>> lol by far the most funny pharo teaser I have watched and the tool looks >>> extra useful , well done :) >>> >>> On Thu, Aug 24, 2017 at 6:33 PM Benoit Verhaeghe <benoit.verhaeghe(a)inria.fr> >>> wrote: >>>> >>>> Hi everyone, >>>> >>>> I'm glad to present you the trailer of SmartTest for ESUG >>>> https://www.youtube.com/watch?v=jAvfdN2z5-s >>>> >>>> BenoÃ®t Verhaeghe >> > > -- > www.tudorgirba.com > www.feenk.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > >

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Stephane Ducasse

Denis We could have integrated in Pharo roassal years ago and have tabs full of call graphs and others. Now why we did not do it. Someone has to work on UPDATING baselines so that the following equation works. seed + baseline + package + CrossCuttingChange => seed' + baseline' + package' right now we do not have the baseline' and each time we integrate something in the image it loses its metadata. So this is why the ConfigurationOfRB was rotten. Without this behavior we do not want extra new stuff in the system because it kills the modularity of the integrated component and the system. Stef On Sat, Aug 26, 2017 at 5:41 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi doru > > This is cool. Now I did not change my veto on GTExample. There will not > get integrated. Period. > We do not want to be forced to use special tools to manage semantic > metadata when we can have simple call. > I'm already scared and amazed by the complexity of annotations in the Java > world. > So to me if the Pillar part cannot be separated from GTExample then too > bad. > > > Stef > > On Sat, Aug 26, 2017 at 1:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> We are really pleased to announce another major advancement in the >> development of the moldable editor, and most of it was enabled because of >> one new feature: expandable elements. We think this will impact >> significantly our day to day interactions. >> >> To exemplify what we mean, we will make use of two more alpha projects >> that we did not announce yet: GT Documenter (a set of documentation tools >> based on Pillar and GT Examples) and GT Mondrian (the graph visualization >> engine), both of which are being implemented in Bloc. >> >> Please take a look at the following pictures showing the documentation >> Pillar file that ships together with GT Mondrian. What stands out are the >> two embedded pictures. These are actually not pictures, but >> visualizations rendered live during the viewing of the document out of a >> referenced GT Example. >> >> >> Now, GT Examples are likely also new for most people. We introduced them >> a couple of years ago based on the original idea of Markus Gaelli. These >> are a kind of tests that return an object and that can be built out of >> other examples. The nice thing is that they are always executable and >> testable. So, of course, if you see the resulting object, you can also see >> the code that created it, and if you see the code, you can even execute it >> live, right in place (notice the preview of the second snippet). >> >> >> Perhaps the most controversial part of GT Examples is that they offer a >> mechanism to define static dependencies via pragmas. Please, letâs leave >> this debate to another occasion, but please also notice that tools can use >> that static information to unfold the code of the referenced method (notice >> the nested code editors). >> >> A side note: if you look closer at the list with three items at the top >> of the Tutorial section, you will notice numbering next to #. That is >> actually syntax highlighting and so is the mechanism that embeds the >> expandable elements. Itâs really cool. >> >> Taking step back, when we introduced the editor a few weeks ago, we >> called it moldable because we said we can make it take different shapes >> easily. GT Documenter with everything you see in the above screenshots has >> currently ~500 lines of code, and all this while still having an editor >> that is highly scalable. >> >> We think that Bloc and Brick will change dramatically face of Pharo and >> now we can start to get a glimpse of what is possible. For example, the use >> case presented above is more than a technical tool, and we think this will >> change both the way we write documentation and the way we consume it. >> >> All these will be presented at ESUG both during presentations and at the >> Innovation Awards competition. In the meantime, those that want to play >> with it can execute the following in both Pharo 6.1 and Pharo 7.0: >> >> Iceberg enableMetacelloIntegration: true. >> Metacello new >> baseline: 'GToolkit'; >> repository: 'github://feenkcom/gtoolkit/src'; >> load. >> >> And then inspect: >> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' >> asFileReference >> >> Cheers, >> The feenk team >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >> >

Aug. 26, 2017

Re: [Pharo-users] The Wisdom of the Crowd Redux

by Offray Vladimir Luna CÃ¡rdenas

Yes, thanks for sharing it Richard. For me the issue with wisdom of the crowd arguments is, as you point at the end of the article, that also crowd can be pretty stupid, so when/how you difference between both cases? At some point seems like crowd is wise when they share my opinion and dumb when they don't. A different argument I have found in favor or non-popular but powerful languages is made by Matthew Butterick[1] in the case of Lisp/Racket by deconstructing the ad-populum falacy (something is good, because is popular) and then going beyond the frequent flattery of authoritative voices, giving real examples from a first person perspective. I think that is an interesting and novel approach for advocacy. [1] http://practicaltypography.com/why-racket-why-lisp.html Cheers, Offray On 22/08/17 12:09, Ben Coman wrote: > nice article. thanks for sharing. > cheers -ben > > On Tue, Aug 22, 2017 at 4:14 AM, horrido <horrido.hobbies(a)gmail.com > <mailto:horrido.hobbies@gmail.com>> wrote: > > I'm glad people in the programming community are recognizing the > value of > Smalltalk: The Wisdom of the Crowd > <https://medium.com/@richardeng/the-wisdom-of-the-crowd-c7aff954bd5f > <https://medium.com/@richardeng/the-wisdom-of-the-crowd-c7aff954bd5f>> > . I > was very pleasantly surprised by this. > > > > -- > View this message in context: > http://forum.world.st/The-Wisdom-of-the-Crowd-Redux-tp4963261.html > <http://forum.world.st/The-Wisdom-of-the-Crowd-Redux-tp4963261.html> > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > >

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Stephane Ducasse

Hi doru This is cool. Now I did not change my veto on GTExample. There will not get integrated. Period. We do not want to be forced to use special tools to manage semantic metadata when we can have simple call. I'm already scared and amazed by the complexity of annotations in the Java world. So to me if the Pillar part cannot be separated from GTExample then too bad. Stef On Sat, Aug 26, 2017 at 1:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are really pleased to announce another major advancement in the > development of the moldable editor, and most of it was enabled because of > one new feature: expandable elements. We think this will impact > significantly our day to day interactions. > > To exemplify what we mean, we will make use of two more alpha projects > that we did not announce yet: GT Documenter (a set of documentation tools > based on Pillar and GT Examples) and GT Mondrian (the graph visualization > engine), both of which are being implemented in Bloc. > > Please take a look at the following pictures showing the documentation > Pillar file that ships together with GT Mondrian. What stands out are the > two embedded pictures. These are actually not pictures, but > visualizations rendered live during the viewing of the document out of a > referenced GT Example. > > > Now, GT Examples are likely also new for most people. We introduced them a > couple of years ago based on the original idea of Markus Gaelli. These are > a kind of tests that return an object and that can be built out of other > examples. The nice thing is that they are always executable and testable. > So, of course, if you see the resulting object, you can also see the code > that created it, and if you see the code, you can even execute it live, > right in place (notice the preview of the second snippet). > > > Perhaps the most controversial part of GT Examples is that they offer a > mechanism to define static dependencies via pragmas. Please, letâs leave > this debate to another occasion, but please also notice that tools can use > that static information to unfold the code of the referenced method (notice > the nested code editors). > > A side note: if you look closer at the list with three items at the top of > the Tutorial section, you will notice numbering next to #. That is actually > syntax highlighting and so is the mechanism that embeds the expandable > elements. Itâs really cool. > > Taking step back, when we introduced the editor a few weeks ago, we called > it moldable because we said we can make it take different shapes easily. GT > Documenter with everything you see in the above screenshots has currently > ~500 lines of code, and all this while still having an editor that is > highly scalable. > > We think that Bloc and Brick will change dramatically face of Pharo and > now we can start to get a glimpse of what is possible. For example, the use > case presented above is more than a technical tool, and we think this will > change both the way we write documentation and the way we consume it. > > All these will be presented at ESUG both during presentations and at the > Innovation Awards competition. In the meantime, those that want to play > with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > And then inspect: > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > > Cheers, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > >

Aug. 26, 2017

Re: [Pharo-users] Morphic renderer for Pillar?

by Stephane Ducasse

Hi hannes "Ideally we should add the pillar element to the associated morphic to manage back link from the renderer to the pillar tree. But this is to be done." I meant that rendering is just one part of the story, that in the future you will want to click on the morph and - jump to the code - edit in place so in that case this is important to be able to have a pointer to the Pillar model. I remember I did not like the PRMorphWriter because it has a lot of assumption of the output. Now we did the two in one afternoon to show to maxim that we could do it fast instead of explaining it. So you can consider that this is was just a trial showing the way but I would not be surprised that we should throw away what we did. I think that in each visitor action somehow we should a call (may be via a super call) to aMorph setPillarElement: anElement Stef On Fri, Aug 25, 2017 at 10:11 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 8/25/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> The package contains two approaches to render a Pillar document object >> to Morphic. >> >> 1. PRVisitor subclass: #PRMorphWriter >> 2. PRDocumentWriter subclass: #PRMorphWriter2 >> > After removing PRMorphWriter we have what the screen shot shows. > > PRMorphWriter2 using PRMorphCanvas does the job. > > PRMorphInterface is a demo class and PRRenderingExamples contains some > demo Pillar source code. > > > Stephane, you wrote > > "Ideally we should add the pillar element to the associated morphic to > manage back link from the renderer to the pillar tree. > But this is to be done." > > I do not understand what you mean with this. > > It sound like there > should there be a link from the morph used in rendering to the Pillar > document object model node? > > The way how it is implemented at the moment is different. > > An instance of the class Text is created. > > parseButton action: [ > document := PRPillarParser new parse: textInput text. > morphWriter start: document. > textResult text: morphWriter text ]. > > Then it seems that just a TextMorph is displayed > > writer text asMorph openInWindow. > > And what is the reason for this? > > --Hannes

Aug. 26, 2017

Re: [Pharo-users] [ANN] Pharo wiki , is here

by Dimitris Chloupis

Grafoscopio can display markdown files ? On Sat, Aug 26, 2017 at 5:38 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Dimitris, > > I understand your practical reasons to have Markdown over Pillar and in > fact I have advocated several of them. As I have said, Markdown ubiquity > for complete documentation workflows (including complete books) is similar > to git ubiquity for code. Despite having other personal preferences in > markup and DVCS, I think is strategic to give them support in Pharo, > without precluding any work on our own tools (Monticello, Metacello, > Pillar, etc.). > > I'll try to make some experiments with integration of Documenter in > Grafoscopio and Markdown. They'll advance slowly, because time constrains > now that I'm trying to finish my thesis, but once a week I'll try to show > advancements and make questions. > > Cheers, > > Offray > > On 26/08/17 01:55, Dimitris Chloupis wrote: > > As I said the format is not so important for me, the reason why I chose > markdown instead of pillar is because you can edit it using github web > interface making it easier. The books will continue to use Pillar, because > making a book is obviously a lot more sophisticated than creating a wiki > that mainly has web links to various internet locations. Pillar already can > export to markdown , latex, html and through latex it can also export to > pdf. > > After Stef requested it, I moved the wiki inside the pharo git repository > here > > https://github.com/pharo-project/pharo > > I also added a link to it inside the git wiki of pharo > > https://github.com/pharo-project/pharo/wiki > > > On Sat, Aug 26, 2017 at 2:17 AM Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> So, we're going to have Markdown for the wiki and probably for >> documentation (via GitBooks)..., which is not surprising considering the >> vast amount of support such documentation format has and the extensions for >> a complete documentation toolchain and features. As I said, I think that is >> an important syntax and we should put Scholarly/Pandoc Markdown in the >> radar for documentation support in Pharo. Is what I'm doing with >> Grafoscopio and now that Pillar support is again taking momentum, the >> infrastructure there (parsers, highlighters, editors) could be extended to >> support Pandoc's Markdown. >> >> I'll keep you posted. >> >> Cheers, >> >> Offray >> >> On 24/08/17 17:59, Dimitris Chloupis wrote: >> >> >> >> On Thu, Aug 24, 2017 at 11:32 PM Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> You have Netstyle/Workflow too. >>> >> >> done >> >> "Why are you using markup documents to create the wiki when you could >> use Github wiki itself? >> >> For portability?" >> >> good question. Yes for flexibility , another reason however is that >> Github wiki is a separate repo and I did not want that because in the very >> back of my head I am considering the option of creating software to allow >> access to wiki from inside Pharo and I wanted to be all (content and code) >> in the same repo. Its a very low priority for now. >> >> Also Github wiki is basically the same as I am doing with some extra >> format (table of contents) , in my case I dont care because Github allows >> me to define HTML templates that will format the wiki webpage and make it >> look a a lot more polished that pharo wiki looks like. Generally there are >> some cool stuff you can do with Markdown and Github , plus the fact that >> markdown can embed HTML etc. >> >> There is also the option of Gitbook which has some nice features for >> generating polished and well structured documentation. >> >> So I like to keep my options open. For now I am focusing 100% on content. >> >> >> >

Aug. 26, 2017

Re: [Pharo-users] [ANN] Pharo wiki , is here

by Offray Vladimir Luna CÃ¡rdenas

Dimitris, I understand your practical reasons to have Markdown over Pillar and in fact I have advocated several of them. As I have said, Markdown ubiquity for complete documentation workflows (including complete books) is similar to git ubiquity for code. Despite having other personal preferences in markup and DVCS, I think is strategic to give them support in Pharo, without precluding any work on our own tools (Monticello, Metacello, Pillar, etc.). I'll try to make some experiments with integration of Documenter in Grafoscopio and Markdown. They'll advance slowly, because time constrains now that I'm trying to finish my thesis, but once a week I'll try to show advancements and make questions. Cheers, Offray On 26/08/17 01:55, Dimitris Chloupis wrote: > As I said the format is not so important for me, the reason why I > chose markdown instead of pillar is because you can edit it using > github web interface making it easier. The books will continue to use > Pillar, because making a book is obviously a lot more sophisticated > than creating a wiki that mainly has web links to various internet > locations. Pillar already can export to markdown , latex, html and > through latex it can also export to pdf. > > After Stef requested it, I moved the wiki inside the pharo git > repository here > > https://github.com/pharo-project/pharo > > I also added a link to it inside the git wiki of pharo > > https://github.com/pharo-project/pharo/wiki > > > On Sat, Aug 26, 2017 at 2:17 AM Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > So, we're going to have Markdown for the wiki and probably for > documentation (via GitBooks)..., which is not surprising > considering the vast amount of support such documentation format > has and the extensions for a complete documentation toolchain and > features. As I said, I think that is an important syntax and we > should put Scholarly/Pandoc Markdown in the radar for > documentation support in Pharo. Is what I'm doing with Grafoscopio > and now that Pillar support is again taking momentum, the > infrastructure there (parsers, highlighters, editors) could be > extended to support Pandoc's Markdown. > > I'll keep you posted. > > Cheers, > > Offray > > > On 24/08/17 17:59, Dimitris Chloupis wrote: >> >> >> On Thu, Aug 24, 2017 at 11:32 PM Stephane Ducasse >> <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >> >> You have Netstyle/Workflow too. >> >> >> done >> >> "Why are you using markup documents to create the wiki when you could >> use Github wiki itself? >> >> For portability?" >> >> good question. Yes for flexibility , another reason however is >> that Github wiki is a separate repo and I did not want that >> because in the very back of my head I am considering the option >> of creating software to allow access to wiki from inside Pharo >> and I wanted to be all (content and code) in the same repo. Its a >> very low priority for now. >> >> Also Github wiki is basically the same as I am doing with some >> extra format (table of contents) , in my case I dont care because >> Github allows me to define HTML templates that will format the >> wiki webpage and make it look a a lot more polished that pharo >> wiki looks like. Generally there are some cool stuff you can do >> with Markdown and Github , plus the fact that markdown can embed >> HTML etc. >> >> There is also the option of Gitbook which has some nice features >> for generating polished and well structured documentation. >> >> So I like to keep my options open. For now I am focusing 100% on >> content. >

Aug. 26, 2017

Re: [Pharo-users] Object>>#name deprecated in Pharo 6 -- what do I need to do?

by PBKResearch

Hannes You are certainly not required to eliminate #name altogether; all you have to do is to ensure that any object that receives the message #name knows how to answer its own name in an appropriate way. To rephrase Benâs second para in a more long-winded way: a. Run the code that generates the deprecation warning. b. In the warning pop-up, click on âDebugâ. c. Examine the debug stack in the top pane. It is probable that the first two lines will read: HannesClass(Object) deprecated:on:in HannesClass(Object) name where HannesClass is the name of some class in your domain model. d. You now know that some code you have written is sending the message #name to an instance of HannesClass, but the class does not have such a method. The solution is to decide how an instance of that class should answer its name, and implement that as a method on the instance side of that class. If nothing else is obvious, the usual default is ^self printString. e. If the top line of the debug stack does not refer to a class in your model, work your way down the stack until you find a class that is yours. Hope this helps Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: 26 August 2017 13:08 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Object>>#name deprecated in Pharo 6 -- what do I need to do? Just checking my presumption... is PPCMNode>>#gtTreeViewIn: you own application method? So where it sends #name, instead send #printString (or #asString). Alternatively, #name is being sent to some domain object that doesn't implement #name, so it falls back to the super one from Object. So implement YourDomainObject>>#name: so the one from Object is not executed. cheers -ben On Sat, Aug 26, 2017 at 4:38 PM, H. Hirzel <hannes.hirzel(a)gmail.com <mailto:hannes.hirzel@gmail.com> > wrote: OK, so #name should not be used at all [1] The error message I get is PPCommonMarkSpecTest class>>DoIt (blockVisitor is Undeclared) The method Object>>#name called from PPCMNode>>#gtTreeViewIn: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. I wonder how I can fix this without going to much into details. --Hannes ------------------------------------------------------------------------------------------------------------------------ [1] Pharo 6.1 source code: Object>>name "Answer a name for the receiver. This is used generically in the title of certain inspectors, such as the referred-to inspector, and specificially by various subsystems. By default, we let the object just print itself out.. " self deprecated: 'Implement your own domain representation of an object, or use #asString or #printString instead.' on: '27 May 2016' in: #Pharo6. ^ self printString On 8/25/17, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > wrote: > I don't have an Image to check, but I believe Object>>name > just does "^self printString", > so by default, in your application send #printString instead of #name. > > cheers -ben > > P.S. Perhaps this would be a good candidate for automated rewrite? > > > On Thu, Aug 24, 2017 at 8:49 PM, H. Hirzel <hannes.hirzel(a)gmail.com <mailto:hannes.hirzel@gmail.com> > wrote: > >> Hello >> >> In the last days there was a discussion that >> >> Object>>#name >> >> >> should no longer be used. I did not follow the discussion in detail. >> What was decided how #name should be replaced? >> >> What do I need to do if I get a deprecation warning [1]? >> >> >> Thanks for the answer in advance >> >> Hannes >> >> >> >> >> [1] >> The method Object>>#name called from PPCMNode>>#gtTreeViewIn: has been >> deprecated. >> Implement your own domain representation of an object, or use >> #asString or #printString instead. >> >> Select Proceed to continue, or close this window to cancel the operation. >> >> >

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Denis Kudriashov

No Thierry, Newspeak do not allow it. And it not looks similar to what I want. Now command+click on selector opens implementors window. In past it moved browser to single implementor. It was nice and it is how other IDEs are working. But as Tim notice it always loses context. And it is quite difficult to browse long call chain which include many small methods. So with new editor command+click will be able expand implementor just in place. I think it will be big improvement for IDE. 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >>> Denis - that's a very cool idea if I've understood you - expand in the >>> source code of the current method, literally inline? So you could scroll up >>> and down to view the context as you expand it out? >>> >> >> Yes, exactly. >> > > Then that would look a bit like the NewSpeak code browser, if you would > like to try the concept. > > There are disadvantages to that paradigm. One of those is that the system > browser in Pharo is ill-suited to long methods. > > Thierry > > >> >> >>> One of the complaints around refactoring is that you lose context of >>> surrounding code - intelligent in place expansion would be the best of both >>> worlds... >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> This is really cool. It opens so many possibilities. >>> >>> I imaging method editor where message sends can be expanded to >>> implementors just in place. >>> >>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>>> Hi, >>>> >>>> We are really pleased to announce another major advancement in the >>>> development of the moldable editor, and most of it was enabled because of >>>> one new feature: expandable elements. We think this will impact >>>> significantly our day to day interactions. >>>> >>>> To exemplify what we mean, we will make use of two more alpha projects >>>> that we did not announce yet: GT Documenter (a set of documentation tools >>>> based on Pillar and GT Examples) and GT Mondrian (the graph visualization >>>> engine), both of which are being implemented in Bloc. >>>> >>>> Please take a look at the following pictures showing the documentation >>>> Pillar file that ships together with GT Mondrian. What stands out are the >>>> two embedded pictures. These are actually not pictures, but >>>> visualizations rendered live during the viewing of the document out of a >>>> referenced GT Example. >>>> >>>> >>>> Now, GT Examples are likely also new for most people. We introduced >>>> them a couple of years ago based on the original idea of Markus Gaelli. >>>> These are a kind of tests that return an object and that can be built out >>>> of other examples. The nice thing is that they are always executable and >>>> testable. So, of course, if you see the resulting object, you can also see >>>> the code that created it, and if you see the code, you can even execute it >>>> live, right in place (notice the preview of the second snippet). >>>> >>>> <pillar-mondrian-expanded-preview.png> >>>> >>>> Perhaps the most controversial part of GT Examples is that they offer a >>>> mechanism to define static dependencies via pragmas. Please, letâs leave >>>> this debate to another occasion, but please also notice that tools can use >>>> that static information to unfold the code of the referenced method (notice >>>> the nested code editors). >>>> >>>> A side note: if you look closer at the list with three items at the top >>>> of the Tutorial section, you will notice numbering next to #. That is >>>> actually syntax highlighting and so is the mechanism that embeds the >>>> expandable elements. Itâs really cool. >>>> >>>> Taking step back, when we introduced the editor a few weeks ago, we >>>> called it moldable because we said we can make it take different shapes >>>> easily. GT Documenter with everything you see in the above screenshots has >>>> currently ~500 lines of code, and all this while still having an editor >>>> that is highly scalable. >>>> >>>> We think that Bloc and Brick will change dramatically face of Pharo and >>>> now we can start to get a glimpse of what is possible. For example, the use >>>> case presented above is more than a technical tool, and we think this will >>>> change both the way we write documentation and the way we consume it. >>>> >>>> All these will be presented at ESUG both during presentations and at >>>> the Innovation Awards competition. In the meantime, those that want to play >>>> with it can execute the following in both Pharo 6.1 and Pharo 7.0: >>>> >>>> Iceberg enableMetacelloIntegration: true. >>>> Metacello new >>>> baseline: 'GToolkit'; >>>> repository: 'github://feenkcom/gtoolkit/src'; >>>> load. >>>> >>>> And then inspect: >>>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' >>>> asFileReference >>>> >>>> Cheers, >>>> The feenk team >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Innovation comes in the least expected form. >>>> That is, if it is expected, it already happened." >>>> >>>> >>> >> >

Aug. 26, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tim Mackinnon

I'd forgotten about the newspeak browser - it was ages ago that I had a look, will try it again. My hunch is you want both - inline and new window sometimes. But as we're firing on all cylinders lately - revising old ideas is no bad thing and maybe we can do them better as things are starting to come together. Tim Sent from my iPhone > On 26 Aug 2017, at 14:59, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> Denis - that's a very cool idea if I've understood you - expand in the source code of the current method, literally inline? So you could scroll up and down to view the context as you expand it out? >> >> Yes, exactly. > > Then that would look a bit like the NewSpeak code browser, if you would like to try the concept. > > There are disadvantages to that paradigm. One of those is that the system browser in Pharo is ill-suited to long methods. > > Thierry > >> >>> One of the complaints around refactoring is that you lose context of surrounding code - intelligent in place expansion would be the best of both worlds... >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>> >>>> This is really cool. It opens so many possibilities. >>>> >>>> I imaging method editor where message sends can be expanded to implementors just in place. >>>> >>>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>> Hi, >>>>> >>>>> We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. >>>>> >>>>> To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. >>>>> >>>>> Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. >>>>> >>>>> >>>>> >>>>> Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). >>>>> >>>>> <pillar-mondrian-expanded-preview.png> >>>>> >>>>> Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). >>>>> >>>>> A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. >>>>> >>>>> Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. >>>>> >>>>> We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. >>>>> >>>>> All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: >>>>> >>>>> Iceberg enableMetacelloIntegration: true. >>>>> Metacello new >>>>> baseline: 'GToolkit'; >>>>> repository: 'github://feenkcom/gtoolkit/src'; >>>>> load. >>>>> >>>>> And then inspect: >>>>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference >>>>> >>>>> Cheers, >>>>> The feenk team >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Innovation comes in the least expected form. >>>>> That is, if it is expected, it already happened." >>>>> >>>> >> >

Aug. 26, 2017