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. 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
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 <[hidden email]> 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 >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
No.
You install this in a 6.1 using: Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. Indeed, the project is still called GToolkit, but the one from GitHub is a new generation that will be exclusively be based on Bloc. Cheers, Tudor > On Sep 2, 2017, at 5:57 PM, H. Hirzel <[hidden email]> wrote: > > 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 <[hidden email]> 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 >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
In reply to this post by Thierry Goubier
Hi,
> On Sep 2, 2017, at 5:43 PM, Thierry Goubier <[hidden email]> 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 >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Hi Doru,
Le 02/09/2017 à 18:22, Tudor Girba a écrit : > Hi, > >> On Sep 2, 2017, at 5:43 PM, Thierry Goubier <[hidden email]> 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. Does that means that even if the analysis would have been able to determine if it was an example, you would insist on the <gtExample> tag? Regards, Thierry > 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 >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> 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." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
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
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
In reply to this post by Tudor Girba-2
Thanks for the update. Is nice to know that this pre-alpha is
advancing fast. Keep us informed and let us know when is going to
alpha, beta, RC, and released, so it can be used as a stable and
responsive package in the last stable Pharo. I would love to
integrate Documenter with Grafoscopio when is mature enough for
that. Offray On 01/09/17 16:51, Tudor Girba wrote:
Hi, _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Free forum by Nabble | Edit this page |