2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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.

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@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@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."

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@gmail.com> wrote:

2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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@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@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."

2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

No Thierry, Newspeak do not allow it. And it not looks similar to what I want.

Hum, you would still get the same overall approach: editor inside editor (or view inside view). Now, you can say it is not the same, up to you. For me, it has the same effect: the editor isn't in a single place anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both).

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.

You miss the past behaviour? Why not adding it again?

But as Tim notice it always loses context. And it is quite difficult to browse long call chain which include many small methods.

I'm not sure it would solve that one. Either it is a long call chain with a fan-out of one, in which case the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors. For that, you already have the flow browser.

So with new editor command+click will be able expand implementor just in place. I think it will be big improvement for IDE.

As I said, with Calypso and Nautilus handling badly long methods, then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything. I'd say there that the GTInspector approach would work better -> expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing). Regards, Thierry

2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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@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@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."

Hi Tim, 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim@testit.works>:

I think you pose some interesting design challenges - but it's worthy of experimentation.

I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space.

I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems).

I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia. I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser.

For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal.

Agreed. I have changed the way I code to reduce the context needed to understand it.

Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive.

Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier? Regards, Thierry

Tim

Sent from my iPhone

On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

No Thierry, Newspeak do not allow it. And it not looks similar to what I want.

Hum, you would still get the same overall approach: editor inside editor (or view inside view). Now, you can say it is not the same, up to you.

For me, it has the same effect: the editor isn't in a single place anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both).

...

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.

You miss the past behaviour? Why not adding it again?

...

But as Tim notice it always loses context. And it is quite difficult to browse long call chain which include many small methods.

I'm not sure it would solve that one.

Either it is a long call chain with a fan-out of one, in which case the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors.

For that, you already have the flow browser.

...

So with new editor command+click will be able expand implementor just in place. I think it will be big improvement for IDE.

As I said, with Calypso and Nautilus handling badly long methods, then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything.

I'd say there that the GTInspector approach would work better -> expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing).

Regards,

Thierry

...

2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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@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@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."

Hi Doru, 2017-08-27 9:24 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

...

On Aug 27, 2017, at 12:06 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Tim,

2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim@testit.works>: I think you pose some interesting design challenges - but it's worthy of experimentation.

I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space.

I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems).

I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia.

I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser.

For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal.

Agreed. I have changed the way I code to reduce the context needed to understand it.

Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive.

Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier?

Please let me intervene briefly :).

Smalltalk was always indeed open. However, we noticed that regardless of the application domain, tools essentially looked the same for these systems. All Smalltalkers I asked extended Object at least once, but before the GTInspector, most of them never extended the inspector. Our language was extremely dynamic, but our tools less so. That is a conceptual problem that we address with what we call moldability.

Hum. From 1992 to now, I would make the same statement in the Smalltalk world, mostly talking a certain conservatism first (look at how much the system browser has evolved over the years), but also some questions about efficiency of alternative forms. For example, the code view of the GTInspector remain for me as one of the clumsiest, worse view I've ever seen in the Smalltalk world for editing code.

The goal of moldability is to make it inexpensive to customize. To this end, we approach the IDE as a language and the moldability is captured in the operators that language provides. Of course, there are limitations to what can be doable inexpensively. However, it turns out that if you do manage to bring the cost to a radical low cost, you get much more extensions and experimentations going on.

I'm a bit missing where the moldability of the IDE went, in that context. You seem to stear very clear from anything related to the system browser...

All infrastructures make certain things easier and others less so. The value of all this does depend on what are the operators and how deep in the infrastructure they are placed. For example, the moldable editor shows these expandable elements as part of syntax highlighting. Syntax highlighting existed since a long time, so making it also able to show other things is quite powerful and requires nothing hardcoded. In fact, I do not know of any other editor that can do that while still having the performance we get.

? Especially that last statement. Adding non text elements in an editor has allways been a fairly easy endeavour in ST, as long as I could remember (1993?). Performance on long texts is orthogonal to Bloc, right? It is present in all editors that do formatting on long documents since the first WYSIWIG editors appeared in the 80's. And, so far, the examples you're showing means that editor isn't as capable as Doc (in 1989/1990?) was. I a bit worried about that syntax highlighting approach. It seems to me very tied to a text + attributes representation instead of an object representation, and I find that API in Pharo horribly clumsy and ineffective, for the apparent benefit of slightly reducing object storage size with a kind of RLE compression.

