- Pharo-users - lists.pharo.org

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

by Denis Kudriashov

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). > > > 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] Pharo wiki , is here

by H. Hirzel

On 8/26/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > And > > Main repository: > http://smalltalkhub.com/mc/Pier/Pillar/main/ And the three slides which give a high-level overview of the Pillar system HH.

Aug. 26, 2017

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

by H. Hirzel

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> 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> 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] Pharo wiki , is here

by H. Hirzel

And Main repository: http://smalltalkhub.com/mc/Pier/Pillar/main/ On 8/26/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Dimitris, > > could you please add the three important Pillar links below I found > out about this week > > Tutorial > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > Syntax summary > http://pillarhub.pharocloud.com/hub/pillarhub/pillarcheatsheet > > Presentation > http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf > > Thx > Hannes > > > On 8/26/17, Dimitris Chloupis <kilon.alios(a)gmail.com> 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] Morphic renderer for Pillar?

by H. Hirzel

On 8/26/17, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Hi, > > Back in 2015 there was Kasper Ãsterbye who did a Pillar-TextRenderer > > There is a screen slide 21: > http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf > > Here is the thread: > http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-td… > > -- > Cyril Ferlicot Hello Cyril Thank you for these two references with some info to the Pillar-TextRenderer Kasper Ãsterbye did. Do you have an idea where I could find the code. I found nothing so far in http://smalltalkhub.com/mc/Pier/Pillar/main/ Regards Hannes

Aug. 26, 2017

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

by H. Hirzel

Dimitris, could you please add the three important Pillar links below I found out about this week Tutorial https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… Syntax summary http://pillarhub.pharocloud.com/hub/pillarhub/pillarcheatsheet Presentation http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf Thx Hannes On 8/26/17, Dimitris Chloupis <kilon.alios(a)gmail.com> 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

[Pillar] How do I open the Pillar editor in Pharo 6?

by H. Hirzel

Hello Doru On 8/26/17, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Just for information: Pillar already ships with a live editor with syntax > highlighting that I built a couple of years ago. Thank you for this information, Doru. Earlier this week I was looking for a "Pillar tool" in Pharo 6 and was told, that there is none. I did not find a link in the help system nor a menu entry in the world menu. How do I get at this live editor? > And there are two inspector presentations available: > - If you inspect a class, you will get a Pillar comment presentation with > syntax highlighting > - If you inspect a .pillar file, you will get a Pillar editor with syntax > highlighting > > Cheers, > Doru > Regards Hannes

Aug. 26, 2017

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

by Tim Mackinnon

Guys - this is absolutely astounding. 6 months ago I tagged a tweet with #pharoproject about why we put up with static source code when we can do so much more, and I'm stunned that in literally months this is a evolving around us. This community is awesome! Tim Sent from my iPhone > On 26 Aug 2017, at 01:03, 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. > > <pillar-mondrian-examples.png> > > 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." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Aug. 26, 2017

Re: [Pharo-users] Minimizing an Application

by Dimitris Chloupis

ah ok , thanks for the clarification , Craig and Tim , this makes more sense to me now :) On Sat, Aug 26, 2017 at 3:44 AM Craig Latta <craig(a)blackpagedigital.com> wrote: > > Hi-- > > > > > ...10mbs which is the size pharo image can be reduced to is > > > > nothing for todays TBs hard drives and GBs flash drives and > > > > online storage. Unless you do an embedded app and 10 mbs are huge > > > > for your limited storage. > > > > > > Or you want to minimize initial startup time, including the time it > > > takes to transmit the entire system over the net. > > > > ...transmitting the entire image would be necessary only in the case > > you want to install it remotely and that remote location has no > > immediate access to the installation. > > Yes, that's what I meant by "initial startup". > > > -C > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > craig(a)blackpagedigital.com > voice through 2017-09-12: > + 1 510 833 5799 <(510)%20833-5799> (SMS ok) > +31 20 893 2796 <+31%2020%20893%202796> (no SMS) > > >

Aug. 26, 2017

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

by Dimitris Chloupis

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