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

Re: [Pharo-dev] [Ann][Pillar] Travis -> Bintray for PDFs

by Stephane Ducasse

Hi peter have a look at the .bintray.json of booklet-Smacc for example. I updated them all. Stef On Fri, Aug 25, 2017 at 10:31 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> A problem I anticipate is that since we only keep the latest build, > > how did you manage that? :-o > > When I was using bintray we had trouble that we could only store every > commit; so I guess I am interested to see what your process is. :-) > > Peter > > On Fri, Aug 25, 2017 at 9:06 PM, Damien Pollet <damien.pollet(a)gmail.com> > wrote: >> >> A problem I anticipate is that since we only keep the latest build, the >> PDF will only match master or any pull request until the next commit/build >> (I don't like storing stuff for each and every commit). But maybe that could >> be fixed by naming the PDF according to their originating branchâ¦ >> >> On 25 August 2017 at 20:11, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >>> >>> +100 :) >>> >>> >>> On Fri, Aug 25, 2017 at 5:45 PM Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi >>>> >>>> with Damien Pollet, we went over all the booklets and some of the >>>> Pharo books currently written in Pillar and made sure that each time >>>> you commit >>>> >>>> - a travis job is run >>>> - latex is produced as well as pdf >>>> - the pdf is stored on bintray >>>> - the release versions are stored on the github repo (I should verify) >>>> >>>> So now you can just do a PR and you get a super nice PDF. >>>> >>>> Have a look at Glorp or Voyage for example >>>> >>>> - https://github.com/SquareBracketAssociates/Booklet-Glorp >>>> - https://github.com/SquareBracketAssociates/Booklet-Voyage >>>> >>>> You can access the bintray files from the squarebracketassociates >>>> lovely binTray account :) >>>> >>>> >>>> https://bintray.com/squarebracketassociates/wip/download_file?file_path=voy… >>>> >>>> >>>> I'm writing a doc of the process so that other people can do it for >>>> their private projects. >>>> >>>> >>>> Stef >>>> >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet > >

Aug. 26, 2017

Re: [Pharo-dev] [Ann][Pillar] Travis -> Bintray for PDFs

by Stephane Ducasse

Damien we are not targeting the perfect solution. Just a good one that works for 80% of the case. You commit in master and you get the pdf, else install latex on your machine. We should focus on real improvement. On Fri, Aug 25, 2017 at 9:06 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > A problem I anticipate is that since we only keep the latest build, the PDF > will only match master or any pull request until the next commit/build (I > don't like storing stuff for each and every commit). But maybe that could be > fixed by naming the PDF according to their originating branchâ¦ > > On 25 August 2017 at 20:11, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> +100 :) >> >> >> On Fri, Aug 25, 2017 at 5:45 PM Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Hi >>> >>> with Damien Pollet, we went over all the booklets and some of the >>> Pharo books currently written in Pillar and made sure that each time >>> you commit >>> >>> - a travis job is run >>> - latex is produced as well as pdf >>> - the pdf is stored on bintray >>> - the release versions are stored on the github repo (I should verify) >>> >>> So now you can just do a PR and you get a super nice PDF. >>> >>> Have a look at Glorp or Voyage for example >>> >>> - https://github.com/SquareBracketAssociates/Booklet-Glorp >>> - https://github.com/SquareBracketAssociates/Booklet-Voyage >>> >>> You can access the bintray files from the squarebracketassociates >>> lovely binTray account :) >>> >>> >>> https://bintray.com/squarebracketassociates/wip/download_file?file_path=voy… >>> >>> >>> I'm writing a doc of the process so that other people can do it for >>> their private projects. >>> >>> >>> Stef >>> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 26, 2017

Re: [Pharo-dev] pillars runs into an infinite loop on a simple typo

by Stephane Ducasse

No pillar is line based and the beginning of the line is key. On Sat, Aug 26, 2017 at 5:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Apparently this is enough to run into an infinite loop somewhere. > > text := '- one > - # cry'. > doc := PRPillarParser parse: text. > > > Also question regarding pillar syntax, is not possible to indent it in the > syntax? > > e.g. > > - one > -# one.one > - two > -# two.one > -# two.two > > Flattening it makes an _indented_ list hard to read (and defeats the point > why we indent things in the first place...) > > Peter

Aug. 26, 2017

pillars runs into an infinite loop on a simple typo

by Peter UhnÃ¡k

Apparently this is enough to run into an infinite loop somewhere. text := '- one - # cry'. doc := PRPillarParser parse: text. Also question regarding pillar syntax, is not possible to indent it in the syntax? e.g. - one -# one.one - two -# two.one -# two.two Flattening it makes an _indented_ list hard to read (and defeats the point why we indent things in the first place...) Peter

Aug. 26, 2017

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

by Tudor Girba

Hi, This is achieved through the integration in Morphic we announced a couple of months ago. Now, Sparta offers: - two backends: Moz2D and Cairo - two host systems: SDL2 and Morphic By default, Bloc ships with Sparta working on Cairo and Morphic, and with this you can use any Bloc element inside a morph. Glamour also comes with a BlocPresentation that makes use of this ability, and this is what you see in the picture. So, it is possible to use this inside Morphic, and our effort will be focused exclusively around this editor. Cheers, Doru > On Aug 26, 2017, at 11:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I wondering how you compose bloc component inside morphic inspector? (which is shown in your pictures) > Did you already have GT inspector in Bloc? > Is it posible to use this editor in morphic? Can we replace rubric? > > 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. > > <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." > > -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Aug. 26, 2017

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

by Denis Kudriashov

I wondering how you compose bloc component inside morphic inspector? (which is shown in your pictures) Did you already have GT inspector in Bloc? Is it posible to use this editor in morphic? Can we replace rubric? 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-dev] [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-dev] [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

[ann] moldable editor - with expandable elements

by Tudor Girba

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

Re: [Pharo-dev] [Ann][Pillar] Travis -> Bintray for PDFs

by Peter UhnÃ¡k

> A problem I anticipate is that since we only keep the latest build, how did you manage that? :-o When I was using bintray we had trouble that we could only store every commit; so I guess I am interested to see what your process is. :-) Peter On Fri, Aug 25, 2017 at 9:06 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > A problem I anticipate is that since we only keep the latest build, the > PDF will only match master or any pull request until the next commit/build > (I don't like storing stuff for each and every commit). But maybe that > could be fixed by naming the PDF according to their originating branchâ¦ > > On 25 August 2017 at 20:11, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> +100 :) >> >> >> On Fri, Aug 25, 2017 at 5:45 PM Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >>> Hi >>> >>> with Damien Pollet, we went over all the booklets and some of the >>> Pharo books currently written in Pillar and made sure that each time >>> you commit >>> >>> - a travis job is run >>> - latex is produced as well as pdf >>> - the pdf is stored on bintray >>> - the release versions are stored on the github repo (I should verify) >>> >>> So now you can just do a PR and you get a super nice PDF. >>> >>> Have a look at Glorp or Voyage for example >>> >>> - https://github.com/SquareBracketAssociates/Booklet-Glorp >>> - https://github.com/SquareBracketAssociates/Booklet-Voyage >>> >>> You can access the bintray files from the squarebracketassociates >>> lovely binTray account :) >>> >>> https://bintray.com/squarebracketassociates/wip/download_ >>> file?file_path=voyage-wip.pdf >>> >>> >>> I'm writing a doc of the process so that other people can do it for >>> their private projects. >>> >>> >>> Stef >>> >>> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Aug. 25, 2017