But, even more important than tool features is the behavior of people. For example, when we first introduced the inspector, all talk was about details (e.g., how it is clumsy to navigate laterally). 2 years later, at this year’s PharoDays most talks used the GTInspector in one way or another to exemplify the presentation. This is a significant impact and this is what we are after.

Yes. This is clearly where the Pharo platform is showing some innovation in the ability to shape better object representations. At the same time, GUI-wise, there is very little innovation in the GUI language used; GT provides a very limited language, for the sake of efficiency and ease (*). But maybe it can't be done in another way, if you want people to really build their extensions.

At feenk, we don’t say that we build tools. We see ourselves as designing experiences.

Which is a worthwhile goal. Regards, Thierry (*) Such layers represent a so huge investment anyway, so it may be unavoidable.

Cheers, Doru

...

Regards,

Thierry

Tim

Sent from my iPhone

On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier@gmail.com> wrote:

...

2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>: No Thierry, Newspeak do not allow it. And it not looks similar to what

I want.

...

Hum, you would still get the same overall approach: editor inside

editor (or view inside view). Now, you can say it is not the same, up to you.

...

For me, it has the same effect: the editor isn't in a single place

anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both).

...

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.

...

You miss the past behaviour? Why not adding it again?

But as Tim notice it always loses context. And it is quite difficult to

browse long call chain which include many small methods.

...

I'm not sure it would solve that one.

Either it is a long call chain with a fan-out of one, in which case the

developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors.

...

For that, you already have the flow browser.

So with new editor command+click will be able expand implementor just

in place. I think it will be big improvement for IDE.

...

As I said, with Calypso and Nautilus handling badly long methods, then

a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything.

...

I'd say there that the GTInspector approach would work better -> expand

on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing).

...

Regards,

Thierry

2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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@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@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."

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

Hi Doru, thanks for the explanation... I'll end up with three questions: - What makes Bloc different compared to the InterViews and Amulet toolkits? And Unidraw? - Will some of your workflows enables exploration of parallel, non-deterministic programs? - Will we be able to have non-linear execution paths and explorations through examples and documentation? Regards, Thierry 2017-08-27 13:37 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

Hi Thierry,

Indeed, you noticed correctly that we stayed away from the code browser.

We found several years ago that Morphic was too limiting. During the Spotter implementation we found ourselves having to construct a mini-Morphic in order to do what we wanted to do. With text we had several prototypes for a different kind of editing experience, but we hit a wall. The interface from the GTInspector is the most rudimentary solution we could put in place, and it is there mostly as a placeholder to get over the bridge.

This is why we joined the Bloc project and we focused all our tool development effort on it. The goal is to be able to build interfaces that do not yet exist and that enable workflows that are radically different. We showed can do that once we have an infrastructure, and we will continue to do it until we have a full development experience.

We did not start from the experience of writing code explicitly. That is because the IDE should encompass all activities including the way we understand a system, and we think that focusing on reading is to be left for the previous century. So, we started from the inspector and debugger and we are making our way towards the writing part.

Writing code is certainly of deep interest to us. However, the system browser is the least interesting of the places where we want to write code. That is because we want to code against live objects, not against dead text. The main use case the system browser is good for is to organize code and to find a starting place for getting to a living object. For the rest of the use cases, there are other solutions that are better. For example, even with the current Playground, we have people spending more time in there than in the code browser. That says something given that the Playground is quite bare at the moment.

We do not think in terms of tools, but the overall workflows we want to support. It’s not a race against features, but a reimagining of what an experience can be like. For example, let’s take documentation: right now, both producing and consuming documentation happens mostly outside of the environment. So, the I in the IDE is failing in this respect. We want to make both of these activities more attractive inside the environment and the demo you see here is a step in that direction. There is no name for this tool yet because we tend to not phrase the problem like that.

Related to other editors, there are indeed WYSWIG tools, but they are typically not dynamic. There are viewers that are dynamic, but they tend to not scale well and not be editable. There are tools that scale, but they are not too visual. And even when there exist some, they are not in an IDE. So, yes, there are pieces that already exist, but the way we apply them is novel.

