Thanks.
About examples: I am not completely satisfied with the existing pragma-based definition, but I am convinced that, after having used examples extensively, they are very useful. We will certainly do another iteration over the model, but as I mentioned, I would prefer to have the conversation about them another time. Now, we should talk about the editor :).
In the context of the editor, the examples was a validation use case to show to what extent we can mold it to a specific application. The main issue here is that we can start to have expression possibilities at UI level that did not exist before. Really, it is quite amazing that we can now decorate a piece of text with any visual elements at no cost. For example, we did the same with pictures (referencing a picture shows it right in place).
The examples support was added on top of the default Pillar without really changing the main grammar (there is only a tiny change to allow having scripts that can have parameters, but that is for convenience only). Other than that, we have a simple grammar specialization that adds syntax highlighting. We would have preferred to do it on the AST level, but the issue right now is that the AST does not carry token information and is less useful for tooling at present time. The final goal should be to enrich the AST have the syntax highlighter be a visitor, but again, that is secondary.
The way we captured examples now is not ideal, and I actually would like to have a conversation about how to make Pillar more extensible (probably to reintroduce something like *ref���). As we will move Pillar towards the image, we will certainly need ways to both link to objects and code (methods, classes) and to insert various representations in place.
Cheers,
Doru
On Aug 26, 2017, at 5:41 PM, Stephane Ducasse <stepharo.self@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@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."