Hello Doru

I understand that I load this into Pharo6.0/6.1 with

Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; configuration; loadDevelopment. [1]

Is the documenter included

And that the screen shot http://gtoolkit.org/pictures/examples.png showing many pragmas no longer applies....

Regards Hannes

[1] taken from http://gtoolkit.org/#install

On 9/2/17, Thierry Goubier thierry.goubier@gmail.com wrote:

Hi Doru,

Le 01/09/2017 à 23:51, Tudor Girba a écrit :

...

Hi,

When we announced the GT Documenter as an application for the moldable editor, one of the remarks was that GT Examples implementation relies too much on pragma magic.

We are now happy to announce that this is no longer the case because Andrei did a great job and rebuilt examples without the need for static pragmas for specifying dependencies.

Thinking of it, I'm sure that analysis is nearly able to establish something is a proper example without even the <gtExample> tag...

Regards,

Thierry

...

So, now we can example dependencies simply through normal calls:

emptyView

<gtExample> ^ GtMondrian new

twoNodes

<gtExamples> view := self emptyView view nodes with: {1 . 2}

... and the engine can figure out the static dependencies. This means that examples can be used both as plain unary methods, and as replacement for tests. We think this should address the worry of examples being too heavy (the current implementation is ~350 lines).

With a bit of extra effort, we also adapted GT Documenter to expand the example dependencies as seen below. This means that examples can now be used directly as units of documentation as well.

We think this is significant.

Cheers, The feenk team

-- www.tudorgirba.com http://www.tudorgirba.com www.feenk.com

"We are all great at making mistakes."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

Hi,

On Sep 2, 2017, at 5:43 PM, Thierry Goubier thierry.goubier@gmail.com wrote:

Hi Doru,

Le 01/09/2017 à 23:51, Tudor Girba a écrit :

...

Hi, When we announced the GT Documenter as an application for the moldable editor, one of the remarks was that GT Examples implementation relies too much on pragma magic. We are now happy to announce that this is no longer the case because Andrei did a great job and rebuilt examples without the need for static pragmas for specifying dependencies.

Thinking of it, I'm sure that analysis is nearly able to establish something is a proper example without even the <gtExample> tag…

Not all returning unary methods are meaningful examples. <gtExample> denotes the intention of using a certain code and returning object as an example.

Doru

Regards,

Thierry

...

So, now we can example dependencies simply through normal calls: emptyView

<gtExample> ^ GtMondrian new twoNodes <gtExamples> view := self emptyView view nodes with: {1 . 2} ... and the engine can figure out the static dependencies. This means that examples can be used both as plain unary methods, and as replacement for tests. We think this should address the worry of examples being too heavy (the current implementation is ~350 lines). With a bit of extra effort, we also adapted GT Documenter to expand the example dependencies as seen below. This means that examples can now be used directly as units of documentation as well. We think this is significant. Cheers, The feenk team -- www.tudorgirba.com <http://www.tudorgirba.com> www.feenk.com "We are all great at making mistakes." _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

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

"We cannot reach the flow of things unless we let go."

if you could have a pragma or Method send that would group a tree of Methods together so you could document it and maybe example it like this and then you could choose to have the Compiler inline them all into the root Method actually so the root Method could inline the tree of Methods it calls into itself or most or some of the tree or it would let you pick from a chooser or whatever then i would be sold on the giant soup of Methods a blizzard of tiny Methods the whole deal

it could be a kind of a lispy macro functionality

because the thought of actually calling all these little things just makes me start into dreaming of lagging and Smalltalk is slow

but i should use the Profiler I SHOULD USE THE PROFILER all these rank and file notions to dispel i should use the Profiler once and then the ice is broken if it's not in a loop then it doesn't matter but i always assume that it might be is this my fault? is this my problem? and when i see something be laggy rank and file notions refuse to quell

so then the root Method could get the inlined Methods as dependents so if they change it could also recompile Maybe but what if the dependents gets too large just show the dependents tree WeakArrays