As for syntax highlighting, it is tied to text and attributes but only to the extent we wanted it to be. The current implementation is 2k lines of code. In comparison, just the core of Rubric is 5.5k. But, the rendering is not related to text whatsoever. Word and adornments are just element that conform to a layout. So, this means that people can build something else at a much smaller costs should they want to.

Cheers, Doru

...

On Aug 27, 2017, at 10:43 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Doru,

2017-08-27 9:24 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,

...

On Aug 27, 2017, at 12:06 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Hi Tim,

2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim@testit.works>: I think you pose some interesting design challenges - but it's worthy of experimentation.

I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space.

I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems).

I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia.

I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser.

For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal.

Agreed. I have changed the way I code to reduce the context needed to understand it.

Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive.

Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier?

Please let me intervene briefly :).

Smalltalk was always indeed open. However, we noticed that regardless of the application domain, tools essentially looked the same for these systems. All Smalltalkers I asked extended Object at least once, but before the GTInspector, most of them never extended the inspector. Our language was extremely dynamic, but our tools less so. That is a conceptual problem that we address with what we call moldability.

Hum. From 1992 to now, I would make the same statement in the Smalltalk world, mostly talking a certain conservatism first (look at how much the system browser has evolved over the years), but also some questions about efficiency of alternative forms.

For example, the code view of the GTInspector remain for me as one of the clumsiest, worse view I've ever seen in the Smalltalk world for editing code.

The goal of moldability is to make it inexpensive to customize. To this end, we approach the IDE as a language and the moldability is captured in the operators that language provides. Of course, there are limitations to what can be doable inexpensively. However, it turns out that if you do manage to bring the cost to a radical low cost, you get much more extensions and experimentations going on.

I'm a bit missing where the moldability of the IDE went, in that context. You seem to stear very clear from anything related to the system browser...

All infrastructures make certain things easier and others less so. The value of all this does depend on what are the operators and how deep in the infrastructure they are placed. For example, the moldable editor shows these expandable elements as part of syntax highlighting. Syntax highlighting existed since a long time, so making it also able to show other things is quite powerful and requires nothing hardcoded. In fact, I do not know of any other editor that can do that while still having the performance we get.

? Especially that last statement.

Adding non text elements in an editor has allways been a fairly easy endeavour in ST, as long as I could remember (1993?).

Performance on long texts is orthogonal to Bloc, right? It is present in all editors that do formatting on long documents since the first WYSIWIG editors appeared in the 80's.

And, so far, the examples you're showing means that editor isn't as capable as Doc (in 1989/1990?) was.

I a bit worried about that syntax highlighting approach. It seems to me very tied to a text + attributes representation instead of an object representation, and I find that API in Pharo horribly clumsy and ineffective, for the apparent benefit of slightly reducing object storage size with a kind of RLE compression.

But, even more important than tool features is the behavior of people. For example, when we first introduced the inspector, all talk was about details (e.g., how it is clumsy to navigate laterally). 2 years later, at this year’s PharoDays most talks used the GTInspector in one way or another to exemplify the presentation. This is a significant impact and this is what we are after.

Yes. This is clearly where the Pharo platform is showing some innovation in the ability to shape better object representations.

At the same time, GUI-wise, there is very little innovation in the GUI language used; GT provides a very limited language, for the sake of efficiency and ease (*). But maybe it can't be done in another way, if you want people to really build their extensions.

At feenk, we don’t say that we build tools. We see ourselves as designing experiences.

Which is a worthwhile goal.

Regards,

Thierry

(*) Such layers represent a so huge investment anyway, so it may be unavoidable.

Cheers, Doru

...

Regards,

Thierry

Tim

Sent from my iPhone

On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier@gmail.com> wrote:

...

2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>: No Thierry, Newspeak do not allow it. And it not looks similar to

what I want.

...

Hum, you would still get the same overall approach: editor inside

editor (or view inside view). Now, you can say it is not the same, up to you.

...

For me, it has the same effect: the editor isn't in a single place

anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both).

...

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.

...

You miss the past behaviour? Why not adding it again?

But as Tim notice it always loses context. And it is quite difficult

to browse long call chain which include many small methods.

...

I'm not sure it would solve that one.

