- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Fraction and parentheses

by Stephane Ducasse

Hi serge the printing should be normal because like that you are ready to type 1/3 + 2/3 and get 1. Now I do not get why you get ((1/2)) thanks for reporting it. Stef On Mon, Dec 19, 2016 at 9:08 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > I have one question about Fraction. > > When I print a fraction like 1/2 in the Playground I obtain (1/2) and > when I inspect I obtain ((1/2)). Why do we need all these parentheses > ? > > I didn't try with a current Pharo 6.0 image, because my bandwidth is > quite limited right now (Vietnam). > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Dec. 19, 2016

Re: [Pharo-dev] [Moose-dev] Re: Too frequent crashes :-(

by Stephane Ducasse

Hi peter I can understand your frustration. I would be really like to see what I can do to help. But I do not know. Except showing your mail to the vm guys. Thanks for having send it! Stef On Mon, Dec 19, 2016 at 2:03 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Mon, Dec 19, 2016 at 08:12:29AM +0800, Ben Coman wrote: > > Can yo point to where you added you workaround? > > The fix is a single line, because I hate myself. > > interpreterProxy failed ifTrue:[^nil]. > > https://github.com/pharo-project/pharo-vm/commit/ > 9bf66cf656b176d988e1b0ba74fc37da467e6192 > > To give you more info: > > The problem is that memory of canvas forms are not properly pinned, so > during garbage collection the form is being moved, but if at the same time > the canvas form is being updated and moved, you are accessing wrong memory > -> crash. > > My fix will return prematurely if an error occurs and throws > PrimitiveFailed in the image before any wrong memory is accessed. On > Roassal side the PrimitiveFailed is catched and a paint cycle is skipped > --- this is good enough, as it results only in ocassional flicker that > immediately fixes itself instead of crashing the image. > > It seems that on Mac there are also other places in the BitBlt code where > the surface is being accessed without a check. > > Also be careful not to be misled by the crash dump stack. It took me quite > a while to figure out that GrafPort is already operating on wrong data, so > it's not GrafPort's fault, but BitBlt's; of course both should possibly be > investigated with respect to the mac crash. > > Final note, personally I found it much easier the debug and manipulate the > resulting C code (and recompiling just that), then to modify the Slang code > and rebuild the source code and recompile it all (but again, I don't know > what is the proper way to work with the VM code). > > I used this script to trigger the crash https://gist.github.com/ > peteruhnak/024650ed2594301558df4da913549b54 > As the crash depends on memory consumption and "proper" garbage collection > cycle, it wasn't the easiest to reproduce, however the script above usually > managed to crash it. Having a more reliable way would be nice, but simply > triggering GC (nor full GC) wasn't enough because the memory wasn't in the > "right" state. > > Peter > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Max Leske

VM looks ok BTW. Really seems to be the update itself. > On 19 Dec 2016, at 21:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hmm.. I think I will revert this update. > >> On 19 Dec 2016, at 16:36, Max Leske <maxleske(a)gmail.com> wrote: >> >> Confirmed on OS X 10.12.3 >> >>> On 19 Dec 2016, at 19:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> The image seems to come up with a black screenâ¦ something went wrong. >>> >>> Can someone else check? >>> >>>> On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: >>>> >>>> Branch: refs/heads/6.0 >>>> Home: https://github.com/pharo-project/pharo-core >>>> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 >>>> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… >>>> Author: Jenkins Build Server <board(a)pharo-project.org> >>>> Date: 2016-12-19 (Mon, 19 Dec 2016) >>>> >>>> Changed paths: >>>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st >>>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st >>>> M Kernel.package/Delay.class/class/initialize-release/initialize.st >>>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st >>>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st >>>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st >>>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st >>>> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>>> A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st >>>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st >>>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st >>>> >>>> Log Message: >>>> ----------- >>>> 60330 >>>> 18735 DNU on suggestions shortcut in GTDebugger >>>> https://pharo.fogbugz.com/f/cases/18735 >>>> >>>> 19432 Promote DelaySpinScheduler from experimental status (part 2) >>>> https://pharo.fogbugz.com/f/cases/19432 >>>> >>>> 19438 Widen tolerance for DelayScheduler timing tests >>>> https://pharo.fogbugz.com/f/cases/19438 >>>> >>>> http://files.pharo.org/image/60/60330.zip >>>> >>>> >>> >>> >> >> > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Marcus Denker

Hmm.. I think I will revert this update. > On 19 Dec 2016, at 16:36, Max Leske <maxleske(a)gmail.com> wrote: > > Confirmed on OS X 10.12.3 > >> On 19 Dec 2016, at 19:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> The image seems to come up with a black screenâ¦ something went wrong. >> >> Can someone else check? >> >>> On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: >>> >>> Branch: refs/heads/6.0 >>> Home: https://github.com/pharo-project/pharo-core >>> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 >>> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… >>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> Date: 2016-12-19 (Mon, 19 Dec 2016) >>> >>> Changed paths: >>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st >>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st >>> M Kernel.package/Delay.class/class/initialize-release/initialize.st >>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st >>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st >>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st >>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st >>> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st >>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st >>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st >>> >>> Log Message: >>> ----------- >>> 60330 >>> 18735 DNU on suggestions shortcut in GTDebugger >>> https://pharo.fogbugz.com/f/cases/18735 >>> >>> 19432 Promote DelaySpinScheduler from experimental status (part 2) >>> https://pharo.fogbugz.com/f/cases/19432 >>> >>> 19438 Widen tolerance for DelayScheduler timing tests >>> https://pharo.fogbugz.com/f/cases/19438 >>> >>> http://files.pharo.org/image/60/60330.zip >>> >>> >> >> > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Max Leske

Confirmed on OS X 10.12.3 > On 19 Dec 2016, at 19:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The image seems to come up with a black screenâ¦ something went wrong. > > Can someone else check? > >> On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: >> >> Branch: refs/heads/6.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 >> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2016-12-19 (Mon, 19 Dec 2016) >> >> Changed paths: >> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st >> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st >> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st >> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st >> M Kernel.package/Delay.class/class/initialize-release/initialize.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st >> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st >> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st >> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st >> >> Log Message: >> ----------- >> 60330 >> 18735 DNU on suggestions shortcut in GTDebugger >> https://pharo.fogbugz.com/f/cases/18735 >> >> 19432 Promote DelaySpinScheduler from experimental status (part 2) >> https://pharo.fogbugz.com/f/cases/19432 >> >> 19438 Widen tolerance for DelayScheduler timing tests >> https://pharo.fogbugz.com/f/cases/19438 >> >> http://files.pharo.org/image/60/60330.zip >> >> > >

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Graham McLeod

+1 Graham Torsten Bergmann wrote: > Hi Tudor, > > we all already had exchanged on this topic in discussions on this list back a year ago or even before > and as we have seen there were different arguments and different point of views. > > Actions to make Pharo more known are always appreciated and as you made more progress on the idea/tools > side for sure you can demonstrate better what can be done with this approach. > > But does it mean all the other arguments are now invalid because of this? I don't think so. > > Anything described/demonstrated in this approach can perfectly be done without changing the meaning > of the "example" pragma and by using an own pragma to mark methods following that idea. > > Trying to hijack "example" pragma again as it is your preferred pragma name does not help because this is > like enforcing your own point of view on the topic to people like me following the existing > "example" usage. Currently<example> and its usage is very generous and not so restrictive what kind of > example the method contains or what return value it may provide. > > Also counting the current usage in the default image does not tell you anything as it leaves out all external > projects. > > > Similar to Ben I personally have not changed my point of view. I agree with him in using an own and more specific > pragma like > > -<sample> > -<sampleInstance> > -<exemplar> > > better depicting the meaning of returning an sample/sample instance/exemplar of an instance of the class. > I would be fine with using just "sample" as well as "Sample driven development". > > > There is no need to change the meaning of the existing pragma<example> which is more > general and can be any kind of example like: > - example of usage > - a simple example script > - sample instance > - example of an algorithm > - example on how to use several classes together > - ... > > For<example> it is not necessary to return exactly once instance of the class where the pragma > is used in. > > Thx > T. > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Marcus Denker

The image seems to come up with a black screenâ¦ something went wrong. Can someone else check? > On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/6.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 > https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-12-19 (Mon, 19 Dec 2016) > > Changed paths: > M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st > M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st > M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st > M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st > M Kernel.package/Delay.class/class/initialize-release/initialize.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st > M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st > A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st > A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st > > Log Message: > ----------- > 60330 > 18735 DNU on suggestions shortcut in GTDebugger > https://pharo.fogbugz.com/f/cases/18735 > > 19432 Promote DelaySpinScheduler from experimental status (part 2) > https://pharo.fogbugz.com/f/cases/19432 > > 19438 Widen tolerance for DelayScheduler timing tests > https://pharo.fogbugz.com/f/cases/19438 > > http://files.pharo.org/image/60/60330.zip > >

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Dimitris Chloupis

personally I like what I see, I don't have any objection. My personal opinion on this is that Pharo needs a proper documentation system which what examples are part of like Java or Python doc strings. But then a doc strings system is far more complex than the GTExample and a lot more work. In the mean time GTExample looks like a good enhancement to have. I also dont see it creating any incompatibilities with the existing <example> pragma. On Mon, Dec 19, 2016 at 7:27 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Dec 19, 2016, at 5:49 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, Dec 19, 2016 at 3:53 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> > >> > >> 2016-12-19 8:46 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >>> > >>> Hi, > >>> > >>> I would prefer if this thread does not transform in a terminology > debate > >>> too much. > >>> > >> > >> @Doru, but you asked "What do you think" and I think Bens response > about > >> sampleScript is valid > >> > >> @Ben Did you check Dorus blog entry > >> (http://gtoolkit.org/doc/Examples/examples.html) I think this makes > >> it more clear why gttExamples are more than just methods producsing > >> "samples" > > > > > > I hadn't seen that before. Thanks for the tip. > > So I cede the point the aim is something more than just a sample. > > Thank you! > > But, if we are at it, please letâs continue and brainstorm. The existing > implementation should be taken as a first fully working version. It would > be great to have people play with it and find its weaknesses. > > Cheers, > Doru > > > > > cheers -ben > > > >> > >> > >>> > >>> Example is a term that fits both the code and the returning object. > >>> <gtExample> is applied on a method and it primarily describes that > method. > >>> The term âexampleâ also describes the meta object that is wraps the > concrete > >>> return value with the information from the method (for example, the > label of > >>> the example, the link to the subject, or the dependencies to other > >>> examples). The example term is also important from the metaphor point > of > >>> view: "we learn from examplesâ. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>>> On Dec 19, 2016, at 3:34 AM, Ben Coman <btc(a)openinworld.com> wrote: > >>>> > >>>> On Mon, Dec 19, 2016 at 5:49 AM, Tudor Girba <tudor(a)tudorgirba.com> > >>>> wrote: > >>>>> Hi, > >>>>> > >>>>> As you might know, a while ago we created GTExamples, a framework > that > >>>>> supports both example-based live documentation and testing: > >>>>> http://gtoolkit.org/doc/Examples/examples.html > >>>>> > >>>>> GTExamples was part of the GTInspector for a while, but as it > evolved, > >>>>> we pulled it out in a separate project. This separate project is not > in > >>>>> Pharo anymore but it is part of the full GToolkit configuration > (Pharo only > >>>>> ships the core of GToolkit). The idea of taking GTExamples out was > to allow > >>>>> the community to have a more elaborate discussion about the role of > examples > >>>>> in our environment. > >>>>> > >>>>> I have invited you to join that conversation, but it did not take > off. > >>>>> I understand that perhaps the topic does not look appealing at this > moment. > >>>>> > >>>>> We will certainly continue to evolve GTExamples both on the semantics > >>>>> level of the dependency constructs and on the integration with > tools. Our > >>>>> goal is to enable a new practice that I would like to call > Example-Guilded > >>>>> Development (or Example-Driven Development), and position Pharo to > be the > >>>>> only platform on which someone can do that. But, that is our goal, > and does > >>>>> not have to be the same with other peopleâs goal. > >>>>> > >>>>> Right now, GTExamples relies on the <gtExample> pragma to denote a > >>>>> method that returns an object that exemplifies something. > >>>> > >>>> > >>>> I've previously not done a good job of promoting the use of <sample> > >>>> for this. I'll try spinning this wheel once more. > >>>> > >>>> There are two concepts to consider: > >>>> * The returned object. > >>>> * The method code that creates the returned object. > >>>> > >>>> The "returned object" is best considered a <sample>. > >>>> The "method code" is best considered an <example> that produces the > >>>> sample. > >>>> > >>>> > http://www.differencebetween.com/difference-between-example-and-vs-sample/ > >>>> > >>>> The term "exemplifies/exemplification" associates equally with both... > >>>> * http://www.thesaurus.com/browse/example > >>>> * http://www.thesaurus.com/browse/sample > >>>> but for example... from a draw full of cutlery you don't "take an > >>>> example spoon", you "take a sample spoon". > >>>> > >>>> > >>>> So it depends on where you want the focus to be. > >>>> * If the focus is on working with a sample object, then <sample> makes > >>>> a better pragma for the method creating it. > >>>> * If the focus is on the code producing the sample, then <example> is > >>>> a better choice. > >>>> > >>>> Maybe you are constrained by existing industry terminology, > >>>> but "Example-Driven Development" might be equally called > >>>> "Sample-Driven Development". > >>>> Without having read into the topic, intuitively the former broadly > >>>> encompasses copying static code > >>>> while the latter feels more limited to working with an object. > >>>> > >>>> > >>>> My proposal... > >>>> * <sample> provides a narrower sense of side-effect-free provision of > >>>> object to work with. "Samples are often tangible parts and can be > >>>> observed" > >>>> * <example> provides a broader sense of showing how things work > >>>> together, in ways that may or may-not include side effects that you > >>>> don't actually want to execute - just to refer to. "Examples are used > >>>> [to] illustrate something. [Its] expected that the example will be > >>>> imitated and replicated among its audience." > >>>> * <script> provides a sense of system management, of methods causing > >>>> significant side effects. You won't want to copy these methods, just > >>>> make use them. > >>>> > >>>> <sampleScript> feels awkward to apply to examples, since by my these > >>>> are neither samples nor scripts. > >>>> > >>>> > >>>> cheers -ben > >>>> > >>>> > >>>>> Executing this method as an example should have no side-effects > (either > >>>>> because the method itself does not have a side-effect, or because the > >>>>> example method defines how the cleanup should happen using the > mechanism > >>>>> provided by GTExamples). > >>>>> > >>>>> This meaning is different from the meaning of the <example> pragma > used > >>>>> through Pharo. There are currently 55 places that use this pragma > inside > >>>>> Pharo and most of them come from FastTable. As things will progress > and more > >>>>> libraries might use GTExamples, the situation can become confusing. > >>>>> > >>>>> To make things less confusing in the future, I would like to define > the > >>>>> meaning of the <example> to denote a method that returns an object > without > >>>>> having side effects. Would you agree with this? > >>>>> > >>>>> If yes, I would suggest the name of the new pragma that would replace > >>>>> the existing one to include âscriptâ in the name. For example, > >>>>> <sampleScript>. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> Cheers, > >>>>> Doru > >>>>> > >>>>> > >>>>> -- > >>>>> www.tudorgirba.com > >>>>> www.feenk.com > >>>>> > >>>>> "Reasonable is what we are accustomed with." > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> âSoftware has no shape. Actually, it has no one shape. It has many." > > -- > www.tudorgirba.com > www.feenk.com > > "If you can't say why something is relevant, > it probably isn't." > > >

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Tudor Girba

Hi, > On Dec 19, 2016, at 5:49 PM, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Dec 19, 2016 at 3:53 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> 2016-12-19 8:46 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>> Hi, >>> >>> I would prefer if this thread does not transform in a terminology debate >>> too much. >>> >> >> @Doru, but you asked "What do you think" and I think Bens response about >> sampleScript is valid >> >> @Ben Did you check Dorus blog entry >> (http://gtoolkit.org/doc/Examples/examples.html) I think this makes >> it more clear why gttExamples are more than just methods producsing >> "samples" > > > I hadn't seen that before. Thanks for the tip. > So I cede the point the aim is something more than just a sample. Thank you! But, if we are at it, please letâs continue and brainstorm. The existing implementation should be taken as a first fully working version. It would be great to have people play with it and find its weaknesses. Cheers, Doru > cheers -ben > >> >> >>> >>> Example is a term that fits both the code and the returning object. >>> <gtExample> is applied on a method and it primarily describes that method. >>> The term âexampleâ also describes the meta object that is wraps the concrete >>> return value with the information from the method (for example, the label of >>> the example, the link to the subject, or the dependencies to other >>> examples). The example term is also important from the metaphor point of >>> view: "we learn from examplesâ. >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Dec 19, 2016, at 3:34 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> On Mon, Dec 19, 2016 at 5:49 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> As you might know, a while ago we created GTExamples, a framework that >>>>> supports both example-based live documentation and testing: >>>>> http://gtoolkit.org/doc/Examples/examples.html >>>>> >>>>> GTExamples was part of the GTInspector for a while, but as it evolved, >>>>> we pulled it out in a separate project. This separate project is not in >>>>> Pharo anymore but it is part of the full GToolkit configuration (Pharo only >>>>> ships the core of GToolkit). The idea of taking GTExamples out was to allow >>>>> the community to have a more elaborate discussion about the role of examples >>>>> in our environment. >>>>> >>>>> I have invited you to join that conversation, but it did not take off. >>>>> I understand that perhaps the topic does not look appealing at this moment. >>>>> >>>>> We will certainly continue to evolve GTExamples both on the semantics >>>>> level of the dependency constructs and on the integration with tools. Our >>>>> goal is to enable a new practice that I would like to call Example-Guilded >>>>> Development (or Example-Driven Development), and position Pharo to be the >>>>> only platform on which someone can do that. But, that is our goal, and does >>>>> not have to be the same with other peopleâs goal. >>>>> >>>>> Right now, GTExamples relies on the <gtExample> pragma to denote a >>>>> method that returns an object that exemplifies something. >>>> >>>> >>>> I've previously not done a good job of promoting the use of <sample> >>>> for this. I'll try spinning this wheel once more. >>>> >>>> There are two concepts to consider: >>>> * The returned object. >>>> * The method code that creates the returned object. >>>> >>>> The "returned object" is best considered a <sample>. >>>> The "method code" is best considered an <example> that produces the >>>> sample. >>>> >>>> http://www.differencebetween.com/difference-between-example-and-vs-sample/ >>>> >>>> The term "exemplifies/exemplification" associates equally with both... >>>> * http://www.thesaurus.com/browse/example >>>> * http://www.thesaurus.com/browse/sample >>>> but for example... from a draw full of cutlery you don't "take an >>>> example spoon", you "take a sample spoon". >>>> >>>> >>>> So it depends on where you want the focus to be. >>>> * If the focus is on working with a sample object, then <sample> makes >>>> a better pragma for the method creating it. >>>> * If the focus is on the code producing the sample, then <example> is >>>> a better choice. >>>> >>>> Maybe you are constrained by existing industry terminology, >>>> but "Example-Driven Development" might be equally called >>>> "Sample-Driven Development". >>>> Without having read into the topic, intuitively the former broadly >>>> encompasses copying static code >>>> while the latter feels more limited to working with an object. >>>> >>>> >>>> My proposal... >>>> * <sample> provides a narrower sense of side-effect-free provision of >>>> object to work with. "Samples are often tangible parts and can be >>>> observed" >>>> * <example> provides a broader sense of showing how things work >>>> together, in ways that may or may-not include side effects that you >>>> don't actually want to execute - just to refer to. "Examples are used >>>> [to] illustrate something. [Its] expected that the example will be >>>> imitated and replicated among its audience." >>>> * <script> provides a sense of system management, of methods causing >>>> significant side effects. You won't want to copy these methods, just >>>> make use them. >>>> >>>> <sampleScript> feels awkward to apply to examples, since by my these >>>> are neither samples nor scripts. >>>> >>>> >>>> cheers -ben >>>> >>>> >>>>> Executing this method as an example should have no side-effects (either >>>>> because the method itself does not have a side-effect, or because the >>>>> example method defines how the cleanup should happen using the mechanism >>>>> provided by GTExamples). >>>>> >>>>> This meaning is different from the meaning of the <example> pragma used >>>>> through Pharo. There are currently 55 places that use this pragma inside >>>>> Pharo and most of them come from FastTable. As things will progress and more >>>>> libraries might use GTExamples, the situation can become confusing. >>>>> >>>>> To make things less confusing in the future, I would like to define the >>>>> meaning of the <example> to denote a method that returns an object without >>>>> having side effects. Would you agree with this? >>>>> >>>>> If yes, I would suggest the name of the new pragma that would replace >>>>> the existing one to include âscriptâ in the name. For example, >>>>> <sampleScript>. >>>>> >>>>> What do you think? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Reasonable is what we are accustomed with." >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> âSoftware has no shape. Actually, it has no one shape. It has many." -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

Dec. 19, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60330 Home: https://github.com/pharo-project/pharo-core

Dec. 19, 2016