Either it is a long call chain with a fan-out of one, in which case

the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors.

...

For that, you already have the flow browser.

So with new editor command+click will be able expand implementor just

in place. I think it will be big improvement for IDE.

...

As I said, with Calypso and Nautilus handling badly long methods,

then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything.

...

I'd say there that the GTInspector approach would work better ->

expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing).

...

Regards,

Thierry

2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com

:

...

2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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@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@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."

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

-- www.tudorgirba.com www.feenk.com

"Innovation comes in the least expected form. That is, if it is expected, it already happened."

2017-08-28 9:15 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

...

On Aug 27, 2017, at 7:13 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Doru,

thanks for the explanation...

I'll end up with three questions:

- What makes Bloc different compared to the InterViews and Amulet toolkits? And Unidraw?

Bloc is a low level GUI framework. The widgets and the interaction model for building complete applications belongs to a layer above it. This is what Brick is supposed to be. We are right now at the level of building widgets and did not yet decide on the concrete the interaction model. That is why to make it useful, we use the editor embedded inside a Morphic-based interface.

What do you mean by the interaction model? Because, even at low-level, Bloc has already chosen a interaction model (probably a thread per window dispatching events to components arranged in a tree model by bounding boxes + a focus for input, and propagation of damage events upstream). Do you means something like MVC or PAC-Amodeus?

I did not know Amulet, but Interviews and Unidraw I read about more than a decade ago and even then I did not manage to get my hands on a working copy. Unidraw is a high level component-based engine for building applications that bares more similarities with something like Glamour. Nevertheless, I never saw Unidraw in practice and from the documentation that is available it is hard to distinguish the details, and details matter a lot.

The InterViews code (and UniDraw) is easy to find; it has been maintained for open source system under the name ivTools. In it, iDraw is a fine example of UniDraw, and it's GUI (the way it shows scrolling without scrollbars is typical of the visualisation community). Another example is TkInetd. Something that is not usually built in ivTools, but which I think is an absolute must study item for anybody doing GUI toolkits, is Doc. The source is available, probably in the InterViews 3.0 source distribution. Doc is also described in the book Design Pattern.

So, perhaps the most important difference is that Bloc works now in Pharo. This does not mean that it is the best possible framework, only that it is the best we could do. We are confident it is quite good, but it remains to be seen whether it will be enough to be practical.

I agree about that: works in Pharo. I expect it to be good, on the level of those toolkits from the 90's, which means probably as good as anything commercially available today, and perfectly suited to Pharo needs.

...

- Will some of your workflows enables exploration of parallel, non-deterministic programs?

This is certainly an area of interest, although not an easy one. We already used logging that collected signals from multiple processes and explored them inside GT Inspector, but certainly more is needed.

...

- Will we be able to have non-linear execution paths and explorations through examples and documentation?

I am not sure what you mean by execution paths, but when it comes to exploration, this is exactly one of the things we are after: there are multiple contexts one might want to “consume" code in and most of these are unforeseen. For example, showing a method inside a piece of documentation provides an entry point that invites a kind of navigation that is orthogonal to the default code structure. The whole idea behind humane assessment is that we should craft tools to match the current context of interest and this implies new angles of exploration, and this is what GT offers. Last year at ESUG I provided some examples of such exploration paths: https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA

Well, the question arise because I think one of the thing you seems to be targeting for documentation is iPython, and iPython is sequential (the flow of statements through the document) and well suited to its purpose. And the GTExamples pragmas looks like a poor man's graph of dependents examples. At the same time, I see the GT concrete realisation as working often with a single object; that is a single GT inspector showing two panes on a screen (or a playground, which means a single object and a script). So I wonder if that restriction is significant.

But, I am not sure I actually addressed your question.

I'm not sure I know what I am looking for exactly myself. So that make that question difficult to answer? I'm starting to piece around what I would need for this, one item at a time. It's not important however; it does not has enough research value, just that it could be interesting. Regards, Thierry

Cheers, Doru

...

Regards,

Thierry

2017-08-27 13:37 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi Thierry,

Indeed, you noticed correctly that we stayed away from the code browser.

We found several years ago that Morphic was too limiting. During the Spotter implementation we found ourselves having to construct a mini-Morphic in order to do what we wanted to do. With text we had several prototypes for a different kind of editing experience, but we hit a wall. The interface from the GTInspector is the most rudimentary solution we could put in place, and it is there mostly as a placeholder to get over the bridge.

This is why we joined the Bloc project and we focused all our tool development effort on it. The goal is to be able to build interfaces that do not yet exist and that enable workflows that are radically different. We showed can do that once we have an infrastructure, and we will continue to do it until we have a full development experience.

We did not start from the experience of writing code explicitly. That is because the IDE should encompass all activities including the way we understand a system, and we think that focusing on reading is to be left for the previous century. So, we started from the inspector and debugger and we are making our way towards the writing part.

Writing code is certainly of deep interest to us. However, the system browser is the least interesting of the places where we want to write code. That is because we want to code against live objects, not against dead text. The main use case the system browser is good for is to organize code and to find a starting place for getting to a living object. For the rest of the use cases, there are other solutions that are better. For example, even with the current Playground, we have people spending more time in there than in the code browser. That says something given that the Playground is quite bare at the moment.

We do not think in terms of tools, but the overall workflows we want to support. It’s not a race against features, but a reimagining of what an experience can be like. For example, let’s take documentation: right now, both producing and consuming documentation happens mostly outside of the environment. So, the I in the IDE is failing in this respect. We want to make both of these activities more attractive inside the environment and the demo you see here is a step in that direction. There is no name for this tool yet because we tend to not phrase the problem like that.

Related to other editors, there are indeed WYSWIG tools, but they are typically not dynamic. There are viewers that are dynamic, but they tend to not scale well and not be editable. There are tools that scale, but they are not too visual. And even when there exist some, they are not in an IDE. So, yes, there are pieces that already exist, but the way we apply them is novel.

As for syntax highlighting, it is tied to text and attributes but only to the extent we wanted it to be. The current implementation is 2k lines of code. In comparison, just the core of Rubric is 5.5k. But, the rendering is not related to text whatsoever. Word and adornments are just element that conform to a layout. So, this means that people can build something else at a much smaller costs should they want to.

Cheers, Doru

...

On Aug 27, 2017, at 10:43 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Hi Doru,

2017-08-27 9:24 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,

...

On Aug 27, 2017, at 12:06 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Hi Tim,

2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim@testit.works>: I think you pose some interesting design challenges - but it's worthy of experimentation.

I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space.

I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems).

I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia.

I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser.

For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal.

Agreed. I have changed the way I code to reduce the context needed to understand it.

Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive.

Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier?

Please let me intervene briefly :).

Smalltalk was always indeed open. However, we noticed that regardless of the application domain, tools essentially looked the same for these systems. All Smalltalkers I asked extended Object at least once, but before the GTInspector, most of them never extended the inspector. Our language was extremely dynamic, but our tools less so. That is a conceptual problem that we address with what we call moldability.

Hum. From 1992 to now, I would make the same statement in the Smalltalk world, mostly talking a certain conservatism first (look at how much the system browser has evolved over the years), but also some questions about efficiency of alternative forms.

For example, the code view of the GTInspector remain for me as one of the clumsiest, worse view I've ever seen in the Smalltalk world for editing code.

The goal of moldability is to make it inexpensive to customize. To this end, we approach the IDE as a language and the moldability is captured in the operators that language provides. Of course, there are limitations to what can be doable inexpensively. However, it turns out that if you do manage to bring the cost to a radical low cost, you get much more extensions and experimentations going on.

I'm a bit missing where the moldability of the IDE went, in that context. You seem to stear very clear from anything related to the system browser...

All infrastructures make certain things easier and others less so. The value of all this does depend on what are the operators and how deep in the infrastructure they are placed. For example, the moldable editor shows these expandable elements as part of syntax highlighting. Syntax highlighting existed since a long time, so making it also able to show other things is quite powerful and requires nothing hardcoded. In fact, I do not know of any other editor that can do that while still having the performance we get.

? Especially that last statement.

Adding non text elements in an editor has allways been a fairly easy endeavour in ST, as long as I could remember (1993?).

Performance on long texts is orthogonal to Bloc, right? It is present in all editors that do formatting on long documents since the first WYSIWIG editors appeared in the 80's.

And, so far, the examples you're showing means that editor isn't as capable as Doc (in 1989/1990?) was.

I a bit worried about that syntax highlighting approach. It seems to me very tied to a text + attributes representation instead of an object representation, and I find that API in Pharo horribly clumsy and ineffective, for the apparent benefit of slightly reducing object storage size with a kind of RLE compression.

But, even more important than tool features is the behavior of people. For example, when we first introduced the inspector, all talk was about details (e.g., how it is clumsy to navigate laterally). 2 years later, at this year’s PharoDays most talks used the GTInspector in one way or another to exemplify the presentation. This is a significant impact and this is what we are after.

Yes. This is clearly where the Pharo platform is showing some innovation in the ability to shape better object representations.

At the same time, GUI-wise, there is very little innovation in the GUI language used; GT provides a very limited language, for the sake of efficiency and ease (*). But maybe it can't be done in another way, if you want people to really build their extensions.

At feenk, we don’t say that we build tools. We see ourselves as designing experiences.

Which is a worthwhile goal.

Regards,

Thierry

(*) Such layers represent a so huge investment anyway, so it may be unavoidable.

Cheers, Doru

...

Regards,

Thierry

Tim

Sent from my iPhone

On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier@gmail.com> wrote:

...

2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>: No Thierry, Newspeak do not allow it. And it not looks similar to

what I want.

...

Hum, you would still get the same overall approach: editor inside

editor (or view inside view). Now, you can say it is not the same, up to you.

...

For me, it has the same effect: the editor isn't in a single place

anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both).

...

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.

...

You miss the past behaviour? Why not adding it again?

But as Tim notice it always loses context. And it is quite

difficult to browse long call chain which include many small methods.

...

I'm not sure it would solve that one.

Either it is a long call chain with a fan-out of one, in which case

the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors.

...

For that, you already have the flow browser.

So with new editor command+click will be able expand implementor

just in place. I think it will be big improvement for IDE.

...

As I said, with Calypso and Nautilus handling badly long methods,

then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything.

...

I'd say there that the GTInspector approach would work better ->

expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing).

...

Regards,

Thierry

2017-08-26 14:59 GMT+02:00 Thierry Goubier <

thierry.goubier@gmail.com>:

...

2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@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@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@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."

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

-- 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

"Don't give to get. Just give."

Hi Stephan, 2017-08-28 10:50 GMT+02:00 stephan <stephan@stack.nl>:

On 26-08-17 18:38, Thierry Goubier wrote:

For me, it has the same effect: the editor isn't in a single place

...

anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both).

A concrete problem with the Newspeak editor/browser is the invisibility of multiple open edits when editing a large class. There might be changes scrolled away. What it misses is an efficient way of looking only at the open edits. That could be achieved by having a view collapsing all non-edited code.

Would a class-level save work? One could trigger the collapse there as well. Thierry

Stephan

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@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@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."

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@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.

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."

The code works fine in Pharo 7.0. I just tried the following: 1. wget -O- get.pharo.org/alpha+vm | bash

Ah, sorry. I always forgot update.

2. Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load 3. './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference Cheers, Doru

2017-08-29 11:32 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

Hi Denis,

Thanks for the feedback!

As I mentioned, this is a pre-alpha :). Our main focus was on exploring that the design works in breadth. There are indeed, detailed issues that do not work yet, and there are edge cases for navigation and insertion/deletion that are still open issues.

In Bloc we intentionally have not focused on error catching yet. So, right now when there is an error during layout or rendering, Bloc can get in a funny state. You can reset Bloc with: BlUniverse reset

The code works fine in Pharo 7.0. I just tried the following:

1. wget -O- get.pharo.org/alpha+vm | bash 2. Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load 3. './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference

Cheers, Doru

...

On Aug 29, 2017, at 11:04 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hi

I have bad feedback. I guess work is still in progress.

So basic cursor navigation is still not working fine: - sometimes cmd+arrow up is not working and cursor disappears. - scrolling feels slow and not smooth. After attempt to edit text (just press key) I got assertion failures about some layout problems. And after reopening inspector the bloc pillar tab was empty.

When you are expecting stable version? Should it works better in "native" Bloc window (without morphic)? And how to open example this way?

Also it not loads well in Pharo 7 and not working there. My feedback from Pharo 6 on MacOS

2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor@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

"Obvious things are difficult to teach."